Imaging and Desktop Engineering

Deployment Features in Windows Vista

A typical factor in your previous heroic deployment efforts was the number of images that you had to manage. In heterogeneous environments with diverse requirements, you often had to build numerous images. Adding new hardware, language packs, patches, and drivers usually required recreating each disk image. Patching multiple images and testing each of them when a critical fix appeared required a lot of effort. Therefore, one of Microsoft's major design goals in Windows Vista was to significantly reduce the number of images you must maintain and help you maintain those images more easily.

A key way that Windows Vista helps you reduce the number of images you must build and maintain is by reducing dependencies on components that typically differ from one image to the next. These include languages, hardware abstraction layers (HALs), and device drivers. For example, unlike earlier versions of Windows, Windows Vista images are no longer tied to a HAL type (Windows Vista supports only ACPI-based computers). The operating system can redetect the HAL when you apply it to each destination computer. Also, Windows Vista is language neutral, which means that all languages are operating system components, and adding or removing language packages is easy.

In addition to reducing dependencies, Microsoft modularized Windows Vista to make customization and deployment easier, based the installation of Windows Vista on the file-based Windows imaging (.wim) file format, and added other significant deployment features to the core operating system. The following list describes these core deployment features in Windows Vista:

Setup. Setup for Windows Vista installs the operating system from an image file (Install.wim) and uses the new Unattend.xml answer file, which replaces the collection of answer files that earlier versions of Windows use (e.g., Unattend.txt, Sysprep.inf). Because image-based deployment is faster, you can use it in high-volume deployments and for automating image maintenance.

Imaging. Windows Vista is delivered to you in the Windows imaging (.wim) file format, already prepared by running Sysprep, and is highly compressed to minimize network traffic when replicating or deploying the image. Unless you need to install third-party applications, you do not need to recapture an image file. You can install the Windows Vista .wim file from the Windows product DVD or create customized images for automated deployment. Because .wim images are file based, you can service (e.g., add files, change registry settings) your deployment images offline, making image maintenance easier. You can also store multiple volume images in a single .wim file, one of which can be bootable.

Windows System Image Manager (Windows SIM). Windows SIM (formerly Setup Manager) is the tool you use to create your distribution points (folders storing files to add to an image) and answer files and to add optional components and packages such as device drivers and languages to your images. It exposes all configurable settings in Windows Vista and enables you to make and save your customizations in Unattend.xml, including disk configurations and other settings.

ImageX. ImageX (formerly XImage during the Windows Vista beta) is the new file-based imaging tool for Windows Vista. ImageX is a command-line tool that you can use to fully script the disk-imaging process. You can use it to capture, modify, and apply file-based .wim images for rapid deployment. ImageX can also mount .wim files on folders, enabling you to explore and change files in the folder. ImageX works with other technologies that use .wim images, such as Setup for Windows Vista and Windows Deployment Services (Windows DS).

Sysprep. Sysprep is the tool you use to prepare computers for disk imaging. Sysprep has new and fewer command-line options.

Script-based installations. Windows Vista includes extensive support for using the command line and scripting to enable remote, automated, and repeatable deployment solutions. For example, ImageX is completely scriptable.

Installation reliability and performance. Windows Vista is designed for a much faster and more reliable installation experience than earlier versions of Windows. Upgrading to Windows Vista is fast, depending on the system being upgraded as well as the size, speed, and free space on the hard disk.

The following sections describe these features in more detail. The "Windows Imaging File Format" section describes the organization of .wim files and the Windows Imaging Application Platform Interface (WIMGAPI) API that developers can use to manage them. The "Modularization" section describes how Windows Vista modularization helps make building and maintaining images easier. The "New Unattend File Format" section describes the new XML-based unattended setup answer file and how it simplifies the task of customizing your images for deployment.

Windows Imaging File Format

Windows Vista will be distributed in .wim files, the new image file format. This format has the following advantages:

• Windows imaging files are a file-based image format that lets you store multiple images in one file. You can perform partial volume captures by excluding files, such as paging files, that you don't want to deploy the image.
• This format reduces file sizes significantly by using a compressed file format and single-instance storage techniques (the image file contains one physical copy of a file for each instance of it in the image file, which significantly reduces the size of image files that contain multiple images).
• You can service the image contained in the .wim file, including adding and deleting packages, software updates, and device drivers, without recreating a new image by applying it, customizing it again, and recapturing it.
• You can mount .wim files as folders, making it easier to update files in the images they contain.

Windows imaging files enable the nondestructive application of an image to the destination computer's hard disk. You can also apply an image to different-sized destination drives, as .wim files don't require the destination hard disk to be the same size or larger than the source hard disk.

Windows imaging files can span media, enabling you to use CD-ROMs to distribute large .wim files.

Windows PE .wim files are bootable. For example, you can start Windows PE from a .wim file. In fact, Windows Vista Setup and Windows DS start Windows PE from the .wim file Boot.wim, which you can customize by adding items such as device drivers and scripts.

File Format Details

Figure 1 shows the format of a .wim file. The following list describes each part:

Header. The header contains a signature, size, and version. It also includes a globally unique identifier (GUID), part list, boot index, and compression type.

File Resources. Windows imaging files store the file resources (e.g., File Stream Data 1) contiguously after the header. The file resources are compressed using LZX (most compression) or XPress (fastest compression). File resources do not contain information such as file locations and attributes.

Metadata. Each .wim file's metadata includes the volume's directory structure, file names, attributes, hard links, reparse points, streams, and so on.

Resource Table. The resource table includes resource locations, hash, and reference count, and associates file resource data with file instances.

Image Info Descriptor. The Image Info Descriptor is reserved for image XML data.

Figure 1: The Windows imaging file format.

WIMGAPI Overview

The WIMGAPI is the Windows Imaging API that developers can use to manage .wim files. The API exposes all imaging functionality. In fact, ImageX is a command-line interface for WIMGAPI.

The possibilities are endless. For example, a developer can use the API's functions to create a new .wim file and capture an image to it. The developer's code can mount the .wim file to a folder, update its contents, and unmount the .wim file. Last, a developer's code can prepare a computer's hard disk by partitioning and formatting it, then applying the .wim file to the computer. The API even provides callback messages that enable the developer's code to display progress and error messages to the user.

WIMGAPI lets independent software vendors (ISVs) develop third-party image-deployment and servicing products to fill almost any need. It also lets your company's IT developers more easily create custom imaging solutions for your organization. The Windows Imaging Interface Reference fully documents the WIMGAPI functions, structures, and messages.

Modularization

Windows Vista is built using modular design. Modularization doesn't just mean that users can choose which features to install. Modularization gives you the selective capability to customize Windows Vista, enabling the following benefits:

• You can more easily add optional packages such as device drivers, language packs, service packs, and updates to an image.
• You can more easily customize Windows Vista to your specific requirements.
• Microsoft can service an individual component without breaking the entire operating system.
• You can reduce testing while deploying a new operating system.

For example, Windows Vista is language agnostic. Languages, including English, are packages. You don't need a separate image for each language. Thus, the modularization of Windows Vista significantly reduces the number of images a global organization must maintain. Another example is that User State Migration Tool (USMT) 3.0 can now compare migration manifests between versions, and more accurately determine the settings to migrate between versions.

Figure 2 shows what modularization looks like from your perspective. You use Windows SIM to add packages to and remove packages from an image (see the "Windows System Image Manager" section for more information about Windows SIM). In this example, you see three packages in the Answer File pane. Under Hotfix, you see two hotfix packages. Under LanguagePack, you see the English language pack. You simply download the package to your distribution share, and then drag the package from the Distribution Share pane and drop it on the Answer File pane. After adding packages to your answer file, you can commit the source files to your image by clicking Apply Answer File to Image on the Tools menu.

Figure 2: Packages.

Component Servicing Architecture

Windows SIM uses the Component Platform Interface (CPI) APIs to access the settings in a Windows Image file. The CPI APIs enable you to create your own custom applications that can automate the creation and management of answer files. The CPI serves as a switchboard for the three primary interfaces. CPI accesses the three interfaces to provide required information to create setup files. The interfaces are:

• Component-Based Servicing (CBS). Interaction with CBS enables management of packages including service packs, hotfixes, languages packs, and other types of packages.
• Setting Management Interface (SMI). SMI queries and relays information about system settings to the CPI.
• WIMGAPI. WIMGAPI provides information to the CPI about how to identify and interpret a .wim file. This process, known as mounting, enables the CPI to understand the .wim file type and properly interpret the information contained in the file.

These three interfaces call the specific information that Windows SIM needs to work with packages, settings, and mounting of the Windows Image file.

Windows Vista Setup

In earlier versions of Windows, the setup and deployment process was automated by multiple answer files, such as Unattend.txt, Sysprep.inf, and Winbom.ini. These answer files enabled automation during a particular phase of setup and deployment—one answer file for each phase. Because some unattend settings were valid during more than one phase, or pass, duplication existed between the files, particularly Unattend.txt and Sysprep.inf. This duplication caused extra effort and possibly deployment errors.

As in earlier versions of Windows, Windows Vista Setup has multiple passes. However, Windows Vista uses a single answer file, Unattend.xml, for all of the following passes (the generalize and specialize passes are required; all others are optional):

offlineServicing. In the offlineServicing pass, the Unattend.xml file is applied to the offline destination image. Offline passes are staged with an operating system image that is not currently running. You can apply some updates and certain Unattend.xml settings to the offline image during the offlineServicing pass. For example, you can add new or updated Plug and Play (PnP) drivers or remove a language pack during an offline pass.

generalize. The generalize pass creates a reference image that can be applied to a variety of systems. During the generalize pass, basic system information is initialized, and all machine-specific information is removed from the image. The generalize pass is started by the sysprep/generalize command. You can automate the configuration of your reference image by configuring a setting during the generalize pass. For example, during the generalize pass, you can set the default home page in Microsoft Internet Explorer for your business's home page.

specialize. During the specialize pass, machine-specific information for the image is created, such as the unique system identifier (SID). Whereas the generalize pass creates an image template that applies to the entire organization, the specialize pass further customizes the installation. For example, during the specialize pass, you can customize the installation for a specific department or branch.

auditSystem. The auditSystem pass is an optional pass that enables you to add additional device drivers and applications to the image. This results in fewer required images because a reference image can be created with a minimal set of drivers. The image can be updated with additional drivers during the audit process. You can then test and resolve any operating system issues related to malfunctioning or incorrectly installed devices on the image. For example, you can install additional language packs, updates, or other applications, such as Microsoft Office.

auditUser. The auditUser pass is similar to the auditSystem pass. However, the auditUser pass processes these settings after users have logged on, not before they have logged on. Like the auditSystem pass, the auditUser pass is used to test the functionality of the Windows Vista image.

oobeSystem. This pass defines the first boot experience for end users. The out-of-box experience (OOBE) runs the first time the user starts a new computer that you have prepared or after the user runs Windows Setup. The OOBE is run before the Windows shell or any additional software loads and performs a small set of tasks necessary to run Windows.