Preparing Windows Images for Mass Deployment

The first segment of this series was titled “Slipstreamed and Unattended Windows Installations” and you can find it published here on ASP Free. In that article we  presented the popular slipstreaming strategy that allows administrators to integrate service packs, security patches, hot-fixes, and hardware drivers into the Windows installation. Moreover, tips on creating an unattended setup were also explained.

In this part we are going to focus on a different approach. Microsoft released a tool called System Preparation Utility, abbreviated Sysprep, specifically designed to “prepare the system” for use as a reference source later on for disk- or partition- cloning tasks. With the help of Sysprep, the system-specific information is eliminated from the reference system; thus it can be used machine independently as a template.

The main difference between the approach described in the first segment and this one is quite clear: slipstreamed and unattended installations are just “scripting an automated” setup: everything will be installed from scratch normally without requiring user interaction. With Sysprep, we prepare a reference image that is ready to be cloned and massively deployed on hundreds of computers of all kinds.

As a matter of fact, the second technique barely takes a few minutes if we exclude the time required while we prepare the reference source image. Once we have finished the process and we have the image ready, cloning it on a huge number of computers simultaneously (via multi-cast, for example) may take less than a few minutes because the image is written sector-by-sector on the hard drives.

Now that we understand the difference between these routes, let’s move on.

System Preparation Utility has a few requirements that should not be neglected when deciding whether it is the answer or not to our massive task. First off, the source sample computer must be from the same category as the destination systems in terms of HAL compatibility. The following list will enumerate the compatibilities.

• Non-ACPI PIC (Hal.dll) is only compatible with exactly the same HAL as itself.
  
  
• ACPI PIC (Halacpi.dll) is only compatible with exactly the same HAL as itself.
  
  
• Non-ACPI APIC UP (Halapic.dll) is compatible with both Non-ACPI APIC UP and MP.
  
  
• Non-ACPI APIC MP HAL (Halmps.dll) is compatible with both Non-ACPI APIC MP and UP.
  
  
• ACPI APIC UP (Halaacpi.dll) is compatible with both ACPI APIC UP and MP.
  
  
• ACPI APIC MP (Halmacpi.dll) is compatible with both ACPI APIC MP and UP.

Having compatible HALs (Hardware Abstraction Layer) is probably one of the most crucial requirements, but the list goes on. Plug and Play devices must include the necessary drives. Basically, all sorts of devices that may be used right away (and supposedly required for work purposes) should be supplied with their drivers; otherwise, the source reference operating system, which ends up cloned, won’t be ready for them.

The next requirement is a no-brainer: the hard drives of the destination computers must be of at least the size of the source reference computer’s. A larger size means more space, so this won’t cause any problems whatsoever. But without using the additional ExtendOemPartition key in the Sysprep.ini configuration file, the “leftover” space will be part of a separate second partition. That key expands the main partition.

Once the requirements are met, Sysprep can be used to prepare the current Windows installation from the source reference computer. This means that the utility brings that particular setup to the state that it would be in initially, right after a fresh installation and deleting system- and user-specific information such as the computer name, security identifier (SID), driver cache, and so forth.

There are numerous ways to grab a copy of Sysprep. Windows XP Service Pack 2 Deployment Tools [link] contains various other useful utilities along with Sysprep. Once you have the archive, extract its content to a folder called “sysprep” on the partition and/or hard drive on which the reference Windows can be found. This must be respected, otherwise Sysprep won't be able to find its configuration files.

Before starting the utility, you should prepare the reference Windows OS. Update the necessary hot-fixes, security patches, and even service packs if necessary. A new user template may be created, if that’s what you want, for default account settings. However, if the computers will join a domain right after they have received the deployment, then this part can be skipped. Otherwise, you should install applications in the template that will act as default account.

In general, it is advocated to configure that template account in great detail because it's going to be used as default user account later on. Therefore, settings regarding Internet Explorer, Windows Explorer, the Start menu, the desktop, and System settings (such as virtual memory, restore points, etc.) shouldn’t be forgotten. This step can be skipped, however, if computers will join a domain where policies are enforced.

Moreover, there’s an extra utility that does an amazing job of enumerating all of the drivers of an existing Windows OS. It’s called SysPrep Driver Scanner (1.3.1). It is a nifty free utility; it’s useful because you will know exactly the necessary drivers that should be incorporated into the sysprepped reference source Windows OS as well.

And even better, it does the job all by itself. It adds the necessary entries for those drivers into the registry so that Sysprep, using –mini-setup, will search for(and find) the drivers, and as a result, include them in the sysprepped installation. This eliminates the need for you to fiddle with OemPnPDriversPath in the Sysprep configuration file (sysprep.inf) that should be manually edited to add the path of drivers.

Now it’s time to configure Sysprep before the process, because the reference OS is ready. You should have the “sysprep.inf” answer file located in the Sysprep folder. That is a sample answer file, which is going to serve as a configuration file, in a sort of INI-like fashion, containing headers and keys with values. You can either modify the sample file or create your own with “setupmgr.exe” (Windows Setup Manager Wizard).

There are various ways to launch sysprep; it supports a lot of parameters with which you can alter its behavior. Each is thoroughly documented by Microsoft. But an amazing batch file can be found at the Vernalex website. You may check it out here. This batch file automates useful tasks such as cleaning up driver cache, flushing data to disk, closing SMB connections, and terminating unneeded processes and services.

Once everything is completed, Sysprep is executed in the following fashion.

start sysprep -reseal -mini –quiet

It should be noted that this process can take from 5-10 minutes up to 30 minutes and even more. You will surely notice this as the computer starts to work hard. After sysprep finishes its activity, the computer will shut down. This is when you need to create an image with your favorite disk- / partition-cloning utility. You just boot up with that utility, such as Clonezilla (read the article published at DevShed) and get the job done.

This is critical: you should not let the computer boot up in Windows before you have created the clone image, otherwise that half an hour (or more) of work becomes worthless, because the mini-setup will begin (which takes barely a few minutes) by asking the user those “user-specific” details, and then the Windows OS will be ready to use.

And no, you don’t want this to happen. You want to clone before this happens—because you want this aforementioned mini-setup to start for each user after you have massively deployed the clones. You see, that’s the entire process in a nutshell.

On this page we are going to mention some practical guidelines along with details on how to use and work with Sysprep. But we must admit that Microsoft has done an extremely good job documenting these deployment tools. You should definitely read this official documentation before moving further. It explains the entire process again.

Deploying Windows Vista (via this Sysprep technique) isn’t that different and can be easily understood by reading this step-by-step guide. A major distinctive difference is that answer files can be created with a wizard called Windows SIM (System Image Manager) under Vista just as you could with SetupMgr with Windows XP. Configuration files use .xml extensions (i.e.; sysprep.xml).

Moreover, with Vista there’s an additional imaging utility called ImageX. You should read its user guide too. Hopefully you understand by now that preparing Windows installations to be massively deployed later on isn’t such a tough task; it is just pretty detail-centric. Everything lies in those details. Understanding the process isn’t hard because it clearly makes sense. However, applying them can become tricky.

Each tiny little parameter can totally alter the behavior (and therefore, the end result) of each process. So ultimately, you may want to research, study, and then practice a lot until you finally figure out a routine that works for your own needs. As well, it may be helpful if you experiment a bit with different options, even if you succeed right from the beginning. Who knows?—another option might be even better…

As you can see, we have arrived at the end of this second and final part of this series. By now you should be more than familiar with two of the most common (and probably the easiest and most straightforward) strategies that can save lots of time for us, money for the organization, and perhaps even alleviate possible sources of frustration.

I have placed an emphasis on understanding the “inner workings” of these two routes, because knowing what happens behind the scenes helps us make better decisions when facing dilemmas or simply troubleshooting some weird nobody-ever-heard-of issues. Practice makes perfect; you may struggle at first until you successfully forge your first images and all that, but after that—it’s all routine, productive routine.

All in all, the purpose of this article series was to inform you about the possibilities of these two paths that could be taken when massive deployment of Windows operating systems is required. Surely, there are other possible ways as well. But these two are among the most popular and effective. Ultimately, all that we could do is give you a brief overview of the tools. For deeper understanding you need to do more research.

Speaking of the disk and partition duplications, not too long ago I published an article titled “Clonezilla: Free Mass Disk-Cloning Utility.” It is truly an open source application that performs; think of it as the Symantec Norton Ghost Enterprise suite “on steroids.” And best of all, it’s free. Be sure to check it out!

And finally, we can’t really finish without inviting you to join our helpful forums at DevHardware Forums. We’ve a strong base of resident professionals, enthusiasts, and tech experts. If you want to hear opinions on some service or ask some clarifications regarding some details just shoot us your questions. We’ll do our best to help. And you should also want to pay a visit to the forums of our “sister:” DevShed Forums.