Editor's Note: Portions of this article were adapted from The Definitive Guide to Windows 2000 Administration (Realtimepublishers.com).
Disk-cloning software represents a major step in the evolution of OS deployment automation. With disk-cloning tools, you can configure a master system, complete with configured OS and applications, create a binary image of the system installation (i.e., create a "picture" of the disk's contents), then duplicate that image on other systems. Some utilities even let you multicast an image over the network so that multiple PCs can simultaneously receive a disk image from one or more source servers.
Although these utilities have proven handy for many IT shops, they aren't problem free. Disk-cloning utilities raise concerns about security and machine uniqueness (e.g., SID duplication). Despite these concerns, the tools' overwhelming popularity within the IT community showed Microsoft that disk-cloning products (and their potential problems) aren't about to go away. So Microsoft has embraced the technology and developed the System Preparation tool (sysprep.exe). Sysprep augments rather than replaces the functionality of disk-cloning software and makes using disk-cloning software more efficient and safer.
Disk Duplication Demons
Disk-cloning utilities have been lifesavers for network administrators who need to deploy large numbers of workstations on their networks. But disk-cloning software presents two major problems. First, these utilities require the reference machine (i.e., the machine from which you create the image) to have a virtually identical hardware configuration to the target machine (i.e., the machine that receives the image). Otherwise, you're likely to see a blue screen when you start up the cloned machine. Considering the fairly short life cycle of most PC hardware and the variety of hardware that exists in most companies, this shortcoming limits the usefulness of disk-cloning software.
Second, and more important, disk-cloning software creates a significant security problem when you use it on Windows XP, Windows 2000, and Windows NT systems. When you install these OSs, the installation process assigns the system a unique SID. Because disk-cloning software duplicates the reference machine's disk image after that machine has been assigned a SID, the target machines' SID will be identical to the reference machine's SID.
To understand why SID duplication creates a security problem, consider that each system in an XP, Win2K, or NT environment generates a unique SID that's associated with all the local user accounts. Two machines that have the same SID would assign the same SID to all new user accounts you create on those machines. In this situation, Windows will see the resulting user accounts as being the same—regardless of any differences in the usernames. For example, if you gave the shipping clerk a machine based on the same disk image as the machine you gave to the head of your Accounting department and both users created a new local administrator account on their machine, the shipping clerk would have rights to access anything that the Accounting department head's local user account could access.
Postduplication SID Switching
Disk-cloning software vendors offer a solution to the SID-duplication problem: SID-changing utilities that can modify the SID on a cloned machine. However, I've found that many of these utilities cause residual problems, and many fail to change the SID that's referenced within the registry and file system.
Also, be aware that Microsoft supports cloned machines only under limited circumstances. You need to have cloned a machine before the SID assignment or in conjunction with Sysprep for Microsoft to support that machine. For more information about Microsoft's support of cloned systems, see the Microsoft article "Do Not Disk Duplicate Installed Versions of Windows" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q162001).
Sysprep to the Rescue
Unlike postduplication SID-changing utilities (such as those that ship with most disk-cloning utilities), Sysprep restores machine uniqueness by letting you roll a reference machine back to its pre-SID state after you install all desired software. The first time you start a reference machine after running Sysprep on it, the machine will return to the last stage of the Windows setup process (i.e., the machine and network identification stage), in which the SID is assigned. (Don't run Sysprep on a production system: The utility removes critical configuration information and effectively rolls the system back to a state prior to setup completion. Run Sysprep only on reference systems that you've intentionally set up to provide a template system configuration.)
A benefit to using Sysprep with disk-cloning software is that Microsoft supports machines that you use this method to deploy, so you won't be out of luck if you need to call Microsoft Product Support Services (PSS) for help with a cloned system. I've found that systems cloned from Sysprep-prepared reference systems exhibit fewer problems than do machines created with the disk-cloning and SID-changer utility method.
If you support NT machines and want to use Sysprep, you'll find that getting the NT 4.0 version of Sysprep (Sysprep 1.0) isn't easy. Although the utility is free, Microsoft doesn't make Sysprep 1.0 available for public download from the company's Web site, forcing users to submit a special request for the utility. Furthermore, only Enterprise and Select Agreement customers are eligible to use Sysprep 1.0. If your organization is an Enterprise or Select Agreement customer, take one of the following steps to obtain Sysprep 1.0 for NT:
- Make a request on Microsoft's Request License for System Preparation Tool Web page (http://www.microsoft.com/ntworkstation/deploy/deploytools/requestlicense.asp).
- Fax a request to Windows Deploy Tool License Agreement Request at 206-285-4403 (United States and Canada only).
- Leave a voicemail message with your request by calling 800-394-9621 (United States and Canada) or 206-378-5544 (international).
Sysprep Grows Up
Because SID-duplication problems still exist under XP and Win2K and disk cloning continues to be a popular deployment method, Microsoft updated Sysprep to a Win2K-compatible version—Sysprep 1.1, and an XP-compatible version—Sysprep 2.0. (I discuss Sysprep for XP later.) Fortunately, these new versions are much more accessible. You can download Sysprep 1.1 for Win2K from Microsoft's Web site at http://www.microsoft.com/windows2000/downloads/tools/sysprep/download.asp, or you can access the tool from the Win2K installation CD-ROM's deploy.cab file (which resides in the CD-ROM's \support\tools folder) or from the Microsoft Windows 2000 Server Resource Kit. Figure 1 shows Sysprep 1.1's first dialog box.
To use Sysprep 1.1 to manually duplicate and deploy a Win2K system, follow these steps:
- Install and configure the reference machine with Win2K and the applications you want to include. Don't join the system to any domain, and leave the local Administrator password blank.
- Verify the system configuration and remove all extraneous files that you don't want included in the disk-imaging process.
- Create a directory and name it Sysprep in the root of the reference computer's C drive (e.g., C:\sysprep).
- Extract sysprep.exe and setupcl.exe from the \support\tools\deploy.cab file. If you'll use a sysprep.inf answer file for your manual installation, copy the file to the Sysprep directory as well. (I discuss sysprep.inf files in the next section.)
- Run sysprep.exe on the reference machine to prepare the disk for duplication.
- Use disk-cloning software to duplicate the desired disk partitions.
- Use disk-cloning software to deploy the reference machine's disk image to one or more target machines.
- Boot each target machine that has received the disk image, then complete the installation by following the screens that the Mini-Setup Wizard displays.
Sysprep.exe has a few optional parameters that you might want to use. In Win2K, these parameters are
- quiet. The -quiet parameter forces Sysprep to suppress the display of confirmation messages so that a user doesn't need to respond to the messages. If you plan to run sysprep.exe right after an unattended setup process, for example, add the command
to the \[GuiRunOnce\] section of the sysprep.inf file.
Using Sysprep with an Answer File
A drawback to the standard Sysprep method is that it requires you to manually answer the questions that the Mini-Setup Wizard asks. To improve the automation of a Sysprep deployment, you can use an answer file to automate the responses to the wizard's questions. (For information about answer files and unattended installations, see Robert McIntosh, Windows 2000 Ready, "Automating Windows 2000 Installations with Sysprep," http://www.winnetmag.com, InstantDoc ID 8861, and "Windows 2000 Automated Installations," InstantDoc ID 8767.) The default Sysprep answer file is called sysprep.inf and uses a subset of the sections found in typical unattended answer files. You can place sysprep.inf either in the C:\sysprep folder along with sysprep.exe and setupcl.exe, or on a floppy disk. (If you use a floppy disk, you must insert the disk in the floppy drive after the Windows startup screen appears and before the Please Wait Mini-Setup Wizard screen appears.)
Using Sysprep answer files isn't an all-or-nothing prospect. If you choose not to or inadvertently neglect to complete one or more sections within the answer file, the wizard presents the corresponding screens to the user to complete during the first system reboot. Thus, if you want to create a fully automated deployment for your users, be sure to complete each relevant section within the sysprep.inf answer file. Table 1 lists the sections and parameters of sysprep.inf that relate to a variety of wizard screens and includes some sample values. (In some cases, more than one section of sysprep.inf can have values that relate to a particular wizard screen.) Listing 1, page 44, shows an example of a Win2K-centric sysprep.inf file to be used with Sysprep 1.1. This answer file automatically answers all Mini-Setup Wizard questions except for those in the regional settings dialog box (which will thus be the only screen the user sees).
Sysprep XP Style
The XP version of Sysprep is included in the \support\tools\deploy.cab file on the XP installation CD-ROM. Registered Microsoft OEM system builders can also find the utility in the XP OEM Preinstallation Kit (OPK). For information about the OEM System Builder Program, go to http://www.microsoft.com/oem. For more information about the XP and Win2K versions of Sysprep, see the sidebar "XP and Win2K Sysprep Resources."
The general capabilities and usage of Sysprep 2.0 are much the same as with the Win2K version, although Microsoft has thrown in a few new goodies. One such improvement is the ability to add new or upgraded drivers to an installation image. The XP version of Sysprep also includes several new modes of operation: Factory, Audit, Reseal, and Clean. Although Microsoft designed these modes primarily to meet the needs of OEM system builders that preinstall XP on their systems, the modes will also appeal to some enterprise IT departments.
Factory mode. Factory mode is designed for OEMs and lets them customize Windows OS installation in a manufacturing environment by using a Bill of Materials (BoM) file. The BoM file, winbom.ini, contains multiple sections (similar to sysprep.inf) whose parameters let OEMs automate activities such as software installation, driver updates, registry modifications, PnP enumeration, and configuring a computer with customer-specific data. Factory mode reboots the system into a network-enabled state under which OEMs can automate building and changing the winbom.ini file. Before OEMs ship the machine to a customer, they must use Reseal mode to invoke Sysprep and complete the system-building process. The flexibility of Factory mode lets OEMs reduce the number of master disk images needed to support their customers.
Audit mode. Audit mode lets OEMs run auditing and testing tools on an XP system while they're preparing the system in the manufacturing environment. Audit mode is designed to run after Factory mode. Unlike Factory mode, Audit mode doesn't generate new SIDs or process items in the \[OemRunOnce\] section of the winbom.ini file. Audit mode also provides a system reboot (after Factory mode customizations are complete), which might be necessary to complete hardware and software installations that OEMs invoked in Factory mode.
Reseal mode. Reseal mode is a companion mode to Factory mode that OEMs invoke after they've completed the changes in Factory mode and are ready to prepare the computer for delivery to a customer. When resealing the machine for delivery to a customer, OEMs can specify whether the user will see XP's new Windows Welcome Out-of-Box-Experience (OOBE) screens (the new wizard-based setup screens that XP users typically see when they first boot their systems) or the Mini-Setup Wizard (the first-boot setup screens users see on Win2K systems prepared with Sysprep). You specify the first-boot screen by adding either the -msoobe parameter (for the XP-style setup wizard) or the -mini parameter (for the classic Win2K-style setup wizard).
Clean mode. Clean mode forces Sysprep to clean the critical device database, a registry listing of devices and services that must start before XP can boot successfully. After the setup process is complete, Sysprep clears the database of any devices that it determines aren't physically present on the system. To invoke Clean mode, you use the command
If you're an OEM system builder or would simply like more information about these new OEM-centric modes, check out the ref.chm file, which resides in the XP installation CD-ROM's \support\tools folder, as well as the documentation that accompanies the XP OPK.
To support its new operational modes and assorted other new features, the XP version of Sysprep also provides a larger array of command-line parameters than previous versions do. I covered some of these new parameters earlier; here's a rundown of the others.
- activated. The -activated parameter forces Sysprep not to reset the grace period for Windows Product Activation (WPA).
- forceshutdown. The -forceshutdown parameter shuts the computer down after the Sysprep process is complete. This option is intended for use with systems containing an Advanced Configuration and Power Interface (ACPI) BIOS that doesn't shut the system down properly during the Sysprep process.
- mini. The -mini parameter configures XP Professional Edition to present to the user the Win2K Sysprep-style Mini-Setup Wizard welcome screens rather than XP's new Windows Welcome screens during the first boot. (This parameter has no effect on XP Home Edition, in which the first boot always displays the XP Windows Welcome screens.)
- noreboot. The -noreboot parameter modifies various system registry values (e.g., the SID, the OemDuplicatorString) without rebooting the system or preparing it for duplication. You typically use this option to test whether the registry is being properly modified. Microsoft doesn't recommend using the -noreboot parameter in production environments because the resulting changes can invalidate the Sysprep preparation.
- reseal. Use the -reseal parameter to complete the factory preinstallation process. This parameter clears the system NT Event Viewer logs and prepares the system for customer delivery. If you run Sysprep in Factory mode, you must reseal the installation as the last step in the preinstallation process, either by running this option or by clicking Reseal in Sysprep's GUI, which Figure 2 shows.
An Invaluable Deployment Tool
Sysprep is a useful tool if you regularly perform disk-image cloning of your XP and Win2K systems. In addition to being the Microsoft-supported and recommended method for using disk and system cloning, Sysprep is complementary to most disk-imaging and cloning tools and works with these tools to prevent the duplication of unique information that could potentially lead to functionality or security problems. If you use disk cloning as part of your deployment methodology, I highly recommend checking out Sysprep.