Advanced XP Install – Complete Automation using CD and Network Share – My Complete Process with Code

Download

If you wish to follow this article, please download the code behind it all here. Some of you can likely piece it all together by looking at the code alone, others can use my help below to gather how it works.
XP_Automation.zip (1.22mb)

Quick Introduction

This one is a large subject, considering how much work I’ve put into it. While everyone is feeling the push away from XP, a few parts of this guide may come in handy for people working with other projects. For anyone still on XP, they can at least steal some tricks or tips from what I found worked best.

I support 400+ desktops, co-workers hit around the number as well. Originally when arriving the practice was Ghost images of each model. I preferred a more dynamic approach to this. Working with 50+ images is no fun task. You’re never ‘done‘ when working with an image too; Software gets out of date, new software needs implementation, and there is always something customized on a per-user basis. Sysprep was tried, but after many headaches trying to get a *single* universal image, it’s just never that easy. While sysprep may work for you, provided you make an image for each HAL. As someone with a programming background — Yuck. I’d still have redundancy! You can also fiddle with something such as MySysPrep, however with a large amount of different systems it just never worked well enough, and had too many problems.

High Level Details

At a very very high level: Install XP off CD, let a network share do the rest. Pros being extremely dynamic compared to conventional means, and far less management time once going. Cons being initial setup, and longer deployment times. As far as the ‘longer deployment’, I could care less, usually newer systems are never critical to the point where they have to be done in an hour. There’s practically no overhead, so I can work away on other problems while the process does its job.

Here’s how I did it. I’ll break down into details later. First, I get an OEM Windows CD with no modifications, I slipstream XP Service Pack 3 into this to bring it up to date if it isn’t already. Followed that, I run Windows Updates Downloader (WUD) and download as many patches as I can, essentially these are downloadable Windows Updates. Next step in the process works with nLite. I use nLite to integrate those patches onto the Install CD, as well as Windows Media Player 11. nLite is also very handy in customizing almost anything that can be set in Windows. I use nLite sparingly as I like to keep things as dynamic as possible. I use nLite only to change values I know I’ll never change again (i.e. DNS settings, removing Windows Messenger).

While anyone could stop there and call it a day, I was not happy with that alone. One thing you’ll have troubles with nowadays with a regular OEM XP Cd is drivers. I use DriverPacks to inject LAN and Mass Storage (text-mode) drivers only (this keeps it a size able to fit on a cd). Lastly, I add a start up script to the $OEM$\$1 directory and apply a WINNT.SIF (answer file) within the CD.

How is this Dynamic? This part isn’t, however VERY rarely does the final result of this ever have to be touched. I only touch up every few months with a new CD if there are new drivers available. The next part is the part that really, really helps.

Once Windows is set up, the last thing it does is call a network script through a Windows or Linux File Share (Samba). I install all programs, all patches, all registry adjustments here. This makes a SINGLE point of contact for any fixes. With SysPrep/Ghosting, you have many different images, if one seemingly simple update has to be applied, it can turn out to be a real burden. Using a network share, dropping in the file, and one line of code to a script, and I can call it a day. Of course this is nothing to marvel over in today’s world, but it worked well.

My remote script would do the following:

• Determine if it was being used in a development environment or production environment. File shares are easy to make, and having two provides backup in a sense, and allows for a dev/prod environment where testing can safely happen.
• Run any side scripts/registry keys.
• Install latest drivers.
• Install every program needed with no user interaction. Up to this point, since starting the CD there has still been NO user interaction.
• Install the latest windows updates, without needing WSUS or a ‘push’ including reboots between patching.
• At the very end, it would beep three times to notify the user it was complete. It prompt’s for a computer name, ejects the CD, and displays any changes made to the script recently.

The only user interaction needed is at the very beginning to toss in the CD to start it up, literally a single keystroke. Once done, just computer name was needed, and to remove the CD.

How It Works – In Depth

1. Working Directory

1. Windows Updates Downloader

Next step I do, is boot up the WUD I mentioned earlier and download the latest patches it offers. This does not get all the updates, but it helps with deployment time, and is easy to do. I install WUD right to this directory so I just hop in the directory, boot up the program, get the downloads, and exit.

2. Select Base

At the very start up of making this folder structure I dumped the Original CD (In my case XP SP2) into this. Because I needed XP SP3, I slipstreamed that into a copy of SP2 and have that as well.

You can see that I have ‘unessential removed’ within a name. This is because many of the files on the XP CD are not needed for clean installs and you can cut down on the size of the CD significantly. I removed folders cmpnents, SUPPORT, VALUEADD, and I386/WIN*. If  you want to know what these do, look here.

In terms of the ‘assembly line’ process, in this step I copy whatever clean slate of XP I need into the working directory which will serve as my new CD.

3.1 nLite and 3.2 WMP11 Slipstreamer

I installed nLite to this directory. Run it, select the windows you copied into the Working Base folder. nLite is the tool you use to add the updates from WUD, and any other changes. This is well documented by nLite so I will not go into detail here. This can also be used to slipstream SP3. Drivers can be added here, but refrain from using them as they will be handled later. Not every patch or utility may want to apply, as they were not made for slipstreaming. Do what you can to get as many slipstreamed.

Also here is WMP11 Slipstreamer which works as part of nLite, if you want WMP11 to be integrated into the CD. This is labeled 3.2 as it works in part with nLite.

4. DriverPack

This is a very handy way of getting Drivers in using DriverPacks.net utility. Download DriverPacks Base, and it will gather the latest drivers for you into a folder.

This serves two purposes:

1. Will apply updated drivers to your Windows XP Customized CD we are building so that it has additional network and mass storage drivers. Without newer drivers many systems will blue-screen with 0x0000007b (drive read error). Network drivers are added because they are essential to starting up the remote script once windows is installed. When adding drivers ONLY add these two (Mass Storage TEXT MODE, and Network). Any more will balloon the CD, and we can install the others later.
2. Driverpacks can handle audio, network, mass storage, and more. We can use this to create a ‘Stand-Alone Install’ for the remote script to finish the Drivers after the CD has done its job.

For this step, slipstream the network/mass storage drivers into the Working Directory CD you are building. Also, you’ll want to create a ‘Stand Alone Install’ with all drivers (sans ‘text-mode-setup’) and dump them into the XPCD-Share folder.

5. File Additions

This step, quite simply, is where I put any file additions that must happen to the working directory as part of the build process. In this step, I just copy the files inside to the current build folder within the working directory. I use two directories for my process.

I386 Directory – I have a I386 folder here which contains nothing more than the WINNT.SIF file. The WINNT.SIF is just a windows answer file. See below for one that I used. This one is for full automation, it repartitions and formats the drive without user intervention. I left important values with !! in front of them for changing. Use the reference link above for WINNT.SIF values and go through them to adjust any settings. Take special note of the %systemdrive%\WIN_SETUP\WIN_SETUP.CMD which starts the script that will go into the $OEM$ directory explained below.

$OEM$ Directory – This directory goes directly under the root folder of the current build, not within I386. MSFN explains this folder in detail. Originally used for cmdlines (I no longer use those) this folder now just houses a couple of files. The files put into this will start the remote share script for installing all programs. I use two files here. One for simply starting another batch file, and one that actually starts the work. This is done as windows will not fully log in until the first batch is complete, so the work is done in a new batch that Windows isn’t ‘tied in’ with.

Taking a look at WIN_SETUP_2 batch file, here is where it dynamically differentiates whether to use DEV or PROD server. If you, for now, just want to use a single server, simply change ‘SET FILESTORE_ADDY’ to the IP with the computer hosting the share and remove the rest of that code in that section. If you want to use a DEV and PROD share, I suggest trying to leverage the code I supply there.

A feature of the utility is that it will retry to connect to the share if it can’t. This is there for two reasons, its handy if you don’t have a network cable in the computer yet, and if the computer needs a network driver, you can let this run minimized while you get networking going, then you can walk away. The code will beep three times to get your attention if it can’t connect.

The script will map the network drive to drive Z: which will serve as the letter for the rest of the run.

6. CD Image

If you have gotten this far, you are ready to get an ISO of the CD together. CDImage is a free utility that will remember past settings for doing so, so usually this step is just opening the program and clicking create image. The link above includes the download and instructions from MSFN, a great resource.

I recommend using a VM to test the ISO with, to cut down on blank CD costs!

7. XPCD-Share

I won’t lie, this is the hard part. But it pays off in the end. All the little tweaks and trying to figure out how to get programs to install by themselves requires research on your end. However I can help with a few essential parts by showing the code I used. I will be uploading a slightly stripped down version, excluding items that most people will not ever find a use for. Hopefully this won’t overwhelm many people. If it does, you can at least leverage some parts of it that makes sense to you. This folder must be shared as xpcd-share, it is what WIN_SETUP_2.CMD (placed on CD in step 5) connects to. Here’s the detail on the script process:

1. Windows CD finishes install and comes up to user login
2. Windows answer file (WINNT.SIF) contains automatic login information and logs in.
3. WIN_SETUP_1.CMD runs, according to the [GUIRunOnce] section, also the drivers slipstreamed into CD are cleaned up.
4. WIN_SETUP_1.CMD *starts* WIN_SETUP_2.CMD and exits.
5. Windows logs in, and WIN_SETUP_2.CMD connects to the remote share, and starts WIN_POST_LOGIN.CMD

WIN_POST_LOGIN Begins

1. Call’s _Header.bat to import the IP of the share it connects to. _Header.bat reads this from a file containing the IP generated by WIN_SETUP_2 from step 5.
2. Run’s any other batch files needed (in my file I use the Microsoft batch to block IE 8.0 from being downloaded). start /wait is used, as its much safer to ensure code is executed sequentially, rather than all at once! The same idea goes for the Registry changes which are straight forward.
3. Driverpacks are copied over locally, then executed. Running remotely has often created problems.
4. Resolution changes, however this is nothing important. If you must, you can download it here. Keep in mind that you’ll have to change the path depending on how you lay out your folder. I found this is useless half the time because of driver installs resetting the resolution. This could be placed in RESTART_FINISH.CMD if wanted.
5. Program installs. This is going to be a large portion of set up. I’ve left common ones in there that most people might find useful. Prior to installing, I copy over installation files that must be run locally. Office installations require MST files to be created which is out of the scope of this article.
6. Unnecessary shortcuts are removed. If you want to add shortcuts you can try finding this Shortcut.exe file, or use the VBS file provided there. I added a shortcut to a batch for opening up a share that had write privileges for allowing techs to upload/download drivers from a repository that proved quite handy.
7. Some programs require home-brewed Auto-It‘s to move them along. I used some of my own here.
8. The program copies over more tools, but directly to the desktop for helping Techs. Here two of my own applications are moved over. One for detecting names of ‘Unknown Devices’ for any devices still needing drivers (you can find that on this website!) and a Novell Autologin utility. CPU-Z is handy for finding the Motherboard make, and other useful tidbits, without having to pry open a desktop to look inside just to figure it out.
9. The last portion copies over any scripts that will be running locally on reboot to start finishing the install. Also very important, the registry changes add an autologin count of 5. This is for future reboots needed with Windows Updates. A reasonable number here is given in case of an infinite loop, which I have not seen yet. The Windows updates script will terminate the loop when it senses there are no more updates. The script adds WIN_REBOOT.bat as the next reboot startup script.
10. Reboots with a time delay, and removes the Z: drive. The mapped drive is always removed on reboot, it appears to work MUCH better this way rather than having a persistent connection.

WIN_RESTART Begins

1. Reconnect to share.
2. This is a bit overkill but helpful. I check for a temporary file used as a flag for whether or not I’m done this part of the script. If it’s not there, I run two Auto-Its. One to open up Office 2003 and close it. And then one to open Office 2007, have it go through its couple-minute long first time run initialization, select defaults, then close it. Then it creates a file so that next time, it won’t do this. This is here because even with a Silent install of Office they both have some stupid first time initialization junk I don’t need my users to go through. Also, Office 2007 will NOT get any updates unless it is started up and selected that you want to do that, by default.
3. I also have a script for automating the Genuine Advantage program that will inevetiably show up when running the Windows Update Script. This runs in the background every reboot for when it finally shows up.
4. The complicated Windows Updates. All taken care of by a nice (slightly modded) VBS script provided from Microsoft in some obscure part of their website.

WIN_RESTART_FINISH Begins

1. Disables the AutoLogin and removes start-up script references in registry.
2. Beeps to notify technician the task is complete.
3. Runs rename computer prompt (RenameComputer.vbs)
4. Ejects CD (EjectCD.vbs)
5. Removes Network Drive
6. Runs a window that shows techs latest changes to remote script, any known bugs, any reminders etc. I use a utility XEcho.exe which allows me batch formatting and colour.
7. Cleanup: Removes mapped drive, deletes temp files in WIN_SETUP dir. This is done multiple times along with delays to ensure its toasted.
8. Deletes itself.

Ending Notes

This article is incomplete, and the files available still require tweaking (passwords, network ips, etc). I still have yet to build up an environment to double check the files will work, as I’ve had to adjust/remove details. I should have time in the future to upload any other beneficial parts, such as silent install commands for various other programs. In the meantime, I hope this article has served you well.