Remote installation scripts as created by Windows Setup Manager can help ease the installation of multiple Windows XP workstations. Here are some advanced techniques you can use to get even more out of the scripts.
In the article "Create a Windows XP Remote Installation Script using Setup Manager," I showed you how you could create a basic script that could be used to automatically deploy the Windows XP operating system to a new computer. Deploying the operating system is only the beginning though. There is much more that you can do with your remote deployment script. In this article, I will explore some of the more advanced scripting techniques.
A practical example
If you've ever gone to the Electronics store and bought a new PC, you probably found that there was a ton of junk that was preloaded. The PC probably contains a lot of branding from the manufacturer, some programs that you will never use, and some drivers. I always found these factory installations to be annoying because the PC is configured as the manufacturer wants it to be rather than how I want it to be. Did you ever stop and wonder how the manufacturer managed to distribute this type of setup though?
Some PC manufacturers set up a PC, create an image file, and then copy the image to every new PC that goes down the assembly line. Most, however, use a kicked up version of the script that we created in the first article.
The difference is that Setup Manager just provides you with the basics for deploying a default Windows installation. However, the scripting language used by installation scripts is actually a lot more robust than Microsoft would have the casual administrator believe. The language offers commands that allow you to deploy a fully customizable version of Windows. It even allows you to deploy other applications along with the operating system.
Modifying the distribution point
Before we get too far I want to point out that an installation script is powerless by itself. Even the simple scripts created by Setup Manager are dependant on having access to the Windows installation files. If you are going to create an installation routine that distributes service packs, drivers, applications, and things like that, then you will have to modify the Windows installation files.
A lot of the tricks that I am going to be showing you in this article would be impossible if the script were to be run against an unmodified Windows installation CD. Since the Windows installation files will need to be modified, you have a couple of choices. One option is to use a utility such as nLite to create a modified Windows installation CD. Although this technique works pretty well, you are limited by the CD's capacity.
Your other option is to create a network distribution point for the modified Setup files. The problem with using a network distribution point is that you need an operating system so that you can get to the network to access the distribution files. However, if you had an operating system installed, then you wouldn't need the distribution files. In my opinion, the best thing that you can do is to use your script and modified installation files in conjunction with the Remote Installation Services (RIS). That way, you can boot the system off of a RIS boot disk and access your file distribution point and your installation script. Setting up a RIS Server is beyond this article's scope, but there are lots of articles on the Internet that explain how to setup RIS.
Making setup completely automated
During the early stages of Setup, Windows Setup will stop and ask which partition you want to install Windows onto. If we are setting up a brand new machine though, there is no reason why we should have to specify a partition. Setup should know to install Windows on the C drive. Fortunately, this is something that can be scripted. Before I show you how though, I should mention that the following technique will delete any existing partitions on the machine's first physical drive.
If you look at a script that we created by Setup Manager, you will see that it looks like an INI file. It has section headers enclosed in brackets, followed by a set of commands. If you want to automatically partition the boot drive then locate the script's [Unattended] section and add the following command to it:
The command tells Windows to delete any existing partitions from the machine's first physical hard disk, and repartition the drive as one big volume. The command also instructs Setup to format that volume using the NTFS file system.
Adding device drivers
Another useful trick to modifying the installation script is to bundle device drivers with the Setup files. The reason why this is so useful is because Windows XP is several years old. There are numerous hardware devices that exist today that didn't exist when Windows XP was first released. Therefore, Windows XP does not contain a driver for such devices. Even if Windows XP has a built in driver for some of your hardware devices, there is a good chance that newer device drivers have been created since Windows XP shipped. Newer device drivers typically improve the device's performance and stability.
Adding device drivers to a deployment is one of those tasks that requires you to modify the installation media. Specifically, you will have to create a directory called $OEM$ beneath the I386 directory (\I386\$OEM$). The $OEM$ is a special directory that is used for adding third party components to a Windows deployment. I will talk more about this special directory in the next section.
For now though, create a directory beneath $OEM$ named $1. In the $1 directory, you will need to create a separate subdirectory for each driver that you want to bundle with the installation image. Keep in mind that you can put as many drivers as you want in this area. The drivers don't have to be used by the machine that you are setting up. For example, if half of your machines have NVIDIA video cards and the other half have ATI video cards, you could setup drivers for both, and Windows will take what it needs during Setup and ignore the drivers that do not match the machine's hardware.
OK, so to clarify things, let's pretend that you wanted to add an ATI driver and a NVIDIA driver to the Windows Setup files. To do so, you would create the following two directories and then copy the necessary driver files into the appropriate directory:
Creating the directories and copying the driver files into them is only half of the process though. You must now modify your installation script so that Setup knows to look for drivers in the directories that you have created. To do so, you would add the following command to the [Unattended] section of the script:
Notice in the command above that I didn't have to specify the \I386\$OEM$\$1 portion of the path. I only had to list the names of the subdirectories that contain the driver files.
The $OEM$ folder
In the last section, I mentioned that the $OEM$ directory was used to deploy additional software with Windows. This directory has a lot of special characteristics though. For starters, just creating the $OEM$ directory alone won't do anything. You have to tell Windows to use the directory. If you look at the script created by Setup Manager, you will see a command that says OemPreinstall=No. This command tells Setup that you are just performing a basic Windows deployment. If you change the No to Yes though, then you are telling Setup that you are a PC manufacturer and that you want to perform a highly customizable deployment. Only after setting the OemPreinstall=Yes option does Setup recognize the $OEM$ folder.
I've already shown you how you can use the $OEM$ folder to deploy device drivers, but you are probably wondering what else you can do with this folder. One of the most useful things that you can do with the $OEM$ folder is that you can use it to place files in a specific location on the user's hard drive. If you create a one character sub directory beneath the $OEM$ folder, then Windows Setup interprets that character as a drive letter.
For example, imagine that I wanted to place a file named BRIEN.TXT into a directory named C:\FILES on the user's machines. Obviously, C:\FILES doesn't exist by default. If I wanted to create such a directory on the user's machines, I create a directory named \I386\$OEM$\C\FILES on the distribution share. I would then place the BRIEN.TXT file into that directory. When the automated installation script runs, Setup would see this directory structure and know to put the BRIEN.TXT file into the C:\FILES directory on the machine that's being set up.
This technique works great if you are placing files into a directory that doesn't exist yet. What if you want to put a file into the Windows directory though? The $OEM$ directory can accomplish such a task, but you can't just create a directory named \I386\$OEM$\C\Windows. Instead of using the directory name Windows or WINNT, you have to name the directory $$.
For example, if you wanted to place a file into the \Windows\SYSTEM32 directory, you would have to put it in the \I386\$OEM$\$$\SYSTEM32 directory. Did you notice that I left out the drive letter in this directory name? The $$ directory path refers to the Windows system directory regardless of what it is named or what drive it is on.
Although you would usually place files in $OEM$ directories that refer to drive letters, there are special circumstances in which you would place files directly into the $OEM$ directory. You would put files directly into this directory if they were a part of the OEM branding. For example, we've all seen PC manufacturers that modify Windows Setup to display their own logo, and maybe a special background image.
If you wanted to make a custom setup that had your corporate logo or something like that, you would need to place two files directly into the $OEM$ directory. The files are called ourlogo.bmp and backgrnd.bmp. The ourlogo.bmp file should be roughly 175x175 pixels and the backgrnd.bmp file should be 640x480. Both files should be in a normal BMP format. After dropping these files into the $OEM$ directory, you would need to modify the installation script so that Setup will use the new images. To do so, you would add the following lines of text to the script:
Deploying a service pack
Another nice thing that you can do to your custom installation is to automatically deploy a service pack. Think about it for a minute. Normally, after you install Windows one of the first things that you do (either manually or through a patch management system) is to install the current service pack.
Rather than deploying a service pack later on, why not include it as a part of the Windows installation? You can easily accomplish this through a technique known as slipstreaming. Slipstreaming refers to the technique of overwriting some of the Windows installation files with files from the service pack.
Slipstreaming a service pack is easy to do. The first step is normally to copy the Windows installation files to a folder on your network, but we've already done that. Next, create an empty folder on the hard disk and copy the service pack to that folder. Now, open a Command Prompt window, navigate to the service pack folder, and enter the service pack's file name with the -X switch. The service pack setup program will now ask you for the path to which you would like to extract the service pack files. Enter the name of the current directory and click OK to continue.
When you do, the setup program will extract the files contained within the service pack. The final step is to enter the UPDATE command followed by the /S switch a colon, and the path to the Windows installation files (UPDATE /S:C:\WIN2003CD). This will update the Windows installation files to include the service pack.