Useful Hyper-V links

This content is 16 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

In the week or so since Hyper-V RTMed there has been a huge amount of coverage on various websites. Here’s a roundup of some of the more useful articles that I’ve come across recently:

Windows Vista imaging and deployment

This content is 18 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

However much I try to avoid it, as an IT infrastructure consultant, I always seem to get involved in operating system deployment. With that in mind, a couple of days back, I went along to an event at which Microsoft UK’s James O’Neill gave an interesting presentation on Windows Vista imaging and deployment.

Deployment of a PC operating system ought to be simple. It isn’t. Well, it can be, but only after a lot of hard work and planning. You see, unlike a closed system such as Apple Mac OS X, a Windows deployment typically has to support a plethora of different PCs – each with their own hardware variants (very few organisations have the luxury of a 100% standardised infrastructure – IT hardware simply changes too quickly for that). For many years now, the approach to deploying a PC operating system has been to use imaging software, e.g. Symantec Ghost, but there are complications around which images can be applied on what hardware, as well as licencing implications for any software included in the image – often images are created based on a combination of target hardware and end-user roles. Then there’s the data to consider – how are applications to be deployed, what will happen to user data (e.g. in an upgrade scenario), and what about system settings (Outlook profile, etc.). A managed deployment has many advantages around consistency (between images), manageability and reliability; however there is a huge cost attached to maintaining each image.

Since the creation of Windows NT, administrators have been able to automate Windows deployment using a system of answer files and either a product CD or a distribution share. This can be customised to roll out additional applications as well as to alter the Windows configuration and add OEM-specific items and it works well, but is slow to deploy and costly to maintain (often scripted installations are used to deploy to reference PCs from which images are taken).

Windows 2000 introduced the concept of booting a PC across the network using the pre-boot execution environment (PXE) to connect to a remote installation services (RIS) server and download an image. Later, this was extended to create the solution accelerator for business desktop deployment (BDD) and enhanced through the creation of Microsoft automated deployment services (ADS) – now renamed Windows deployment services.

Windows Vista employs a totally new deployment approach – using Windows Image (.WIM) files – look on a Vista DVD and there is no i386 folder (the main setup file on my Vista RC2 DVD is called install.wim). Those who have worked with BDD and ADS may already be familiar with an older version of the .WIM file format and the new version supports deployment to a new system, side-by-side installation, or in-place upgrades (actually, an in-place upgrade is a side-by-side installation which then transfers the settings from the old copy of Windows, which can safely be destroyed later). The Windows imaging approach supports modularisation of components, single instance storage, compression and file-based imaging – allowing many images and many image variants to be installed in a single .WIM file for deployment from optical media, or using deployment solutions such as BDD or Microsoft SMS. Importantly, deployment is non-destructive. Furthermore, Windows Vista does not have any of the restrictions around hardware abstraction layers (HALs) and so there is no requirement for hardware-specific images; and because the image is file-based (cf. disk block-based images), it can be mounted as a file system and manipulated offline.

.WIM files are structured as follows:

  • Header – with signature, version, GUID and indexes to images.
  • File resources – the actual image files.
  • Metadata – information about the files within the image.
  • Resource table(s) – effectively a directory tree for the files within the image, defining the file system.
  • XML data – information used to customise the image.

Windows imaging uses a system of filters, e.g. the .WIM file system filter (to edit image contents) and the WIM boot filter (not surprisingly to boot from an image). The main tool used for manipulation of .WIM files is imagex.exe (previously known as ximage.exe). imagex.exe allows the mounting and unmounting of .WIM files as a file system, whereby changes can be made before they are committed to the .WIM file. It is also used to create, append to and split image files, as well as for viewing the XML data about an image file. There’s also an API for programmatic manipulation of .WIM files – WIMGAPI. It’s important to note that, whilst there are both 32- and 64-bit versions of the Windows Vista deployment tools, they are compatible, so images created/modified with a 64-bit version of imagex.exe will still work on a 32-bit system, etc. Also worth noting is that the System Preparation Tool (sysprep.exe) still exists – images still need to be sysprepped – but there are new options around what the system should do on its first boot.

Whilst imagex.exe can be used to capture the contents of a running system, it’s not good practice, and Microsoft recommends that the Windows pre-installation environment (WinPE) is used instead. Because WinPE runs entirely in memory there are no issues around locked files and Windows PE 2.0 will be made more widely available than previous versions. James’ presentation also indicated that a file called winscript.ini can be used to specify exclusions (e.g. pagefile.sys, hiberfil.sys, \WINDOWS\CSC, \RECYCLER, System Volume Information, \$ntfs.log, etc.); however he’s since blogged that the .INI file is not required – the key point is that there are files which you will almost certainly want to exclude from an image.

Another important tool is the Windows System Image Manager – setupmgr.exe on steroids! This is used to build a catalog of .WIM file contents and then customise the file – e.g. to add components, or to customise settings, before validating the resulting unattend.xml answer file.

Other deployment tools, available for previous Windows versions but updated for Vista include the application compatibility toolkit and the files and settings transfer wizard (formerly the user state migration toolkit).

Bootable .WIM files are always called boot.wim. The boot process is as follows:

  1. Read boot configuration database (BCD) file. This tells the system what to execute and effectively replaces the boot.ini file found in previous versions of Windows NT/2000/XP/2003; however, unlike boot.ini it is not a text file – it must be edited using bcdedit.exe.
  2. Mount boot.sdi
  3. Attach boot.wim to boot.sdi
  4. Continue boot process.
  5. Install .WIM file system filter

The use of .WIM files is not limited to Windows Vista imaging – although they may be unsupported with other operating systems and there may be complications (e.g. I wrote a post last year about deploying Windows XP using ADS). Indeed, Windows Vista imaging technologies will also be used for the next Windows Server product (codenamed Longhorn), although because this is still a beta product, the details may be subject to change. Importantly, the tools provided for working with Windows Vista .WIM files are not all compatible with legacy operating systems.

It looks as though the new Windows Vista approach to imaging and deployment will be a steep learning curve for us all, but it should result in a more flexible, and manageable, approach to deployment – more information about Windows Vista deployment enhancements is available on the Microsoft website.

More on booting Windows PE from a USB flash drive

This content is 18 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

A few months back, I wrote about booting Windows PE from a USB flash drive. Early versions of PE didn’t make this very straightforward, but Microsoft UK’s James O’Neill has blogged about doing exactly this with Windows PE 2.0 in his article on getting started with Windows PE – it looks like it’s got a whole lot easier.

Hopefully, I’ll get some time to have a go at this soon.

Booting Windows PE from a USB flash drive

This content is 18 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Something that I’ve been playing around with for a while now is booting Windows Preinstallation Environment (Windows PE) from a USB flash drive and a few weeks back I finally found enough time to have a proper look at this and make some progress.

There’s lots of anecdotal evidence of success (or otherwise) on the ‘net, but because Microsoft restricts access to Windows PE, many people are using Bart Lagerweij’s BartPE as an alternative. I do have access to Windows PE and specifically wanted to get this working using the Microsoft version. Some people (e.g. Niko Sauer and Dag at have done similar things with Linux variants such as Knoppix.

It seems that not every USB flash drive is capable of acting as a boot device and not every PC BIOS supports USB boot. If there is no BIOS support, then it’s just not going to work (I think USB 2 is also a prerequisite). It’s also unlikely that a USB stick will work as shipped from the factory – it will need a boot partition to be (re)written and the easiest way to do this is with a USB disk format tool.

I got a Dell Latitude D600 to boot MS-DOS last year using a Dell 128MB USB flash drive (which is a rebadged Lexar Digital Film device) but didn’t get much further because Windows PE was too large to fit on the device. More recently, I’ve been using a 256MB SanDisk Cruzer Mini that I bought from for £9.99. I’ve use this to successfully boot an IBM Thinkpad T40 and a Compaq Evo D510SFF but can’t test on the Fujitsu Siemens Lifebook S7010D that I use for work because I don’t have access to the BIOS (thanks to my employer’s corporate information systems administrators).

Here’s my process for taking a USB flash drive from new to booting Windows PE:

  1. Check that the PC BIOS supports booking from USB-attached removable media and enable this.
  2. Download and install a USB flash drive format utility – I used the HP USB disk storage format tool v2.1.8 (SP27608) but alternatives include the Dell USB memory key utility revision (R69131) and Martin List-Petersen also recommends MBRTool, which formats a USB flash drive in hard disk mode and installs a FreeDOS kernel (with FAT32 support); however he also reports that it seems to have trouble with USB keys of 256MB or larger.
  3. Format the USB flash drive with a FAT16 file system, including ability to work as an MS-DOS startup disk and with quick format deselected.
  4. Perform a test boot into MS-DOS using the USB flash drive.
  5. Download BootPart and copy this to the USB flash drive (I used v2.60).
  6. Copy a Windows PE installation that is known to work from CD/DVD to the USB flash drive.
  7. Rename the \i386 folder to \minint.
  8. Copy from \minint to \.
  9. Copy setupldr.bin from \minint dir to \ and rename to ntldr (no extension).
  10. Reboot from the USB flash drive and run bootpart (you can now delete the DOS files on the stick and remove the boot. ini entry for MS-DOS (if really needed, personally I would leave it there).
  11. Reboot from the USB flash drive once more and Windows PE should load.

Some notes I’ve read suggest that there is an extra step – i.e. that of copying winbom.ini from \minint dir to \; however, using a colleague’s pre-built Windows PE 2005 images I couldn’t get the normal PE one to work – only the one which was configured to to use a RAM disk (and that didn’t have a winbom.ini). The downside of this was that it took about an hour to boot! I thought this was because the reference PC only had 256MB RAM but tried on a 512MB machine and no difference. Obviously need to do more work in this area, but the basic principle of booting from the USB flash drive is now proven.

I’ll post an update with the final configuration when I manage to make Windows PE more performant but, at present, the file system on my USB flash drive looks like this:

\bootpart.exe (01/08/2005 02:06 44,544 bytes)
\ntldr (25/03/2005 11:00 298,096 bytes)
\ (25/03/2005 11:00 47,772 bytes)
\minint\bootfix.bin (25/03/2005 11:00 1,024 bytes)
\minint\ 25/03/2005 11:00 47,772 bytes)
\minint\setupldr.bin (25/03/2005 11:00 298,096 bytes)

The winnt.sif file contains the following text:

BootDevice = "ramdisk(0)"
BootPath = "\i386\System32\"
OsLoadOptions = "/noguiboot /fastdetect /minint /rdexportascd /rdpath=winpex86.iso"
Architecture = "i386"

USB articles at
MSFN forum – Boot PE from USB flash drive
Oliver Aaltonen’s USB booting tips
Jacopo Lazzari’s USB pendrive how to
The CD Forum – boot your WinPE or UBCD4Win on USB flash drive