Background

Provide an automated method of deploying Windows XP. We have done the same thing with Windows NT for several years (we skipped w2k pro), but as noted by the NT install notes there has been a lot of pain and suffering from doing this.

One solution was to take an easy way out and just ghost the installs and deploy that way. This would solve us a lot of problems we've had with automated unattended NT deployments. Our problems we've had included:

• Slow network-killing installs. Ghost can multicast. Even if it couldn't, a desktop with 2 gigs of data would require no more than 2 gigs of network transfer. Unattended installs often have to download the same crap over and over again. For example, as the years passed, we had to do braindead install issues like installing SP6 early in the install since some programs insisted on it, then install IE, then install a package that required IE6, then reinstalled ie6 again, then installed sp6 again. Also, a typical install often required more than 10 reboots
• Unexplained glitches Sometimes an install would just not autologon during one of the automated boots and just stop at that point, leaving it unfinished. We've had cases where packages just mysteriously don't install too. This can probably be solved via better error checking in our install scripts.
• Unsupported unattended installation from vendors Many vendors, including Microsoft on some of their products, just don't support unattended or silent installs on their products. That requires us to do sysdiff packages or potentially buggy scriptit scripts. (Why, five years after Microsoft allegedly invented the zero administration kit, vendors still don't support this, I have no idea. Training techs to develop installs is often difficult and time consuming.)

However, there are numerous problems to ghosting that worry me. They include:

• Too many hardware types and local PC installation needs. While each computer lab usually has all the same machines running the same set of packages, when you get into office situations, it starts to get ugly. The fact we have about 20 different labs and hundreds of offices all needing different packages beyond the basics means we'd be maintaining hundreds of images. Which leads to...
• Maintenance of images. Say we have 100 different install images, how do we update a package or fix a bug in the install? For example, let's say we find our installation of package foo fails when a user does some function where the fix is to update an ACL on a file to make it work? We have methods and jobs to update currently installed machines remotely, but what about new installations? We either have to somehow edit the image itself, or expand it, make the edit, and then re-ghost it, or just rebuild the image from scratch. Which leads to...
• Integrity of the images. How do we assure that all these images include the ACLs, settings, and package options that we wish to be consistent across the organization? Someone has to sit there and do a manual install, answer installation questions for each package, perhaps tweak registry settings and registry ACLs, etc, etc... We could lay out a careful documentation procedure to follow but let's face it, people don't like to document, things can be left out, and the tech following the install docs to build an image may forget or accidently skip a step, making the entire image unusable.
• Microsoft's flock()ing product activation. Sysprep can help deal with deployment of images on some slightly dissimilar hardware since it triggers hardware redetection, but there's something I read on microsoft's site that mentions you can only rollback an image three times before automated product activation stops working.

The answer might indeed be a combination of best of both worlds. The nice thing about unattended installations is that it is consistent (barring stupid windows braindead refusals to connect to shares, for example), and it's self-documenting. It follows a script or batch file. If a change needs to be made, tweak the install script and all future installations will automatically get the fix. For cases where we have to roll out entire labs and having 100 machines doing unattended installs at once kills the net, we could use the unattended installation to build a disk image, then sysprep it and roll it out with Ghost using multicast.

And so, after some preliminary investigations by many, here, this 20 April 2002, we set out on another adventure, remembering well the woes and sorrows that were experienced doing the same thing with NT five years ago and the anticipated new takes of woes and sorrow that we will freshly experience all over again as well as learning how to do things all over again... Even though the computer industry moves allegedly at lightning pace, we know from experience that nothing Microsoft ever claims ever really quite works as advertised. :-(

Main XP Unattended Install Doc Page