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.