Windows Insider

Installation Automation

Installing a server is usually boring and time-consuming. Using scripts may not alleviate the boredom, but it will free you up for more interesting tasks.

I have an ironic streak in me, so I like the idea of using computing power to eliminate computer drudgery. That’s why I like using scripts to automate the installation of servers.

You may subscribe to the school of thought that wants to go one step further and use imaging technologies such as Symantec’s Norton Ghost or PowerQuest’s DriveImage to clone off your servers. I prefer scripted installations because an image made on one server could have slightly different settings than the installation on what appears to be an identical server. Why take a chance that a tiny change in an ASIC might cause instabilities months after installation?

I also prefer a scripted installation because it lets me skip the installation of certain components and services that would ordinarily be installed by default, such as games and multimedia services and other incidentals that don’t belong on servers. Another potentially unwanted component installed by default is IIS, which should only be installed on Web servers and, otherwise, represents an unnecessary security vulnerability. Even if you want to install IIS, it’s important to avoid putting the default Inetpub folders on the C: drive where they can become a door to the system files if the Web service is compromised by a traversal exploit. The only way to select a different drive for Inetpub is to use a setup script.

Scripting also permits automatically installing admin-mode Terminal Services—something that greatly simplifies remote administration—along with handy, miscellaneous components such as Network Monitor, Simple Network Management Protocol and Content Indexing.

So let’s see how to use scripts to leverage a half-hour’s work and avoid many hours of babysitting server installations.

Building the Installation Point and Slipstreaming
Start by configuring a server to host the installation files. This server shouldn’t be on the main production network and should never touch the Internet. As any The X-Files fan will attest, the bogeyman is always out there, so it’s really important to keep a new server in a pristine network environment until it has its armor plating of security updates and anti-virus software. You can set aside a corner of your server room for doing unattended installations using crossover cable to a small installation server. If you want to speed things up a bit, put gigabit Ethernet adapters on both servers.

Copy all the files from the server CD to a folder on the installation server, then share the folder. The share name needs to meet 8.3 naming requirements because you’ll be using the DOS networking client to connect to it.

Unless you’re a Premier partner with the latest server CD, you’ll need to slipstream the service pack files into the installation folder. Slipstreaming avoids applying the service pack after setup, then reapplying it again and again when installing services later on.

To slipstream a service pack, first expand the service pack files to another folder on the installation server, then run Update with the following syntax:

update /s:<installation_point>

where <installation_point> is the folder containing the setup files. Don’t include the I386 in the path; it’s appended automatically. Windows 2000 service packs are cumulative, so you only need to slipstream SP3.

The server remembers the UNC path of the installation folder. Following installation, you can point the server at a central location for installation files or perhaps make a local copy on the server. You’ll need to change a couple of Registry entries:

Key: HKLM\SOFTWARE\Microsoft\Windows\Current Version\Setup
Value1: SourcePath=<UNC path to slipstreamed files;
             e.g. \\server1\windist>                   
Value2: ServicePackSourcePath=<UNC path to slipstreamed
files; e.g. \\server1\windist>  

When entering paths in the two values, don’t include the I386 folder.

Building a Boot Disk using Bart
You’ll need a way to bring your server up on the network to connect to the installation share. This requires a boot disk with Windows network drivers. You can simplify this task considerably by taking advantage of a great Web site for building automated boot disks: Bart’s Boot Disks at

The key to building a Bart disk is the Build Floppy Disk (BFD) utility. BFD creates a DOS boot disk formatted with Windows 98 build 4.10.1998 and includes the correct versions of EMM386, Smartdrv, Fdisk, Xcopy and Format, along with a freeware RAM drive utility called Xmsdisk. It includes compressed cab files, which it calls modules, that contain mouse and keyboard drivers, real-mode NDIS drivers for NETBEUI, TCP/IP, and NWLink, and a basketful of network adapter drivers. You can put as many adapter drivers on the disk as you have room to store them. A boot utility on the disk does a PCI bus scan to identify network adapters, then loads the correct driver from the list of available cab files. Very slick.

The Autoexec.bat on the boot disk builds a RAM drive and extracts the cab file contents into memory. It then walks you through creating a profile for your network logon. With that done, you’re ready to connect to the installation share using the NET USE command. You can also use a classic character-based browsing interface by simply typing NET. Burn the contents of the floppy to a bootable CD to get a very fast boot.

You’ll want to load as many drivers and utilities onto Bart’s modular boot disk as possible. To avoid the 1.44MB limit on a standard floppy disk, take advantage of a utility called WinImage, available at, to create a 2.88MB file that pretends to be a floppy, giving you a lot more real estate to install modules and utilities. WinImage is not freeware, but the price for the standard edition is only $30. The BFD utility has command-line options to use WinImage to build a boot image file. Copy the WinImage executable to the \winimage folder in the BFD installation folder then use this syntax:

bfd /i filename.ima /t 288 msnet

Once you have the image file, use your favorite CD packet writer to create a bootable CD. I like Nero Burning ROM ( because it’s fast and has a flexible bootable CD option.

Building a Setup Script Using Setup Manager
An unattended installation is really nothing more than a script that defines choices to make during setup. You can build a script from scratch, but it’s much simpler to use the Setup Manager Wizard (Setupmgr) to at least configure the body of the script. You can do minor surgery on the script file afterward.

The Setupmgr executable is in the file in the Support folder on the Win2K Server CD. Extract the file into a convenient location on the installation server and run it from there. Setup Manager can create an installation point for you, but it’s simpler to create the installation point first with the slipstreamed service pack files, then use Setup Manager to build an unattended setup script and modify the installation files, as necessary, with additional drivers and files.

You’ll need copies of the drivers for any hardware that might be encountered by a server during setup. Because you’ll be using the same installation point to install Win2K on a variety of platforms, you’ll end up with a lot of drivers. That won’t cause a problem, as long as the drivers don’t share the same name for any files.

Setup Manager allows you to pick a random computer name as part of the unattended installation, but server names are too important to leave to chance. Instead, define a list of names. This creates an Unattend Difference File (UDF) in the same folder as the unattended setup script. The UDF file contains a heading for each computer name and looks something like this:


When running the setup executable, Winnt, identify the computer name on the command line along with the /udf switch as follows:

winnt /s:z: /t:c: /u:unattend.txt /udf: w2k-s10,unattend.udf

The installation script created by Setup Manager has a standard .INI file format consisting of headings in square brackets and configuration parameters underneath. Here’s an excerpt. The Deploy.doc file in the Deploy cab file has a list of the headings and what they control. Here are a few items that warrant closer attention:

  OemPnPDriversPath=\drivers\Video\   Graphics\Win2000;\drivers\Video

The “Filesystem=ConvertNTFS” entry converts the operating system partition to NTFS. This requires an additional restart during the unattended setup.

The “OemPnPDriversPath” entry defines a path in $OEM$ that holds drivers for Plug-and-Play hardware that aren’t installed as part of the standard setup files. If the drivers aren’t digitally signed, be sure to include the “DriverSigningPolicy=Ignore” switch. Otherwise, you’ll be prompted during automated Setup to acknowledge that you’re installing unsigned drivers.

The “ProductID=BBBBB-BBBBB-BBBBB-BBBBB-BBBBB” entry permits you to enter the 25-character product key from your master license or volume license agreement.

Notice that the “AdminPassword” entry is in clear text, so it’s important to protect the installation files. Set NTFS permissions so that only authorized administrators have access and, once again, keep the installation server off the production network. In Windows .NET, the admin password in the unattend.txt file is encrypted.

The “AutoLogon=Yes” and “Auto LogonCount=1” entries are a handy way to get quick access to the server for last-minute tweaking after the automated setup process has completed. After the first automatic logon, you’ll be prompted for credentials.

The IIS component entries keep setup from installing IIS by default. You can use a script to install IIS after setup has finished. This is discussed later.

The “TSEnable=On” entry installs Terminal Services and the entries under “[TerminalServices]” configures the service as admin-mode with NT 4.0 permission support.

The game entries keep setup from loading recreational programs. You might want to keep Solitaire, as maintaining keen hand-eye coordination is essential for good system administration.

Here are some network component settings to use for various configurations. The actual ON/OFF settings depend on the server. If you decide to enable SNMP, be sure to read Deploy.doc carefully regarding the use of community strings so that you don’t inadvertently give inappropriate access to the server.


If you need to install Plug-and-Play drivers that aren’t on the server CD, optional mass storage drivers or an OEM HAL, you can identify them to Setup Manager, which will then copy the driver files into a special installation folder called $Oem$. Like rock music and ballet, the layout of $Oem$ appears inscrutable until you understand the hidden meanings.

  • Textmode contains files used during the text mode portion of Setup. This is where Setup Manager places alternate mass storage drivers and OEM HAL files.
  • $$ contains files destined for % windir%, typically C:\Winnt.
  • $1 contains files destined for %windir%\System32. These are usually driver files.
  • C, D and so forth contain files destined for their respective partitions. The folder hierarchy in $Oem$ will be reflected in the production file system.

$Oem$ folder
Figure 1. The $Oem$ folder is a special installation folder for PnP drivers not on the server CD or optional mass storage drivers.

Making Post-Setup
To run additional commands following setup, such as batch files to install applications, you have a couple of options. The Run Once window in Setup Manager will place the batch file names in the unattended setup script under the heading [GUIRunOnce]. These batch files run at the first logon in the context of the logged-on user, which means that Registry entries are placed in HKey_Current_User. The Additional Commands window in Setup Manager places the batch file names in a text file called Cmdlines.txt at the root of $oem$. Batch files in Cmdlines.txt are run at the completion of Setup before restart. This means they run in the Local System security context and any Registry changes are saved to the Default profile.

Making Post-Setup Component Changes Using Sysocmgr
Following the completion of Setup, you may want to make changes to the operating system components. You can do this with an unattended setup script and a utility called Sysocmgr that comes with Win2K. For example, once you’ve created a second partition to hold Inetpub files, you can automate IIS installation with the following entries:


If you plan on using the server as an Exchange 2000 platform, you’ll need to enable SMTP and NNTP, as well.

Once you’ve built the script (call it IIS.txt), use Sysocmgr with the following syntax to install the components:

sysocmgr/inf:%windir%\inf\sysoc.inf /u:c:\iis.txt

If you want to change optional Networking components with Sysocmgr, you’ll need to include the “NetOC=on” option in the Components section.

You can even script the promotion of a Win2K server to a domain controller using the /answer switch on Dcpromo and a text file with a “[DCInstall]” section such as this:


Run DCPromo as follows:

dcpromo /answer:<unattend_script>

See the Deploy.doc file for the various domain controller settings.

Disk Partitioning
The Winnt utility copies installation files to temp folders, so you’ll need to create an operating system partition formatted as FAT or FAT32 on the server prior to running Winnt. You can use Fdisk and Format to do this, but it’s simpler to get a utility called Gdisk that Symantec bundles with Ghost. The Gdisk utility permits wiping a disk and partitioning it with two lines of code:

gdisk 1 /wipe /mbr /y
gdisk 1 /cre /pri /for /sz:8000 /q /y

The first line removes any existing entries from the Partition Table in the Master Boot Record and the second line creates an 8GB primary partition and formats it using FAT32. Unlike NT 4.0, Win2K Setup uses extended INT13 calls that make it possible to have large boot partitions.

You can also run Gdisk in batch mode in Cmdlines.txt to create additional drive partitions and format them as FAT32. Use Convert to convert the partition to NTFS then use Sysocmgr to install IIS with the new partition as the location of the Inetpub files.

Patches and Security Updates
If you slipstream SP3 with your installation of Win2K, you get a new version of the Windows Update client that supports automated installation of patches and hotfixes. This isn’t necessarily a good idea for servers; you lose too much control over the process. You can elect to configure the updates manually for each server, but you can save time by installing the new Software Update Service (SUS) on a central server then approving the patches that you want to deploy. SUS is a free download from Microsoft.

Even Less Work
Next month, I’ll cover how to do this whole process even more seamlessly by using Remote Installation Services (RIS.) Until then, fight tedious computing by visiting and finding a better anagram for MCP Magazine than Amazing PC Me.

About the Author

Contributing Editor Bill Boswell, MCSE, is the principal of Bill Boswell Consulting, Inc. He's the author of Inside Windows Server 2003 and Learning Exchange Server 2003 both from Addison Wesley. Bill is also Redmond magazine's "Windows Insider" columnist and a speaker at MCP Magazine's TechMentor Conferences.


comments powered by Disqus

Subscribe on YouTube