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.

   Previous  [1]  2  3  Next