Image-Based Windows XP Deployment

If you're considering an image-based Windows XP deployment for your organization, you've probably read up on Microsoft's Sysprep tool (sysprep.exe) and examined the pros and cons of maintaining system images. With knowledge about your company's desktop computing requirements and the following insights into how you can leverage Sysprep's advanced system-preparation capabilities, you'll be able to get by with maintaining a smaller number of images, and the images will be useful for longer periods. The time and effort you spend fine-tuning the image and imaging process will pay dividends many times over when you're ready to begin deployment.

Build Images for the Long Term
Like buildings that require strong foundations to stand the test of time, system images need good building materials and solid workmanship. Begin with a clean install; you don't want any stray drivers, registry entries, or application files contaminating your pristine image. To achieve consistency in iterative builds, use scripted installs for both the OS and applications whenever possible. If you're new to unattended installs, be sure to read Inside Out, "Unattended Installs with Windows 2000 Professional," June 2000, http://www.winnetmag.com, InstantDoc ID 8741, which describes the process. Although the article discusses Win2K Pro, the content applies to XP Professional Edition as well. The goal is to always start with the same foundation when you create a new image build. Use a checklist of operations for building an image to avoid neglecting a step that might render the image useless, and always document and use version control on the images you develop just as software developers do when creating applications.

As part of the preparations for taking the source machine's image, Sysprep automatically disjoins your system from a domain; however, I prefer to avoid joining a domain, if possible. Instead, I use the local Administrator account to install applications and service packs and perform customizations. To maximize image longevity, give careful consideration to the customizations you make at this stage. If settings are subject to change, use cmdlines.txt scripts to set the values, as I discuss later. (For example, if you have an internet dialer application that receives updated phone number lists, don't bother to make sure the included phone number list is updated; instead, build in a script to update the list at the end of the imaging process.) You can alter the scripts as needed without necessitating a new image build.

If you're not ready to use Group Policy for managing user environment settings, you can create a default user profile to establish a common environment for new users on imaged systems. When you configure the image-source computer, create a temporary local account, log on to that account, and customize the Desktop, Start menu, and other user profile—related settings you want to standardize. When finished, log off, then log on to the Administrator account. To facilitate browsing in subsequent steps, configure Windows Explorer to show hidden files and folders. Right-click My Computer, select Properties, then click the Advanced tab. Under User Profiles, click Settings, select the profile of the temporary user you created, and click Copy To. Browse to %SystemDrive%Documents and Settings, select the Default User folder, and click OK. Under Permitted to use, click Change, then type

everyone

Click OK, click OK again, and choose Yes when the system asks whether you want to overwrite the existing default user profile. Users logging on for the first time to this system or a system you create from this image will receive the settings the default user profile specifies.

You must include as part of the image any device drivers necessary to support your target computers (and that aren't included as part of the OS). To automate the installation of these drivers, you must copy them to a location on the hard disk and update sysprep.inf to reflect that location. (If you've never created a sysprep.inf file, refer to the sidebar, "Using Setup Manager to Create a Sysprep.inf File.")

Start by creating a Sysprep folder in the root of your system drive. This folder will hold the executables and sysprep.inf files necessary to run Sysprep. Next, create a Drivers folder in the root of the system drive or under the Sysprep folder. If you want the driver files to be available after the Mini-Setup subroutine has run on the target system, create the Drivers folder in the root. (Mini-Setup is a condensed version of the Windows setup process that prompts you for configuration settings not already specified in sysprep.inf.) If you store the drivers in a folder under the Sysprep folder, Mini-Setup deletes them. In the Drivers folder, create appropriate subfolders to hold device drivers for various hardware types. The folder names aren't crucial, but grouping driver types into folders reduces the likelihood of a conflict between identically named files. Copy the third-party drivers into the appropriate subfolders, as Figure 1 shows, making sure to include all necessary files. You must then make an entry in the sysprep.inf file so that the Mini-Setup routine can find the drivers. Look at the "OemPnPDriversPath=" line in the Unattended section of the sample sysprep.inf file that Listing 1 shows to see an example of this entry. Unfortunately, directories in the path aren't traversed, so you must specify each directory individually. After you've established a gold standard base image containing the applications, settings, and drivers you want to deploy, it's time to lean on Sysprep for help with the heavy lifting.

Sysprep Magic
Plenty of information is available about using Sysprep with the imaging process for XP and Win2K, so I won't cover the fundamentals. (For an overview of the tool's capabilities and parameters, see "Deploying PCs with Sysprep," June 2002, http://www.winnetmag.com, InstantDoc ID 24877.) Instead, I discuss the Sysprep features that help make disk imaging a more useful large-scale deployment mechanism.

The most powerful functionality for stretching an image to fit different types of hardware is presented in the SysprepMassStorage section of sysprep.inf. You can manually add mass storage drivers to this section to enable systems with different disk controllers to share an image, or to hedge all bets, you can have Sysprep automatically populate this section with entries for every mass storage driver included with the OS.

The upside of the latter approach is that you can support a wider range of hardware with one image—even hardware that might not have existed in your company when you created the image. Unfortunately, it takes 10 to 15 minutes to include all the drivers during the Sysprep process, and you must provide a means for running Sysprep with the -clean option on target systems. The -clean operation, which you execute using the cmdlines.txt or GUIRunOnce methods discussed below, will prevent Windows from trying to load drivers for nonexistent mass storage controllers. To have Sysprep automatically add mass storage drivers, you must include both a Sysprep and SysprepMassStorage section in the sysprep.inf file. Create the following entry under the Sysprep section:

BuildMassStorageSection=Yes

as Listing 1 shows. To tell Sysprep to create the entries, open a command prompt, change to the directory where sysprep.exe is located, type

sysprep -bmsd

and press enter. The program will build the SysprepMassStorage section and finish silently. Then type

Sysprep -mini

to launch the final Sysprep operation. See "Deploying PCs with Sysprep" for information about other command options you can use to complete the image-building process. You can also use the standard Sysprep GUI to select the Reseal option to make final system preparations before taking an image.

The sysprep.inf file includes some other items that you should look at for their ability to streamline your imaging process and make it more effective. The UserData section lets you predefine answers to typical prompts during setup. Think of the time you'll save by not having to enter the product key each time. (Of course you still must comply with Microsoft's licensing requirements.) You can leave blank any values that you want to enter manually during Mini-Setup. If you want to share an image between multiprocessor and uniprocessor computers, you can do so by specifying either the UpdateHAL or UpdateUPHAL setting in the Unattended section. The Identification section lets you automate the process of joining a domain or workgroup. If you look at the sample sysprep.inf, you'll notice that both the DomainAdmin and DomainAdminPassword values are clear text. Because you can't encrypt this password as you can the local administrator password, you must create and specify an account that possesses only the rights necessary to add computers to the domain. Finally, use the OEMDuplicatorString setting in the GuiUnattended section to help you manage image file revisions. This setting stamps the value you provide (the string) into the registry of all systems built with that image. If you need to identify a system's source image for troubleshooting or tracking purposes, you can check the value of the HKEY_LOCAL_MACHINESYSTEMSetupOemDuplicatorString registry subkey to determine which image you used to build that system.

After honing your sysprep.inf file to perfection, you should consider the benefits that some of Sysprep's parameters offer for extending the usefulness of your images. If you still have to support legacy ISA devices, you can add the -pnp argument to the Sysprep command, which will enumerate non—Plug and Play (PnP) devices during Mini-Setup. The -factory argument lets you boot a machine into a state that lets you perform additional configuration, driver management, program installation, and testing. (The -factory option is used predominantly by OEMs or factory installers to gain more control over the end installation process.) After you run Sysprep in factory mode, you need to run Sysprep with the -reseal option to prepare for the image-creation process.

Automating Actions on the Target System
You can provide an additional level of flexibility in image-based deployments by automatically executing commands during or after running Mini-Setup. To install programs or run programs, batch files, or scripts after the Mini-Setup process finishes, you create entries in a special file named cmdlines.txt. If you need to install programs or run commands, scripts, programs, or batch files after the target system restarts, you create entries in the GuiRunOnce section of sysprep.inf.

Cmdlines.txt. The cmdlines.txt file should reside in the %SystemDrive%Sysprepi386$oem$ directory. Listing 2 shows an example of a cmdlines.txt file that runs Sysprep with the -clean option as well as two other fictional commands. The format and use of cmdlines.txt is straightforward, but keep in mind the following caveats:

GuiRunOnce. To run commands, batch files, or scripts after the target system restarts, you can create entries in the GuiRunOnce section of sysprep.inf. These entries will run the first time a user logs on to the system. As with cmdlines.txt, you need to keep in mind some rules and behaviors when using GuiRunOnce:

Imaging Software
Microsoft provides some excellent tools for assisting with image-based XP deployment, but you must use a third-party product to perform the disk imaging. My review of third-party imaging utilities "Disk-Imaging Solutions," Summer 2001, http://www.winnetmag.com, InstantDoc ID 20876, is somewhat dated, but you can read it to get a feel for how these utilities work and what features to look for. Although these tools keep evolving to automate various aspects of deployment, the primary functions they provide are capturing disk images to a file and downloading disk images from a file. When you have a reliable mechanism for performing the physical disk-imaging procedures, your entire deployment process will proceed more smoothly.

Deploy and Refine
Expect to revisit multiple times the contents of your images, your sysprep.inf file, and other processes you put in place for an image-based deployment. Often you need to try something before you know how it will behave in your environment. The best thing you can do is to learn from the mistakes and hiccups in your process, fix the problems, and try again. Every action that you can avoid or automate will pay dividends each time you use an image to deploy a new system.