Sysprep can help administrators further streamline the process of cloning client systems with Symantec Ghost.
Many administrators have discovered that Symantec Ghost Corporate Edition can be used to reduce the time it takes to deploy new workstations. While there is no doubt Ghost is a great time saver, it does have a few limitations that must be considered when it's used as a rollout tool. I'm going to show you a technique for using Microsoft’s Sysprep tool to work around the limitations of Ghost and reduce the number of images needed for deployment.
What are the limitations of Ghost?
Ghost creates an image that is an exact duplicate of a system. This means the system’s name and Windows security ID (SID) are copied. This is great for backup purposes, but not good in a network environment. Two systems cannot exist on the same network with duplicate names and SIDs. Ghost ships with a tool called Ghstwalk that can create a new SID after an image is made. The other issue is that the systems being cloned must have identical hardware and software. Otherwise you end up reinstalling drivers and software or creating multiple images for each hardware and software configuration you have in your environment.
I have been using Ghost in my work environment for over four years. Every new system that arrives is loaded with our standard image. Over the years, the system's hardware and software has varied. Each new shipment of client computers brought slight hardware variations, such as different video, sound, or network cards.
At first, we used the same image and followed up by correcting the image. This took more time and soon defeated the purpose of imaging. Next we began to create multiple images for each hardware variation. Soon this became a nightmare to manage. Enter Sysprep, which allowed us to reduce our number of images to three.
The concept of Sysprep is simple. Sysprep is run prior to creating a master image. It prepares the system to be cloned by removing the SID and computer name and can be further customized by manually editing the sysprep.inf file. The system is then cloned and a Sysprep image is created. After a new system is cloned with a Sysprep image, a mini-Setup Wizard is launched and the imaged system is renamed and further customized.
Sysprep has been available since Windows NT. To use Sysprep with NT, you had to be participating in Microsoft’s select program. Those restrictions were eliminated with Windows 2000.
There are separate versions of Sysprep for Windows 2000 and XP. Sysprep is included in the Windows 2000 and Windows XP Resource Kit tools. An updated version (1.1) for Windows 2000 is available on Microsoft’s Web site. The examples in this article are from the Windows 2000 version. However, the basic usage and concepts are the same regardless of the version.
Once downloaded and extracted, the package breaks down into the following components:
- Docs—This involves documentation on using Sysprep and unattended installation. Also included are separate text files listing PNP IDs for various mass storage controllers that ship with Windows 2000/XP. In addition to this documentation, Microsoft has multiple Knowledge Base articles on using Sysprep, which you can access by doing a search on the Microsoft site.
- Samples—This includes sample sysprep.inf files for both SCSI and IDE mass storage controllers.
- Tools—This is the Sysprep tool and two supporting tools, setupcl.exe and pnpids.exe.
Using Sysprep properly requires some research and planning. Early versions of Sysprep required that each system being imaged have the same mass storage controller as the system that the image was created from. This limitation was eliminated with the Windows 2000 version. However, you still have to do some planning.
First, you must identify the mass storage controllers in the systems you plan to image. The Sysprep package contains a tool called pnpids.exe that assists in identifying the Plug and Play ID used by Windows to install the proper controller. To use the tool, open a command prompt and change to the Tools folder (where you downloaded Sysprep). Enter the command pnpids.exe %windir%\inf | more. This will produce a list of the PNP IDs as well as the common names. The names and IDs are added to the mass controller section of the sysprep.inf file.
If that sounds like too much work, you can cut and paste the list of controllers from the sample .inf files provided, and Sysprep will try each one upon boot-up. This increases the initial boot-up time, but saves the headache of figuring out each device if you have many hardware variations. If you use this method, you'll also need to start Sysprep with the –clean switch, or Windows will attempt to load each controller driver upon subsequent startups.
Sysprep has several switches that you should learn:
- –nosidgen—Sysprep runs but the SID is not changed. This is used if the cloning program will handle changing the SID.
- –quiet—The mini-Setup Wizard runs with no user interaction. This is used with an answer file.
- –noreboot—The system will not reboot after Sysprep runs.
- –pnp—This forces Plug and Play detection during the mini-Setup Wizard.
- –clean—This removes unused mass storage controller drivers.
To use Sysprep, you must create a sysprep.inf file. Several sample files are included in the download. These can be used as a reference and modified as needed. The easiest method is to use the Windows Setup Manager tool (Figure A). This tool is available in the Windows 2000 Resource Kit (there's also a copy in the \Support\Tools directory on the Windows XP CD) and is used to create an unattended answer file for automated setup; it can also be used to create the sysprep.inf file.
The Setup Manager tool can configure Sysprep to fully automate the setup process (Figure B), or prompt for a few basic items such as machine name and joining a domain.
If you plan to use Sysprep to change the administrator password or join a domain, the passwords will be stored in the sysprep.inf file. This presents a security risk, since the sysprep.inf file is a plain text file. The file is deleted after the setup wizard runs. These risks have always been present when performing an unattended install. When the sysprep.inf file is complete, it will look like a standard .ini file (Figure C).
The documentation details the available keys that can be used in sysprep.inf. In my environment, I launch the Symantec Antivirus software after cloning by adding the path to the executable in the "GuiRunOnce" key. The Corporate Antivirus product does not function properly if has been cloned. In addition, I start Sysprep through a separate commandlines.txt file that launches Sysprep with the –clean switch. This procedure removes any unused mass storage controller drivers. This process is outlined in a supporting document in the Sysprep package titled “Image Maintenance: Reducing the number of master images required.” The commandlines.txt file can be used to launch additional programs or commands at the end of the mini-Setup Wizard.
For Sysprep to function correctly, it must be stored in C:\sysprep on the cloned image. In addition, the support files setupcl.exe and sysprep.inf must be present in the same folder. The folder will be deleted upon completion of the mini-Setup Wizard.
The primary drawback to the Sysprep and Ghost combination is still the issue of dealing with hardware variations. Sysprep reduces this limitation by allowing Plug and Play to force hardware detection with the –pnp switch. This works fine as long as the drivers are contained on the Windows 2000/XP CD. Otherwise, you must preload the drivers on the image and supply sysprep.inf with the path to the driver files.
On my network, I have hardware that spans a five-year period. Most of my older hardware is supported by Windows 2000, so the devices are detected and installed with few complications. The new hardware is typically supported, but the drivers are not present on the Windows 2000 installation CD. To work around this, I use the newer hardware to create my images, and when these images load on the older machines, the proper drivers are loaded as needed.
In my environment, I once had as many as 60 different Ghost images for each hardware variation that existed in our desktop and laptop inventory. After each image was loaded, we would rename the machine, join it to the domain, and perform any additional tasks as needed. Using Sysprep together with Ghost has reduced the time it takes to prepare a new system and has reduced the number of images we maintain to three standard images.