Introducing Deployment Enhancements for Windows Vista | Introducing Microsoft Windows Vista

Many organizations use some form of automation to deploy the Windows operating system, such as disk imaging technology, remote installation, or unattended installation. With disk imaging, administrators typically have to create and maintain separate images for each type of hardware and language used throughout the enterprise. When administrators add new hardware language packs, updates, or drivers, they usually have to create and then test new disk images. Updating disk images every time changes occur is not only time-consuming but also costly. The same is true, but to a lesser extent, for maintaining multiple answer files—multiple answer files are costly to create and maintain, especially when implementations require different types of files and those files use different file formats.

Microsoft used several approaches to reduce deployment complexity and costs. These approaches include using the following features:

Language-independent modularization
Hardware-independent disk imaging
Customizable and extensible preinstallation environments
Standards-based single-format answer files

How do these features work? Well, let’s take a look.

Introducing Modularization and Hardware-Independent Disk Imaging

Microsoft reengineered the basic architectural framework of the Windows operating system so that it uses independent units of programming logic called modules and provides a selective capability to customize Windows Vista by swapping out modules. In this modular architecture, system components, device drivers, and language packs are all created as modules, and so are service packs and updates.

Understanding Modules and Disk Images

The benefits of a modular architecture are far-reaching. Thanks to modularization, when you need to add device drives, language packs, or service packs or make other updates, you can more easily introduce these new components because you are simply adding new modules to the system. When you need to update or remove an existing component, you can do so without impacting the system as a whole—the changes affect only the related module or modules for that component. Because language packs are separate modular components from the operating system itself, you don’t need a separate image for each language used in your organization, thereby reducing the total number of disk images large organizations need to maintain.

Microsoft reengineered the basic distribution format of the Windows operating system so that it uses a hardware-independent image-file format. The new imaging format is called Windows Imaging Format (WIM), and Windows Vista is distributed using this format. Thanks to WIM, Microsoft can ship a single binary to all of its customers around the world: one binary format for 32-bit architectures and one binary format for 64-bit architectures. WIM allows you to store multiple images in one file and significantly reduces image size by using a combination of compression and single-instance storage. With compression, the total size of the image file is reduced in much the same way as Zip compression reduces the size of files. With single-instance storage, the disk image contains only one physical copy of a file for each instance of that file in the disk image. This substantially reduces the size of the image because there are no duplicate files.

WIM allows administrators to modify and maintain disk images offline, which means that administrators can add or remove optional components and drivers or perform updates without having to create a new image. Administrators can also mount images as folders and work with them in much the same way as any other folder, making it easier to update files within images. For example, you can mount an image and then use Windows Explorer to update or remove files as necessary. The ease with which you can update disk images and the removal of the requirement to have multiple hardware-specific disk images greatly reduces deployment complexity and costs.

Tip

The new image-based operating system setup also makes upgrades easier and more reliable. Thanks to WIM, upgrading to Windows Vista essentially means that Setup performs a clean installation of the operating system followed by a migration of user settings, documents, and applications from the earlier version of Windows.

Creating and Managing Disk Images

At a high level, deploying Windows Vista with imaging requires the following procedures:

Creating the configuration to be deployed.
Preparing the system for capture.
Capturing the image.
Maintaining the image as necessary.
Applying the image.

Creating the Configuration to Be Deployed Creating the configuration to be deployed means setting up the operating system, configuring the operating system, installing any necessary applications, and then configuring those applications. Once you do this, you can prepare the system for capture by running the System Preparation command-line tool (SysPrep.exe). SysPrep irrevocably alters the computer and designates it as a master deployment computer by removing the unique identification information from the computer.

By removing the unique identifiers from the computer, SysPrep creates a resulting image that can be installed on multiple computers without creating identification conflicts. However, the computer no longer has identifying information that allows it to be logged on to and used within a domain or workgroup setting. Typically, you must reinstall the operating system.

Capturing the Image In the Windows Automated Installation Kit (Windows AIK), you’ll find a tool called XImage. Using the Windows Vista XImage tool, you can capture your image file from Windows PE or with the operating system fully loaded. The best technique for capturing an entire installation, however, is to use Windows PE. When capturing an image with Windows PE, no locked files or folders will be included in your installation image, and as a result, you should experience fewer problems capturing the image.

Note

Although you can capture an image from a running version of Windows, you can capture only files and folders not in use by the operating system. Later, when you are installing from the image, any in-use files must also be listed in the exclusion list of the configuration script. Although excluding these in-use files reduces the errors you see during installation, it doesn’t ensure that the image is usable. If essential files were locked during the image capture, the image won’t install the operating system properly.

You can capture an image by using XImage with the following syntax:

ximage /capture ImageSource ImageDest "ImageDescription"

ImageSource is the location of the files to image, ImageDest is the name and location of the new image file, and "ImageDescription" is a description of the image file, such as

ximage /capture C:\Windows D:\WinVistaStandard.wim "Windows Vista Standard"

If you don’t specify a destination drive, XImage creates the image and stores it in the XImage folder on the system drive. If the image file is too large for your selected media, you can use the /split option to split an existing image file into smaller .swm files, such as for spanning across several CDs. Before you split an image, you must determine the size of the media required for the image and then provide this value as one of the parameters passed to XImage. In the following example, you split a previously created image file into 600-megabyte (MB) .swm files:

ximage /split D:\WinVistaStandard.wim 600

Maintaining the Image Once you’ve created an image file, you can easily maintain the image. To do this, you must install the Windows Imaging File System Filter (WIM FS Filter) driver on your computer by right-clicking the Wimfltr.inf file in the XImage folder and then selecting Install. After installing the filter driver, you can mount image files to folders on your computer. The files in the mounted image can be browsed via the folder by using Windows Explorer or other software. You can perform copy, paste, and editing operations on files in the mounted folder without having to re-create the image.

Tip

Although it is a best practice to mount images to an empty folder, you don’t have to mount to empty folders. The contents of non-empty folders are inaccessible, but they are not affected by the mount operation. When you unmount the image, you’ll be able to access the existing files on the folder.

Images can be mounted as read-only or read/write. Read-only images cannot be edited; read/ write images can be edited.

You can mount an image as read-only by using the following syntax:

ximage /mount MountPath ImageFilePath ReferenceNumber

MountPath is the location of the mount folder, ImageFilePath is the name and location of the .wim file to mount, and ReferenceNumber is the reference number of the specific volume in the .wim file to use, such as:

ximage /mount C:\Data D:\Images\Data.wim 1

You can mount an image as read/write by using the following syntax:

ximage /mountrw MountPath ImageFilePath ReferenceNumber

ximage /mountrw C:\Data D:\Images\Data.wim 1

Using the mounted folder, you can:

Open files and folders and view their contents.
Add files or folders.
Move the files and folders within an image.
Edit existing files and folders.
Delete files and folders.

When you have finished working with an image, you must unmount the image and optionally commit your changes. You use the following syntax to unmount an image and save your changes:

ximage /unmount /commit MountPath

MountPath is the location of the mount folder, such as:

ximage /unmount /commit C:\Data

If you mounted an image as read-only, you don’t need to use the /commit option. There are no changes to save.

Caution

When working in Windows PE, keep in mind that mounted images cannot persist across restarts. If you have file system changes to be committed as the computer restarts, you will lose the changes. Additionally, Windows PE restarts automatically after 24 hours, so if you leave a changed image mounted and go home, the changes will likely be lost when you return to work the next day. For these reasons, Microsoft recommends that you do not use ximage /unmount /commit from Windows PE.

Applying the Image When you are ready to apply the image, you can do so using a variety of automatic techniques, such as deployment scripts, or you can apply an image manually. Either way, you must first prepare the target computer by creating and formatting the disk partitions. If you choose to perform these tasks from a script, insert the commands to create and format the disk partitions prior to executing the XImage commands that apply the image. You apply an image by using the following syntax:

ximage /apply ImageFilePath ReferenceNumber

ImageFilePath is the name and location of the .wim file to apply, and ReferenceNumber is the reference number of the specific volume to use in the .wim file, such as:

ximage /apply D:\Images\Data.wim 1

To have XImage apply and then verify the image, you can add the /verify option, as follows:

ximage /apply D:\Images\Data.wim 1 /verify

Introducing the Customizable and Extensible Preinstallation Environment

Another new feature in Windows Vista is Windows Preinstallation Environment Version 2.0. Windows PE 2.0 is a bootable startup environment that provides operating system features for installation, recovery, and troubleshooting.

Understanding Windows PE 2.0

When you install Windows Vista, the graphical tools that collect configuration information during the setup phase are running within Windows PE. If Windows Vista fails to start because of a corrupted system file, Windows PE allows you to access and run the Startup Recovery Tool. You can also manually start Windows PE to use built-in or custom troubleshooting and diagnostic tools.

Windows PE replaces MS-DOS as the preinstallation environment. Windows PE is built from Windows Vista components to provide a versatile and extensible environment. Not only can Windows PE run many Windows Vista applications, it can also detect and enable most hardware devices and communicate across IP networks. Windows PE can run entirely from RAM, allowing you to run Windows PE computers that do not currently have a formatted hard disk or an installed operating system.

Windows PE provides full access to both FAT and NTFS file systems. Before you replace or reformat a hard disk, you can start the computer with Windows PE first and then copy any needed files to another disk or to a shared folder.

Windows PE includes several built-in management tools, including:

DiskPart A command-line tool for managing disks, partitions, and volumes.
Drvload A command-line tool for adding device drivers and dynamically loading a driver after Windows PE has started.
Net A suite of commands that allow you to manage local users, start and stop services, and connect to shared folders.
Netcfg A network configuration tool that configures network access.

Administrators can create customized Windows PE images with configuration scripts that customize the deployment process. When a new computer is connected to the network, the built-in Preboot Execution Environment (PXE) client connects to a Windows Deployment Service server and downloads the customized Windows PE image across the network. The new computer then loads Windows PE into memory and launches the configuration script.

Working with Windows PE 2.0

Many types of configuration scripts can be used within Windows PE. Configuration scripts can be used to:

Verify the computer configuration.
Use Netcfg to configure network access.
Use Drvload to install a driver and use the hardware without restarting the computer.
Back up the user data to a shared folder on another computer.
Run DiskPart to partition and format the computer’s hard disk.
Use NET SHARE to connect to a shared folder containing the Windows Vista Setup files.
Run the Windows Vista Setup program to install the operating system.

Like Windows Vista, Windows PE can be contained within a WIM file. However, when you store a Windows Vista image in a WIM file, the only way to start Windows Vista is to copy the full image to the computer’s hard disk. Windows PE, on the other hand, can start directly from a WIM file without being copied to a hard disk. Because of this, you can create a WIM file that includes Windows PE, store this file on bootable media such as a DVD or USB flash drive, and then start Windows PE directly from that media. The Windows Vista distribution media uses this technique to load Windows PE into RAM when you run Setup.

Administrators can load Windows PE fully into memory as well for troubleshooting and recovery. If you choose to run Windows PE from memory, the Windows PE boot loader:

Creates a virtual RAM disk in memory.
Copies a compressed version of Windows PE to the RAM disk.
Mounts the RAM disk as if it were a disk drive and starts Windows PE.

Loading Windows PE from RAM allows you to remove the Windows PE media after Windows PE has started and then insert different media into the computer’s CD/DVD drive. When Windows PE runs from memory, it supports writing temporary files to the virtual RAM disk. This isn’t possible, however, when running from read-only media such as a CD.

Windows PE has several limitations. It requires a computer with a VESA-compatible display and a minimum of 256 MB of RAM. During startup, if Windows PE can’t detect the video settings, it uses a screen resolution of 640 × 480 pixels. Otherwise, it uses the highest resolution possible. Windows PE supports both IPv4 and IPv6. Although you can access shared folders on other computers from Windows PE, other computers cannot access files or folders on a computer running Windows PE.

Windows PE has other limitations as well. Drive letter assignments aren’t persistent between sessions. Windows PE always starts with the default drive letter assignments. Because Windows PE doesn’t support the Microsoft .NET Framework or Windows On Windows (WOW), you cannot use .NET applications on any versions of Windows PE, 16-bit applications on 32-bit versions of Windows PE, or 32-bit applications on 64-bit versions of Windows PE. Additionally, as a safeguard to prevent Windows PE from being used as a general-purpose operating system, Windows PE automatically restarts after running for 24 hours.

Introducing Standards-Based Single-Format Answer Files

With standards-based single-format answer files, Windows Vista introduces significant enhancements for remote and unattended installations. Although earlier versions of the Windows operating system use multiple answer file formats and often require the use of several different types of answer files, Windows Vista uses a single Extensible Markup Language (XML)–based answer file format that allows administrators to deploy systems using only a single answer file.

Instead of having to use unattend.txt, winbom.ini, and sysprep.inf for deployments, you have to use only the Windows Vista unattend.xml answer file. Because XML is based on an existing standard, many different tools can be used to create and modify unattend.xml files, including Ximage (discussed earlier in this chapter). This simplification and reliance on an industry standard can help to ensure that unattended installations are less prone to errors and are more manageable.

From the experts: The Solution Accelerator for Business Desktop Deployment

The deployment tools this chapter describes are building blocks that help you build, customize, and service images. The Windows Automated Installation Kit (Windows AIK) provides Windows System Image Manager (Windows SIM) and Ximage, for example. Windows SIM is the tool you use to create unattended setup answer files for Windows Vista. Ximage is the tool you use to capture, apply, and service images offline.

These tools combined with the many other deployment tools that Microsoft provides for Windows Vista are very capable. They are not a complete solution, however. If you were to rely solely on these tools, you’d eventually build a framework of scripts and related files that automates the deployment process. For example, you’d write scripts that gather information about each destination computer. You’d write scripts that automatically save user state and then restore it after applying the image. You’d write scripts that install applications from an application portfolio. You’d build scripts that configure the computer after applying the image. These kinds of scripts are simple. The framework gets complex in zero-touch installation scenarios, though.

To address the need to glue these tools together into a manageable framework, Microsoft provides the Solution Accelerator for Business Desktop Deployment (BDD). BDD is an end-to-end deployment solution based on the tools you read about in this chapter. It supports light-touch and zero-touch scenarios. BDD does most of the work for you, allowing you to focus more on important deployment details and less on forcing the tools to work together as a complete solution. Using the Windows Vista deployment tools without the BDD framework just doesn’t make sense. For more information about BDD, see http://www.microsoft.com/technet/desktopdeployment.

Jerry Honeycutt

Author and MVP—For more information, see http://www.honeycutt.com.