This documentation is archived and is not being maintained.
The Desktop Files Windows Automated Installation Kit
Wes Miller is a Development Manager at Pluck (pluck.com) in Austin, Texas. Previously, he worked at Winternals Software and at Microsoft as a Program Manager and Product Manager for Windows. Wes would like to thank Scott Dickens and John Macintyre, from Microsoft, for their assistance with this column. Wes can be reached at firstname.lastname@example.org.
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.
Microsoft has historically offered two versions of the deployment tools that the Windows Deployment Team produced. The first version came in the form of the deploy .cab file which has shipped on the Windows CD for years. It included documentation and tools such as Setup Manager for creating unattended setup files, as well as
the Sysprep tool, used to prepare desktops for deployment. The other version of the deployment tools was the OEM Preinstallation Kit (OPK), which was specifically engineered to meet the needs of OEM system manufacturers and was available only to them. This was the original way in which Windows® PE was distributed. There is a new version of the OPK for Windows Vista™, but it will continue to be available to OEMs only.
Fortunately for most other Microsoft customers, some of whom couldn't obtain Windows PE during the Windows XP timeframe, there will be a near analog of the OPK available for them to use, called the Windows Automated Installation Kit (WAIK). The WAIK will be freely available for download from microsoft.com/downloads after Windows Vista ships and will include the following components: Windows PE 2.0, Windows Deployment Services, ImageX, and Windows System Image Manager-a tool I haven't mentioned before that allows for the creation of unattend.xml files to automate setup. Also included is full documentation for all of the tools.
Note that the recommended method for obtaining the WAIK is to download the full Business Desktop Deployment Solution Accelerator (BDD) from microsoft.com/desktopdeployment, which provides not only the WAIK, but the User State Migration Tool (USMT), Application Compatibility Toolkit (ACT). The BDD also includes additional tools and guidance for achieving a successful deployment of Windows Vista.
Windows PE 2.0
I covered Windows PE 2.0 in significant depth in the November 2006 issue of TechNet Magazine, so I won't go into much detail here; suffice it to say that the WAIK will deliver the official release of the new Windows PE build for Windows Vista. It's important to understand Windows PE, since all of the other tools in WAIK either use or work with Windows PE in some manner. You can find my article on Windows PE 2.0 here. .
In my last column, I spent a fair amount of time covering the Windows Imaging (WIM) file format. (See microsoft.com/technet/technetmag/issues/2006/12/desktopfiles.) Now I'll look at ImageX, which is a small, yet powerful, command-line tool that makes the built-in imaging of Windows Vista possible. When planning ImageX, we had considered creating a GUI-based tool, but decided to focus on the command line since automation of the imaging process was the critical component. To see the command-line options for ImageX, see Figure 1.
Figure 1 ImageX Command-Line Tool in Action (Click the image for a larger view)
Windows Deployment Services (WDS), which I'll describe later, does deliver a lightweight GUI tool that allows for easy capture of images, but it does not deliver the full functionality of ImageX. It's also important to note that ImageX is designed and tested to capture images for deployment under Windows PE. It was not designed to do "live" captures of Windows systems that are actively running.
If you are familiar with any other system imaging tool, you are familiar to a degree with ImageX. It was designed to be simple to use, allowing you to easily capture and apply images, and yet provide critical functionality that's often missing or incomplete in the commonly used deployment tools that came before it. One such example, which I'll cover momentarily, is the ability to easily and transparently mount an image as a part of your local file system so that you can view, modify, or delete files from within an existing image.
ImageX provides the image manipulation switches shown in Figure 2. I'm going to call out a couple of specific commands to describe them in more depth.
|IMAGEX /APPEND||Appends a new Volume Image into a WIM file which already contains an existing Volume Image.|
|IMAGEX /APPLY||Applies a Volume Image to a volume that has been partitioned and formatted.|
|IMAGEX /CAPTURE||Captures an initial Volume Image into a WIM file.|
|IMAGEX /DELETE||Permanently deletes the references to a Volume Image from a WIM file. Note that this deletes the metadata. It does not remove the compressed file data—that can be done by using the /export switch to create an entirely new WIM.|
|IMAGEX /DIR||Displays the directory tree of a specified Volume Image in a WIM file.|
|IMAGEX /EXPORT||Exports a Volume Image from a WIM file or several Split WIM (SWM) files.|
|IMAGEX /INFO||Displays the details of a given Volume Image or WIM file—also can set the /boot option for a given Volume Image that contains Windows PE. Only Windows PE can be booted from a WIM file.|
|IMAGEX /SPLIT||Splits a WIM file into one or more smaller SWM files so that it can be contained on multiple CDs or DVDs.|
The Capture command should be relatively clear-the main thing to remember is that you only use capture once per WIM. Since a WIM file is just a file capture, you can capture an entire volume (C:) or even just a directory (C:\Test). Application is the same-you can apply an image to a directory (even if you had captured an entire volume) or, as is more likely the case, the root of a volume. Once a single Volume Image exists in a WIM already, you would use the append command to add to it. Apply is also relatively self-explanatory and only becomes complicated when you are applying multiple WIM files. The delete command is useful if you want to remove the reference to a specific Volume Image-but in order to completely remove the data from that image you must use export to create a new WIM completely free of the data (meaning, if you want to reduce the size of the image by removing the remaining data, you must use export). Think of export as a tool that can act as a defragmenter, or a consolidator, letting you weave a Volume Image into one or more WIM files, or export it to its own completely standalone WIM file. ImageX also provides the following image editing switches: IMAGEX /MOUNT, IMAGEX /MOUNTRW, and IMAGEX /UNMOUNT.
As mentioned, the product team incorporated editing capabilities into the imaging tools and format from the very beginning. By enabling editing, the format and tools would allow customers to copy files in or out, apply service packs, add/remove files or standalone applications, or add/remove other data from the image as needed (even mounting and modifying the registry). Servicing of the image was always a key focus.
You can think of mounting the image as loading the WIM file as a virtual directory. If you're familiar with them, the proper analogy is probably more like a Volume Mount Point, which allows you to mount an entire volume to a directory that exists on another volume (making F: visible as C:\DriveF, for example). Similarly, you may have used the Microsoft® Virtual CD tool or other ISO mounting tools that allow you to mount ISO (CD) images as local drives. In this same manner, ImageX allows you to mount a WIM file as an overlay on top of a directory. You create the directory and then use the mount command to overlay the specified Volume Image on top of the directory, much as if you had applied it there.
Unlike the Virtual CD tool, however, you can mount a WIM image even if it is located across a network share or if it is on removable media. Of course, doing so may limit its editing capability-a WIM on optical media (CD or DVD) will generally be editable in read-only mode. You can also only edit one Volume Image in a WIM at a time if you are editing in read/write mode-this is to allow for proper locking and safe updating of the file when it is unmounted.
You can mount the image read-only (/mount) or read/write (/mountrw). When you use read/write, any modifications you make to the image are temporarily cached (they do not take effect immediately), and when you run the /unmount command with the /commit option, these changes are permanently persisted into the WIM. If you made changes and then decided you really didn't want to persist them, you could also discard rather than commit them when you unmount the image. This is all or nothing-all writes you've made during the time that the WIM file was mounted are either committed or discarded.
Note that there's an important caveat here. Just as with the delete command, when you use the read/write functionality to edit the WIM, the file data in the WIM file itself isn't completely erased or cleaned up-the files are appended to the end of the WIM file, and the earlier reference in the Volume Image is supplanted with the updated data. This means that if you added a new 5MB file, replacing an existing 5MB file, your image will grow by the size of the 5MB file after it has been compressed (that is, 5MB or less, depending on the type of compression used). To remove the old data from the WIM (if you wanted to shrink the image) you would need to use /export to export the Volume Image into an entirely new WIM file.
If you read my discussion of Windows PE 2.0 in the November 2006 issue of TechNet Magazine, you'll remember that it supports booting from a WIM. In order to do this, the WIM file is read using a driver, similar to the way ImageX does it. But the ImageX support was designed to be used at design time, and the WIM boot feature was designed specifically to be read-only and to work just for Windows PE. So although they are similar, the drivers and implementation are different.
In addition to the ImageX tool, Microsoft provides a formally documented API, WIMGAPI, that allows full support for any imaging tool that wants to be able to capture, apply, or modify WIM files. So any third party that wants to add imaging support or replace an existing imaging infrastructure, can do so with WIMGAPI. This API is a part of the WAIK and therefore is distributed with it.
Windows Image-Based Setup
With the imaging format in hand, the new engine for setup was designed. At its core, it is much like the old Mini-Setup or Windows Welcome, asking the basic questions necessary to get the system uniquely set up and configured while also handling disk configuration before installing the image from the install.wim on the Windows setup DVD. The primary goal of the new setup engine was to allow for manual installations of Windows. We envisioned that many OEM and enterprise customers would use ImageX to do their actual deployments.
Remote Installation Services
At this point you may be asking why I haven't discussed Remote Installation Services (RIS). RIS was something I also inherited when I started in the Windows Deployment team. RIS, which shipped first with Windows 2000 and then again in Windows Server® 2003, uses a Pre-boot Execution Environment (PXE) to network boot a computer to the point that a rudimentary wizard can be completed, and Windows installation can occur-all over the network.
The single largest problem with RIS was that it was excruciatingly fragile. The Windows Server 2003 release of RIS, originally only supported with Windows 2000 Professional, expanded support for server versions of Windows. With the incoming rush of Serial ATA (SATA) storage controllers and GB or faster NICs, keeping drivers up to date in RIS was always fraught with peril. Additionally, RIS doesn't support many of the same locales that Windows does, meaning installation of localized versions of Windows with localized keyboards can be difficult, if not impossible. Windows Deployment Services was designed to be the amalgam of Windows setup and RIS-a PXE-initiated boot of Windows PE, which would allow you to deploy a WIM file over the network.
WDS was designed to not only be available in the forthcoming version of Windows Server code-named "Longhorn," but also as an update that would be installable on Windows Server 2003. This meant that WDS would be able to deploy Windows Vista from older versions of Windows Server, and that it would be able to deploy older versions of Windows as well. In fact, WDS not only works with RIS, but it requires an installation of RIS in order to function. This is because it works by updating the RIS infrastructure to be compatible with WDS, while also providing the new WDS infrastructure.
In addition to working as an upgrade from RIS-thereby providing a good migration path for customers continuing to use earlier versions of Windows while beginning deployments of Windows Vista, WDS also provides much better management tools than RIS historically had, allowing for easier addition of new images to the server. It also provides a pluggable PXE framework, meaning that a third-party PXE server can integrate in and specify that it is to answer a specific client's PXE request instead of WDS. This was a request that we often received with RIS that we could not provide at that time.
Initially available as an installable component on Windows Server 2003 to update RIS, WDS will also ship as an integrated component of the Windows Server "Longhorn" products. Microsoft is also currently planning to include WDS functionality in the future versions of SMS (which will be known as System Center Configuration Manager).
WDS works by providing a PXE-booted version of Windows PE 2.0. This image is contained in a WIM (meaning there is reduced data transmitted over the network) and is booted over the network into a RAMDisk. The installation then happens under Windows PE, using a new client application that provides the functionality delivered by the RIS rudimentary OSChooser application in the past.
Though WDS does not support RIS images of Windows XP, Windows 2000, or Windows Server 2003 as-is, it does have the ability to deploy Sysprep images of them. WDS also integrates into Active Directory®, as RIS did historically, but the PXE server can also run without Active Directory if needed. WDS can even be initiated from Windows PE booted from something besides PXE-such as a CD, DVD, or USB Flash Drive (UFD). This is helpful functionality that RIS was not able to provide.
There are effectively three modes WDS can operate in, depending on your existing use of RIS:
Legacy WDS binaries are installed, but OSChooser is the boot mechanism. RISetup and RIPrep, the scripted setup and image-based setup tools for RIS, still function.
Mixed-Mode Both boot mechanisms are available, both sets of imaging tools function, and both sets of management tools function.
Native There is no RIS functionality, only WIM functionality, Windows PE boot, and new management tools are available. Note that this is the only mode scheduled to be available for Windows Server "Longhorn." It will not include any RIS functionality.
WDS also implements a custom client-server communication protocol, and as a result, an OEM or enterprise customer could theoretically build his own deployment application as well.
The process of capturing a WIM image into a WDS server is nearly identical to the Sysprep scenario I walked through. The difference is that the last step will involve booting into the WDS Capture Image, a Windows PE image that exists to help you capture a client system, and capture it to the WDS server.
The core components of WDS are as follows: the WDS Server Service, PXE Server, Image Store, Communication Protocol, File share with Windows PE images (to be booted), WIM images (to be installed), and additional related management files.
WDS was designed to be relatively lightweight and to provide a nearly identical experience (though often faster) than a traditional optical media-based installation of Windows. The implementation of WDS as an update to RIS allows you to gradually replace RIS in a graceful manner while easing into the deployment of Windows Vista in your organization. It also does so in a way that is easier to use and faster than RIS was ever able to deliver with previous versions of Windows.
Windows System Image Manager
The final component of the WAIK is the Windows System Image Manager (SIM). If you are familiar with Setup Manager from previous versions of Windows, then the concept of the Windows SIM should be somewhat familiar to you. This tool allows you to complete several tasks with unattended setup files. You can easily create a new unattended setup file, edit an existing one, or verify the settings in an existing file against a specific image of Windows Vista. The tool can also show you all potential configuration options given a specific WIM with Windows Vista in it-think of the traditional unattended setup options, documented historically in the help files accompanying the deploy.cab. Finally, Windows SIM can help create Distribution Shares and Configuration Sets, which are used to add drivers, applications, and updates to your Windows Vista installations via an unattended setup file.
Windows SIM requires that you be a local administrator on the system you are running it on. When you open Windows SIM, you will see five panes, as illustrated in Figure 3.
Figure 3 Windows System Image Manager (Click the image for a larger view)
Distribution Share, on the upper-left, is a pane that displays drivers and other packages that you have added via SIM. By default it does not have a Distribution Share mounted, but you can easily open or create one.
Windows Image pane, below Distribution Share, displays the config options (Components and Packages) in a given Windows Volume Image in a WIM. Note that you mount a single Volume Image of Windows (one SKU on the Windows Vista DVD) at a time.
Answer File, the pane in the center, displays the configuration options in a new or existing Windows Vista unattended setup file, as well as the default settings as defined by the catalogs (the potential settings and configuration) from the WIM Volume Image that you have mounted.
Properties, in the upper-right of the window, is a pane which lets you edit the individual properties of a component from the Answer File pane.
The final pane is Messages, which is located at the bottom and displays more in-depth feedback, including a view of the raw XML in a Windows Vista unattended setup file (always in an XML format) as well as validation output and any messages related to any Configuration Sets you are currently using (the Configuration Set tab only contains data if you have a Configuration Set opened).
As you've seen, the WAIK provides a very powerful set of tools to help you deploy Windows Vista. The Windows Deployment team has done a great job of creating a collection of tools that you'll find make Windows Vista more easily deployable than any version of Windows in the past.