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
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 www.winimage.com,
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 (www.nero.com)
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 Deploy.cab 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
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:
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
The “ProductID=BBBBB-BBBBB-BBBBB-BBBBB-BBBBB” entry permits you to enter
the 25-character product key from your master license or volume license
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
The “TSEnable=On” entry installs Terminal Services and the entries under
“[TerminalServices]” configures the service as admin-mode with NT 4.0
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
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
- C, D and so forth contain files destined for their respective partitions.
The folder hierarchy in $Oem$ will be reflected in the production file
|Figure 1. The $Oem$ folder is a special installation
folder for PnP drivers not on the server CD or optional mass storage
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:
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:
See the Deploy.doc file for the various domain controller settings.
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 www.wordsmith.org/anagram
and finding a better anagram for MCP Magazine than Amazing PC Me.