Customizing Unattended Win2K Installations

Make your unattended installations more useful and less time-consuming

The bane of every systems administrator's existence is visiting user desktops. The reason isn't that users are terrible people unworthy of visitation, but that desktop visits are time-consuming and costly for the company. In many organizations, the installation and configuration of client OSs is often one of the most significant drains on IT department resources.

Windows 2000 includes several deployment features that can help you manage the chaos inherent in installing and configuring client OSs on your network workstations. Although Windows NT offers useful utilities to assist you in automating OS installation and customization, Win2K greatly improves on these offerings. Win2K includes improved versions of NT favorites such as bootable setup CD-ROMs, over-the-network installations, unattended installations, answer files, Setup Manager, Sysdiff, and Sysprep. In addition, Microsoft includes the Win2K-upgraded version of Sysprep (i.e., Sysprep 1.1) in the Support Tools on the Win2K CD-ROM and in the Win2K Server and Win2K Professional resource kits.

Of all the available Win2K deployment methods, unattended installations remain a favorite of many administrators. As with NT, Win2K offers the ability to launch unattended installations through a /U command-line switch, which the user passes to the winnt.exe or winnt32.exe setup program. Win2K unattended installations are similar to NT-based unattended installations, and you can use Win2K's unattended-installation functionality to deploy new Win2K installations and upgrade from NT and Windows 9x. Win2K also includes several enhanced features that make Win2K-based unattended installations more powerful and convenient than their NT predecessors. You can use these features to fully customize your unattended installations to make them more useful and save more of your precious time.

Preparing a Distribution Folder
Win2K unattended installations require a set of installation source folders (aka distribution folders or distribution share points). These folders contain the files necessary to install Win2K. When you're performing a basic CD-ROM-based installation, the installation source folder is the CD-ROM's i386 folder and its subfolders. Because they're on a CD-ROM, you can't change or customize the files within these folders.

However, hard-disk and network-based installations let you augment the installation folders in useful ways (e.g., add custom drivers or include the latest Win2K service pack). This ability allows for greater flexibility with and enhancement of installations that use these folders. The following steps walk you through how to create a basic Win2K distribution folder (e.g., on a network server):

After you create a basic set of installation source folders, you can start customizing them. The $OEM$ subfolder isn't necessarily the only subfolder you'll need; it's actually a root folder that houses all the folders and files related to an automated or customized installation. Table 1 lists the $OEM$ subfolders and their contents.

All the files in distribution folders should use 8.3-format short filenames so they're accessible to Win2K Setup. If you want to rename files in these folders later, you can do so by creating a special file called $$RENAME.TXT in each folder that contains files that need to be renamed. (Multiple copies of $$RENAME.TXT might be in the distribution folder structure.) $$RENAME.TXT uses the following format:

[section_name_x]shortname_y = "longname_y"

where section_name_x is the path to the subfolder that contains the files to be renamed. You don't need to name a section, or a section can have a backslash () as a name, which denotes that the section contains the names of the files or subfolders that are in the drive root. Short_name_y is the name of the file or subfolder in the subfolder that section_
name_x designates as the one that you want to rename. The name mustn't be enclosed in quotation marks. Long_name_y is the new name of the file or subfolder. This name must be enclosed in quotation marks if it contains spaces or commas.

Updating Distribution Folders to Include Service Packs
A long overdue feature that Microsoft introduced in Win2K is the ability to update a hard-disk-based installation/distribution folder with a Win2K service pack. This process (aka slipstreaming a service pack or an integrated installation of a service pack) obviates the need for running a second, separate installation of a service pack after the base OS installation is complete. This integrated installation feature has two benefits: It lets you install new Win2K systems with the latest version of the OS, and it makes adding new OS components to existing installations a one-step process because it eliminates the need to reinstall the service pack after you add components. However, be aware that you can't uninstall SP1 if you installed the service pack from an SP1-slipstreamed installation source. Therefore, be sure that all your applications work properly with SP1 before you deploy.

To perform an integrated installation of a Win2K service pack on a distribution folder, run the service pack's update.exe program, which is in the update subdirectory of the service pack source folder. However, if you're using the single-file compressed service pack version that you downloaded from Microsoft's Web site, you must first extract the files to an installation point by launching the executable and running it with the —x option (e.g., sp1network.exe —x).

Run Update.exe with the —s installation folder name option, which specifies the folder that contains a Win2K installation source. For example, to upgrade a Win2K installation source (Win2K Server, Pro, or Advanced Server), you would run the following command in a command prompt window or through the Start menu's Run option:

Update -s:C:W2kinst

This command starts a process that modifies the source folder so that it will install the equivalent of the base OS release plus the service pack, as Figure 1 shows. As long as you point Win2K to the service-pack updated installation share point on the network, the installation will receive the latest versions of the OS components. An important note is that the base installation folder that you specify after the —s option isn't the i386 folder, but the root of the Win2K installation folder (one folder above the i386 folder). If you specify another directory, the integrated service pack installation will fail.

Installing Unsupported Devices
Win2K includes Plug and Play (PnP) technology support, which is capable of detecting and supporting a wide array of devices. However, this support won't help an automated deployment that requires custom or third-party mass storage device drivers or hardware abstraction layers (HALs) because these components are required during the text-mode portion of Setup, which happens before the GUI-mode portion of Setup in which full PnP support is enabled. Therefore, you must include these additional drivers within the source installation structure to ensure that Setup properly detects and supports them. In addition to mass storage drivers and HALs, you might want to preinstall PnP drivers for unsupported devices, even if support for those devices isn't crucial to system installation.

Installing Mass Storage Device Support
Installing support for an unsupported mass storage device in a Win2K distribution folder involves the following process: First, create a subfolder named Textmode under the $OEM$ subfolder in your Win2K distribution folder. Next, you need to copy the mass storage device driver files that you received from the hardware vendor (e.g., on a 3.5" disk, CD-ROM, or through a download) to the Textmode subfolder. This set of files usually includes at least a .sys, .inf, and txtsetup.oem file, and might include a .dll file.

In the unattended answer file (e.g., unattend.txt), create a section named [MassStorageDrivers], and input the driver entries that you want the section to include. For example, if you were installing drivers for an unsupported SCSI controller, you might enter something similar to the following in the [MassStorageDrivers] section:

"BigSCSI Corporation 8900 Controller" = "OEM"

To discover what to enter in the [MassStorageDrivers] section, look in the txtsetup.oem file that the vendor included with the driver. This file contains a line similar to the line in the example that you can mimic in your unattend.txt file. For detailed information about the format of an unattended answer file, see the "Microsoft Windows 2000 Guide to Unattended Setup," which has the filename of unattend.doc and is in the deploy.cab file in the SupportTools folder of the Win2K installation CD-ROM. To extract the file under Win2K, double-click the .cab file to reveal its contents, then drag the unattend.doc file into the folder of your choice.

Next, in the unattended answer file (e.g., unattend.txt), create a section called [OEMBootFiles], and enter, line by line, the list of files that came with the mass storage driver (i.e., the files that you previously copied to the $OEM$Textmode folder), as the following example shows:

[OEMBootFiles]Filename.sysFilename.dllFilename.infTxtsetup.oem

If the mass storage device that you're adding support for is a PnP device, its txtsetup.oem file will contain a [Hardwarelds.scsi.ServiceName] section, where ServiceName is the name of the service related to the mass storage device (e.g., [Hardwarelds.scsi.bsc8900]). If you don't see this section, then you must add it. To do so, use a text editor to edit the file, create the [Hardwarelds.scsi.ServiceName] section, and enter the following information into that section:

id = "DeviceID" , "ServiceName"

where DeviceID represents the device identifier, and ServiceName represents the service name associated with this device.

Installing HAL Support
The process for installing support for an additional HAL is similar to installing mass storage support, but a bit less complex. First, create a Textmode subfolder in the $OEM$ folder (if it doesn't already exist). Next, copy to the $OEM$Textmode folder the HAL-related files that you received from the hardware vendor. In your unattended installation answer file (e.g., unattend.txt), edit the [Unattend] section for the HAL, and add a line that represents the HAL you want to install. The section should look similar to the following example:

[Unattend]Computertype = "Description_of_HAL", OEM

In the HAL driver's txtsetup.oem file, you can find the description that you should enter for the variable Description_of_HAL. In this case, I found the description in the [Computer] section of the txtsetup.oem file.

Finally, create in your answer file an [OEMBootFiles] section. In this section, enter the names of the files in the $OEM$Textmode folder, putting each filename on a separate line.

Installing PnP Driver Support
Although mass storage and HAL support are the only additional hardware support that is crucial to complete an unattended Win2K installation, you might benefit from adding PnP driver support for devices on your target PCs that aren't supported by the current version of Win2K. Doing so lets Win2K Setup automatically detect and install support for these devices during an unattended installation.

To install additional PnP devices in your distribution folders, create a subfolder under your main distribution folder for the additional PnP drivers (i.e., the .sys files and their associated .inf files). You can name this folder whatever you prefer (you'll refer to it by name later in an answer file). For example, suppose you name it Pnpdrvs. The resulting directory would be $OEM$$1Pnpdrvs.

Next, to add the path to the list of PnP search drives, add the following line to the unattend.txt file:

OEMPnPDriversPath = "Pnpdrvs"

If you have subfolders under the Pnpdrvs folder, you must specify the path to each subfolder, separating each reference with semicolons. To simplify PnP driver folder maintenance, I recommend that you create a subfolder structure that includes each type of driver—even those for which you don't currently have additional drivers. For example, if your Pnpdrvs folder contains the subfolders Network, Video, and Audio, the answer file needs to contain the following line:

OEMPnPDriversPath = "PnpdrvsNetwork;PnpdrvVideo;PnpdrvsAudio"

The Syspart Deployment Tool
Win2K includes a new deployment tool, Syspart, which is an optional parameter of winnt32.exe (the Win32 version of the Win2K Setup program). This option is handy in situations in which you need to install similar OS configurations on groups of machines that use different HAL files or mass storage drivers. To use this parameter, you install two hard disks on the source machine, then launch Setup from that machine. Target the installation to the primary partition of the system's second drive. After Setup completes the installation, you can remove the second drive and install it in the target machine. This deployment method reduces overall deployment time by eliminating the file-copying portion of the setup process.

To use Syspart, select source machines that represent each of the different hardware configurations in your network and have Win2K or NT 4.0 installed. On each machine, connect the network distribution folder and run Setup using the following command-line syntax:

WINNT32 /U:answerfile /S:install_source /SYSPART:second_drive /TEMPDRIVE:second_drive /noreboot

where answerfile is the answer file Setup is using for the installation, install_source is the location of the Win2K distribution files, and second_drive is the destination drive for the installation (i.e., the drive that you'll remove and install in the target machine). The /SYSPART and /TEMPDRIVE parameters must point to the same partition on the secondary hard disk.

After Setup completes the installation, Setup marks the primary partition on the second disk as the active partition. Then you can move the second disk to the target machine.

Unattended Answer Files
The driving force behind any unattended installation is an answer file, the script that guides the installation and automatically answers the questions that Setup asks during the configuration process. You create an answer file either manually or automatically, by running the Win2K Setup Manager utility, which is in the deploy.cab file in the Win2K CD-ROM's SupportTools folder. The easiest method for creating an answer file is to use Setup Manager to generate a first draft of the file, then manually fine-tune additional settings.

Using Setup Manager to Create and Manage Answer Files
Setup Manager (i.e., Setupmgr.exe), which Figure 2 shows, is a GUI-based utility that uses a wizard-based interface to let you specify various options related to the Win2K setup and upgrade process. After you complete this process, Setup Manager saves your selections in a customized answer file that you can later use to perform unattended installations. You can use Setup Manager to create answer files that incorporate the following customizations:

Although Setup Manager is a useful utility, it has several limitations. For example, you can't use Setup Manager to specify additional system components that you want the unattended installation to install (e.g., WINS, the Network Load Balancing—NLB—service) or to create subfolders under the main distribution folders.

After you've used Setup Manager to successfully create your answer file, you can review the file and make changes. To edit the file, rerun Setup Manager and select the Modify an existing answer file option or use a text editor to make changes that aren't possible through Setup Manager. When you manually edit an answer file, use a text editor that will save the file as text-only.

If you're configuring answer files for the first time, you'll benefit from taking a look at example files to get an idea about how you can configure various settings. Microsoft provides example answer files in Appendix C of the Deployment Planning Guide, one of the books in the Microsoft Windows 2000 Server Resource Kit. The Appendix contains several answer files, including examples targeted toward CD-ROM-based installations and installations on servers that have load-balanced and clustered configurations.

Setting Passwords in Answer Files
You can also use answer files to set a variety of passwords in a Win2K installation. You can use the following fields within an answer file to set different password types: AdminPassword, UserPassword, DefaultPassword, DomainAdminPassword, AdminstratorPassword, and Password. For information about the definitions of these password-related fields, see the "Microsoft Windows 2000 Guide to Unattended Setup," which has the filename of unattend.doc and is in the deploy.cab file in the SupportTools folder of the Win2K installation CD-ROM.

From a security perspective, placing passwords in answer files presents security risks. After you complete an unattended installation, the answer file remains on the computer, but Setup removes all passwords from the local copy of the answer file as a security measure. However, the answer file is available on the target workstation's hard disk while Setup is running. This situation creates a security hole that you can avoid by simply not including password information in answer files.

Extending Disk Partitions
A little-known feature of Win2K is the ability to force Setup to automatically extend the partition to which you're installing Win2K. This functionality is particularly useful for OEMs and IT shops that want to create a small partition of system disks, then later have Setup expand the partition to a larger size.

To extend a partition, Setup uses the ExtendOEMPartition parameter in the answer file to launch the unattended installation. This parameter works only with NTFS partitions, and you can use it in a regular unattended setup answer file or an unattended answer file used for a Sysprep-based installation. The ExtendOEMPartition parameter uses the format

ExtendOemPartition = 0  |  1  |  Added_size

where 0 tells Setup not to extend the partition, 1 tells Setup to extend the partition to fill out the hard disk, and Added_size tells Setup to increase the partition by the specified number of megabytes.

ExtendOEMPartition works only on the active system partition and not on other partitions on the same hard disk or other hard disks in the system. In addition, when you use ExtendOEMPartition = 1, Setup extends the partition to all remaining space on the hard disk, but leaves the last cylinder blank so that you have the option of later converting the disk from a basic disk to a dynamic disk. If you're using ExtendOEMPartition during an unattended installation on a FAT partition, you first need to convert the partition to NTFS by specifying FileSystem = ConvertNTFS in the [Unattended] section of the answer file to convert the partition to NTFS.

Post-Installation Commands
As I previously mentioned, Setup Manager lets you generate commands that run after an unattended installation is complete. To do so, you can use a cmdlines.txt file, the [GuiRunOnce] section of an answer file, or the [SetupParams] section of an answer file. In either case, I recommended that you use Setup Manager whenever possible to manage running post-installation commands. Setup Manager helps you avoid introducing typos and errors and will automatically build the relevant file (or file section) for you.

Cmdlines.txt. The first method for running additional commands during the Win2K setup process involves cmdlines.txt, which contains a list of one or more commands for Setup to run automatically during the GUI-mode portion of the setup process (during the optional components portion). For example, you might tell Setup to install programs for applications that you want on the target Win2K system. If you're using cmdlines.txt for a typical unattended setup, place the cmdlines.txt file in the $OEM$ subfolder of your distribution folder. If you're using cmdlines.txt for a Sysprep-based installation, place the file in the $OEM$1$1$Sysprep folder. Cmdlines.txt uses the syntax:

[Commands]"command_1""command_2". . ."command_x"

where "command_1" and "command_2" refer to the commands you want Setup to run and the order in which you want Setup to run them. When you're creating this file, place all commands in quotation marks. In addition, place the files necessary to run each command line specified in cmdlines.txt in directories that you can access during the setup process (i.e., the files must be on the local hard disk). This requirement means that you might want to place the files in the distribution folder structure so that Setup properly copies them to the target system.

You use this method of specifying post-installation files if you're installing from the $OEM$ distribution subfolder or if the application you want Setup to install is single user-centric (i.e., it doesn't support multiple users through the registry) or designed to be installed by one user and to replicate user-specific information to other users (through the default user section of the registry). Because cmdlines.txt runs during a portion of Setup in which no user is logged on and you have no guarantee of network connectivity, Setup writes user-specific information to the default portion of the Registry. As a result, all subsequently created users receive whatever information Setup has written.

[GuiRunOnce]. You can also launch additional commands during setup using the [GuiRunOnce] section of an unattended setup answer file. As with cmdlines.txt, this section contains a list of one or more commands that you want Setup to run after the installation is complete. However, in this method, Setup doesn't run the command lines until the first user logs on to the system after Win2K is installed. The [GuiRunOnce] section of an unattended answer file (e.g., unattend.txt) uses the syntax:

[GuiRunOnce]"command_1""command_2". . ."command_x"

Where "command_1" and "command_2" refer to the commands you want Setup to run and the order in which you want Setup to run them.

If any of the applications launched by the commands in the [GuiRunOnce] section cause a reboot, you should determine whether the application can be launched in a way that suppresses the system reboot (e.g., through a special command-line switch). Otherwise, if the system reboots, Setup automatically removes all the commands in the [GuiRunOnce] section and the remaining commands won't run. If any of the applications [GuiRunOnce] runs require the presence of the Microsoft Windows Explorer shell, they will fail because [GuiRunOnce] runs these commands before Explorer is present. If you can't address either of these problems for an application, consider using a different method to deploy the application.

[SetupParams]. A third, undocumented method for running additional post-Setup commands in Win2K involves the special [SetupParams] section in the answer file. Using [SetupParams] lets you put everything into one file rather than create an additional file as cmdlines.txt requires you to do. However, this approach suffers from a significant limitation: You can enter only one command. In addition, the command you enter under the [SetupParams] section executes immediately after Setup completes.

To use this method, employ the following format to create a section called [SetupParams] in your answer file:

[SetupParams]UserExecute="c:myappsetup.exe/q/u"

This example causes Setup to launch a program called Setup.exe in the C:myapp folder. The command you add under [SetupParams] must begin with the keyword UserExecute=, followed by the path to the application. You can omit the path only if the referenced application is in the %systemroot% or %system root%system32 folder or search path. You must enclose the pathname in quotes unless you use an 8.3 filename-compliant version of the pathname.

Launching an Unattended Installation
After you've prepared the individual elements of your unattended installation, you're ready to pull them together and launch the installation. Regardless of whether you launch Setup from a DOS boot disk or over the network, you use a command line similar to the following example:

WINNT (or WINNT32) /U[:answerfile] /S:sourcefolder

As with NT, Win2K Setup (i.e., winnt.exe or winnt32.exe) automatically looks for a file called unattend.txt if you don't specify a filename after the /U switch, and /S can be a folder on a local or redirected drive or a Uniform Naming Convention (UNC) pathname to a network share (e.g., \FILESERVERI386).

When upgrading NT and Win9x systems, you can use a trick to improve the performance of Win2K Setup's file-copying phase and balance the resulting load across multiple servers. You use a special command-line switch that takes advantage of a little-known load-balancing feature in winnt32.exe. To use this feature, create distribution folders that contain identical sets of files on multiple servers. Then enable client workstations to use multiple source folders (as many as eight folders) by launching winnt32.exe with multiple /S options specified at the command line.

Unattended installations are an important deployment method in Win2K, and learning about them is definitely a worthwhile investment of your time. Knowing how to customize unattended installations to your organization's needs can make a significant dent in the amount of time you spend swapping disks on client desktops.