Chapter 11 - Windows NT Workstation Unattended Modular Build

By David Skinner, MCS—UK

This chapter provides a template for an unattended modular build of Windows NT, service packs, and application software. The procedural information is broken out into four sections:

• The need for automation

• Overview of standard unattended Windows NT installation

• Design qualities of a modular build

• Walkthroughs and examples of a modular build

Other sections following these provide tips (there are also tips in the procedures), a complete listing and explanation of answer file settings, information on MS-DOS utilities, and a discussion of the ScriptIT utility. The discussion assumes that you are familiar with the manual installation and configuration of Windows NT.

What You'll Find In This Chapter

• An automated solution for "hands-free" installation and configuration of Windows NT Workstation, service packs, and application software.

• Illustration of the standard Windows NT 4.0 (Server and Workstation) functionality for unattended operating system installation and configuration using an answer file and special $OEM$ directory structure.

• Tips on common procedures for Windows NT (and application) configuration.

Warning: This chapter makes recommendations for tuning the Windows NT registry using the Registry Editor. Using the Registry Editor incorrectly can cause serious, system-wide problems that require you to reinstall Windows NT. Microsoft cannot guarantee that any problems resulting from the use of Registry Editor can be solved. Use this tool at your own risk.

On This Page

The Need for Automation
Windows NT Unattended Installation
Design Qualities
Creating a Modular Unattended Build
Phase 1—System Preparation Walkthrough
Phase 2—Installation of Windows NT Walkthrough
Phase 3—Global Windows NT Configuration Walkthrough
Phase 4—Application Installation Walkthrough
Phase 5—Finalize/Domain Membership Walkthrough
Tips on Common Procedures
Answer File Information
MS-DOS Utilities
SCRIPTIT

The Need for Automation

As the PC has become "ubiquitous" it has also evolved into a system several orders of magnitude more powerful than its pioneering predecessor. Operating systems such as Microsoft Windows NT Workstation provide a multi-tasking environment with seamless connectivity to external network systems. Applications such as Microsoft Office leverage this power to provide users with state-of-the-art productivity tools. In addition to boosted productivity, this progress has introduced a problem: rather than plugging in and setting up a few terminals, IT groups now have to install great numbers of increasingly complicated machines.

Deployment Challenges

The increasing internal complexity of operating systems and application software, combined with evolving hardware standards, makes it difficult for companies to adopt and adhere to a consistent PC deployment method.

Typically, companies deploying large numbers of Windows NT Workstations face these challenges:

• Varying PC hardware configuration: CPU, video, hard disk size, hard disk controller, network interface, mouse (PS/2, serial, etc.).

• Different software and configuration requirements from department to department.

• Installation and configuration of application software that does not support automated installation.

Providing an Automated Solution

This chapter describes a process that builds on the Windows NT setup program's unattended installation facility to create a modular unattended deployment process for hands-free installation and configuration of Windows NT Workstation, service packs, and application software.

Developing an automated build has some costs, but it offers:

• Standardization. Even when hardware differs, you can configure both the operating system and applications to company standards, providing a mechanism for centralized version and quality control.

• Reduced Configuration Errors. Automating configuration reduces the risk of error.

• Faster Deployment. Eliminating human input during the build reduces the need for someone to wait, and allows concurrent deployment scheduling.

• Increased Supportability. If there are future support problems, you have a known reference for system configuration.

• Recovery. If there are future hardware failures, you can quickly re-deploy the operating system and applications.

• Cost Effective. Fewer people are required to manage and deliver the rollout, making outsourcing an option. For example, you can provide the hardware supplier with the automated build mechanism, so that new hardware arrives already configured.

Windows NT Unattended Installation

This section illustrates the standard Windows NT 4.0 (Server and Workstation) functionality for unattended operating system installation and configuration through the use of an answer file and special $OEM$ directory structure.

Answer File

An answer file is a text file that can be used to provide some or all of the configuration information required to automate the Windows NT operating system installation and configuration.

Although the syntax of this file is relatively simple, its hundreds of configuration options (listed later in the "Answer File Information" section) can make it lengthy and cryptic. A GUI-mode tool (Setup Manager) provided on the Windows NT CD (in \SUPPORT\DEPTOOLS\i386) presents configuration options as a series of dialogs or checkboxes and automatically generates an answer file.

Here is a simple (commented) answer file for an example:

[Unattended]
OemPreinstall = yes          ;Enables use of $OEM$
NoWaitAfterTextMode = 1     ;Automatic reboot after text
mode
NoWaitAfterGUIMode = 1          ;Automatic reboot after
GUI
mode
FileSystem = ConvertNTFS     ;Convert FAT to NTFS
ExtendOEMPartition = 0          ;Do not extend partition
ConfirmHardware = no          ;Do not ask user to confirm
NtUpgrade = no               ;Do not allow upgrade of NT
Win31Upgrade = no          ;Do not upgrade from Win3.x
TargetPath = winntw          ;Installation directory
OverwriteOemFilesOnUpgrade = no

[GuiUnattended]
OemSkipWelcome = 1          ;Do not display welcome page
OEMBlankAdminPassword = 1     ;Do not specify Admin
password
TimeZone = "(GMT) Greenwich Mean Time; Dublin, Edinburgh,
London"

[Display]
ConfigureAtLogon = 0
BitsPerPel = 8
XResolution = 800
YResolution = 600
VRefresh = 60
AutoConfirm = 1          ;Do not ask user to confirm video

[Network]
DetectAdapters = ""          ;Auto-detect NIC from drvlib
InstallProtocols = ProtocolsSection

[ProtocolsSection]
TC = TCParamSection

[TCParamSection]
DHCP = no
IPAddress = 123.456.789.1
Subnet = 987.654.321.0
Gateway = 123.456.789.5
DNSServer = 123.456.788.750, 123.456.788.751
WINSPrimary = 123.456.788.700
WINSSecondary = 123.456.788.701

Once a valid answer file has been generated, you can use it to automate the installation by passing it as a command-line parameter to the standard Windows NT setup routine. For example:

WINNT /B /U:A:\UNATTEND.TXT /S:D:\I386

$OEM$ Directory Structure

Another powerful feature of the unattended setup routine is the $OEM$ directory structure. $OEM$ enables additional files that are required for the build but not provided on the original Windows NT distribution medium, to be seamlessly copied to the destination hard disk using a series of predefined directory names.

Figure 11.1 illustrates a sample $OEM$ structure. The table below explains the directory names. To utilize this structure, $OEM$ must reside directly beneath the Windows NT distribution files (in this case, i386), and the OEMPreInstall parameter in the answer file must be set to Yes. (You must manually create the $OEM$ structure.)

\Nt4
     \1386
          \$OEM$
               \$$
               \C

Figure 11.1 Sample $OEM$ structure.

$OEM$ directory definitions.

In addition to the reserved directory names, $OEM$ provides increased functionality through the use of two reserved file names:

$OEM$—CMDLINES.TXT

This text file, located in the root of the $OEM$ structure, enables a series of commands to be executed immediately after the automated installation of Windows NT has completed. This is used to initialize phase 3 of the modular build process.

In the example below, the CMDLINES.TXT file is configured to silently install Service Pack3. It assumes that the Service Pack 3 directory has been copied into $OEM$\nt4sp3.

[Commands]
".\nt4sp3\update.exe -u -f -n"

$OEM$—$$RENAME.TXT

This text file enables automatic translation of MS-DOS style 8.3 filename formats into Windows NT long format, so that you can deploy long filenames from file systems that do not inherently provide support for them. The example below shows that this file is in section/value format, where section represents directory and value represents filename translation.

[GSCRIPTS]
SCRIPT~1="Example Long Script Name"
[GSCRIPTS\TEMP]
SCRIPT~2="Another long example"

Design Qualities

The primary goal of the modular unattended build is to provide a single, cohesive mechanism for automating the delivery of Windows NT with application software, and customizing it on a departmental or group basis.

To achieve this goal without additional infrastructure management tools such as Systems Management Server, the deployment mechanism needs these modular qualities:

• Design of the deployment directory structure must enable functional grouping of operating system, application, and configuration files. This simplifies management, and enables operating system and application installation files to reside on separate physical resources.

  For example, all Windows NT installation files could be supplied on a bootable CD. Once installed, Windows NT could connect to a network-based deployment server to install the application software.

  Figure 11.2 illustrates a simple (single CD) modular directory structure that includes application and operating system files. CoreApps represents the root of the application structure, beneath which applications are stored in individual directories. Installation scripts for each application are stored in cmdFiles. The Windows NT files (including $OEM$) are stored beneath Nt4.

\BuildNT (G) \CoreApps \cmdFiles \le30 \vb5 \Vc5 \Nt4 \1386 $0em$ \Drvlib.nic \Inetsrv \System32

**Figure 11.2 Single-CD modular directory structure.**

• All scripts used to control the installation process are Windows NT command files, which are simple and "open," reducing the need for development specialists. Resource kit utilities provide any additional functionality beyond the scope of command files (registry modification, for example).

• Instead of being hard-coded to retrieve files from specific hard disk locations, scripts retrieve this information from a configuration file generated at the beginning of the modular installation process. This enables you to deploy the build from different servers or distribution media (such as CD) without modifying script logic.

• Modular functionality ensures that a configuration script introduces only a single change to the build. As you can see (Figure 11.3) this is achieved by creating a parent/child relationship between the control logic that defines how the build is configured and the configuration script that performs the individual change. This allows you to reuse configuration scripts in multiple parts of the build.

  

  Figure 11.3: Modular configuration script functionality.

• Whenever possible, use the vendor-supplied installation routines to install and configure all applications. If the setup routine does not provide direct support for unattended installations (sometimes referred to as silent installations) the process can be automated through the use of an additional tool—ScriptIT.

This design avoids snapshot installation/deployment tools because they limit integration options. They record the state of the computer before and after manual installation of an application package, then write the differences (files, registry) between these recordings to an installation file. This assumes that the contents of the install-file represent the same set of system changes that would result from execution of the traditional setup routine, so if the package is applied to a new computer it will "install" the application without user intervention.

Unfortunately, this is true only if the package is installed into identical environments with identical configuration requirements. This approach eliminates the "intelligence" of the application's own setup routine, which may configure the application differently if it detects the presence of additional software it can inter-operate with.

Modular Framework—Overview

To develop a modular build it is necessary to combine the above ideals with existing Windows NT installation mechanics in a framework that models the natural (physical) stages of a manual deployment.

Figure 11.4 illustrates a five-phase model that represents the life cycle of a Windows NT installation/configuration, from PC preparation to complete installation. Phases are explained below:

Figure 11.4: Five-phase model.

Phase 1

Phase 1 sets up and prepares the PC to receive Windows NT: an MS-DOS boot disk partitions and formats the destination hard disk for use with the FAT file system, a logical drive connection is established to the deployment device, basic configuration information is requested from the installation engineer (computer name, configuration group, IP address, etc.), and configuration information is written to appropriate files on the local hard disk. This information is used throughout the remainder of the build process, eliminating the need for further human interaction. You can pre-encode the information onto the boot disk, eliminating all human interaction, but this requires creating a uniquely prepared disk for each workstation

Phase 2

Phase 2 executes the traditional unattended Windows NT installation routine, using a combination of floppy-less and unattended installation mechanics to provide a completely hands-free OS installation.

Phase 3

Phase 3 enables you to implement company-wide granular configuration changes to Windows NT. For example, if your company has many departments, each with differing configuration requirements, the configuration in this phase must be common across all departments. Typical examples include browser participation, event log settings, etc.

Phase 4

Phase 4 enables group-specific configuration of Windows NT, and installation of application software through the use of package scripts. This makes it possible to use a single deployment server to provide multiple Windows NT configurations, based on group information supplied in phase 1.

Phase 5

Phase 5 configures security and domain membership properties of the workstation.

You could perform these functions as part of phase 3, but you would have to build the workstation within the domain it is joining. Separating this process allows the workstation to be built outside the domain (by an outsource partner, for example) and to join the domain upon connection to the corporate network.

Creating a Modular Unattended Build

The next sections discuss each phase in turn and provide tricks, tips, and scripts you can use in many other scenarios.

The examples that follow are based on the assumption that you want to roll out Windows NT workstation with the following applications (chosen to illustrate different installation techniques): Office97, Outlook98, Visio, and WinZIP. Windows NT is to be configured as follows:

• Support for 3Com 3c90x and 3c509 network adapters

• Event Log maximum size set to 1 MB

• Windows NT configured for UK locale

• BOOT.INI timer delay reduced to 5 seconds

• Membership in the TSTDOM domain

Getting Started

First you have to construct a skeleton deployment directory structure. It should be appropriately modularized so that operating system, application, and command-script files can reside (as far as practically possible) in separate directories. Figure 11.5 shows the directory structure used during this example.

\Buildsvr on `Zippy' (H:)
          \Answer
          \Apps
               \cmdFiles
               \Office97
               \ol98
               \visio5
               \WinZip
          \Nt4
               \1386
                    \$0em$
                    \$$
                         \System32
                    \C
                         \Build
                              \Drivers
                                   \Audio
                              \Groups
                                   \Example1
                              \Gscripts
                    \Net
                    \NT4sp3
               \Drvlib.ric
               \Inetsrv
               \System32

Figure 11.5 Directory structure used in the example.

The examples and discussion in the rest of this section refer to the Figure 11.5 directory structure residing on a file server. In practice it can reside on any storage device that accessible to Windows NT and MS-DOS by a logical drive letter.

Notes on Figure 11.5, working down from the top:

• Answer. The directory containing the skeleton answer files for use in phase 1.

• cmdfiles. Scripts to control the installation of application software.

• Office97/ol98/visio5/WinZip. Application directories.

• Drivers. Subdirectories for drivers that cannot be installed by the answer file.

• Example1. Configuration group directories containing department-specific scripts.

• Gscripts. Location of control script for phase 3.

• Net. Directory containing the OEM network drivers (not supplied with Windows NT) used by the answer file in phase 2.

• Drvlib.nic. Standard directory from the distribution CD, but trimmed to include only required drivers.

Preparing Windows NT Installation Files

Copy the contents of the i386 (and subdirectories) from the original Windows NT distribution CD into the corresponding i386 directory on the distribution server.

TIP: Replacement Driver required for NTFS conversion—SETUPDD.SYS

There is a known problem with automatic conversion and extension of FAT to NTFS in Windows NT prior to Service Pack 3. To avoid this issue, copy the SETUPDD.SYS file from Service Pack 3 into the Windows NT distribution directory. For more information, see Knowledge Base article 143473, Title: Unattended Setup Stops and Says Press Any Key to Shut Down.

TIP: Reducing files copied during setup

During the text mode portion of unattended setup, Windows NT copies all files from the DRVLIB.NIC distribution directory onto the local hard disk. This directory contains all network drivers supplied with Windows NT and is approximately 20 MB. You can optimize network download times and storage overhead by removing non-required drivers from this directory.

If you don't need Internet services you can delete the contents of INETSRV but leave the directory name: this prevents a "file not found" error during Windows NT installation. If you remove the name, you can avoid the error message by removing (or commenting out) the INETSRV entry in DOSNET.INF.

Preparing Application Directories

Create a directory structure to enable modular storage of application software. Copy the applications into unique (obvious) directories within the application structure, and to put the installation scripts in cmdFiles.

Create the $OEM$ structure

Create the $OEM$ structure beneath i386, ensuring the syntax and relative position of directories is correct.

TIP: Enabling processing of $OEM$ structure during setup

To enable processing of the $OEM$ structure, make sure the OemPreInstall=YES value is specified in the answer file.

TIP: OEM NIC drivers

Ensure that all OEM NICs are placed in unique sub-directories beneath NET.

Unattended Answer Files

Use Setup Manager to create an unattended answer file for each PC with a different hardware configuration. Store these files in the Answer directory on the deployment server.

TIP: Removing EndUser License Dialog

Even though you are configuring Windows NT for unattended installation, by default it displays the End User License Agreement dialog and waits for a response. You can avoid this by adding the "OEMSkipEULA = yes" value to the [Unattended] section of the answer file. If Setup Manager later modifies the answer file, it deletes this line and you will have to put it back in.

TIP: How to determine NIC parameters

When you are specifying the configuration parameters for OEM network cards, you may have trouble finding the appropriate values. You can find them by manually installing the NIC drivers and examining the registry key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\<service name>\Parameters, where <service name> is the name of the network driver.

Boot disk

Create an MS-DOS boot disk with device drivers to enable logical drive connection to the distribution device. Include hard disk preparation utilities in addition to the START.BAT file (and utilities) required in phase 1.

Phase 1—System Preparation Walkthrough

Phase 1 begins with an MS-DOS boot disk that is configured with the appropriate device drivers to provide connectivity to the distribution device. In the example case, the deployment server is Windows NT, so the disk is configured with Microsoft Networking for MS-DOS, and contains the necessary files for hard disk preparation (FDISK and Format). It also stores START.BAT—the batch file (command script) that controls phase 1.

START.BAT depends on three MS-DOS utilities stored on the boot disk: GetLine, Set_Ini!, and ShowMenu. These are highlighted in this section and detailed in "MS-DOS Utilities" section beginning on page 673. Figure 11.6 outlines boot disk functionality.

Figure 11.6: Boot disk functionality.

Here is a typical AUTOEXEC.BAT file from a network boot disk:

@ECHO OFF
ECHO Network Install – BOOT DISK
SMARTDRV C+                    ;See [1] below

NET START
NET USE K: \\FILESERV\NTBUILD
A:\START.BAT                    ;See [2] below

Notes on sample AUTOEXEC.BAT file:

[1]—Smartdrv with write-behind caching to improve file-copy speed during initial MS-DOS-based phase.

[2]—This is the Windows NT pre-configuration script. It generates answer files and initiates phase 2.

Partitioning the Hard Disk

To receive Windows NT for the first time, the PC must have an MS-DOS formatted FAT partition large enough to contain Windows NT and the associated $OEM$ directory structure and temporary files. During phase 2, if you set FileSystem = ConvertNTFS in the answer file, Windows NT automatically converts FAT to NTFS.

TIP: How to install Windows NT on disks <2 GB

On hard drives larger than 2 GB, MS-DOS cannot access data beyond the 2-GB boundary (beyond 1-GB on some systems). During FAT to NTFS conversion, Windows NT provides a feature to extend the installation partition to the maximum size of the disk. This feature is enabled by the OemExtendPartition = 1, nowait parameter in conjunction with FileSystem = ConvertNTFS. Both parameters are in the [Unattended] section of the answer file. On hard disks larger than 4 GB, SP4 is required in conjunction with this feature.

TIP: Decreasing disk preparation time

If you use the feature outlined above you can reduce the time it takes to prepare and format the initial FAT partition by defining a partition large enough to support the installation of phase 2, and allowing Windows NT to extend the partition before applications are installed.

START.BAT—Generating Configuration Information

START.BAT, located on the boot disk, generates all configuration information required for subsequent phases. The information is stored in two files placed on the root of the newly prepared hard disk:

• C:\UNATTEND.TXT—A Windows NT answer file with configuration information unique to the current PC, generated by copying a skeleton answer file from the Answer directory on the distribution server onto the local hard disk and merging machine- and user-specific information. To modify section/value format text files within batch files, use the MS-DOS utility SET_INI!.

• C:\NETWORK.BAT or C:\CDROM.BAT—An MS-DOS batch file with environment variables used to determine drive paths (for the distribution server), computer name, domain name, and configuration group (enables support for multi-department/user configurations discussed in phase 4). The file name indicates the type of distribution device used for deployment.

You can configure START.BAT to provide all configuration information automatically, but to do it you need to create a unique boot disk for each workstation/user. Figure 11.7 illustrates START.BAT logic.

Figure 11.7: START.BAT logic.

The following codes are spaced so that it is easier to read. Lines are broken for layout only: entries should be on a single line.

START.BAT—Listing

In this example, START.BAT is configured to request a minimal set of configuration data from an installation engineer and write it to the files described above.

@echo off
SET netfile=C:\NETWORK.BAT               ;See [1] below
SET cdfile=C:\CDROM.BAT
SET ansfile=C:\UNATTEND.TXT
@ERASE %NETFILE%
@ERASE %CDFILE%
@ERASE %ANSFILE%
CLS

:main
ECHO.
ECHO Example Main Menu
ECHO.
ECHO [A] Network Installation
ECHO [B] CDROM Installation
ECHO.
ECHO Use cursor keys to select, or ESC to cancel:

SHOWMENU A B /E=choice                    ;See [2] below
IF ERRORLEVEL 27 GOTO exit

IF %choice% == A GOTO getNetInfo
IF %choice% == B GOTO getCDROMInfo

:getNetInfo
GETLINE Domain Name:  /L=15 /E=DOMAIN
IF ERRORLEVEL 27 GOTO exit

GETLINE Configuration Group: /L=10 /E=GROUP     ;See [3]  below
IF ERRORLEVEL 27 GOTO exit

GETLINE Source UNC Path: /L=30 /E=SRCUNC
IF ERRORLEVEL 27 GOTO exit

GETLINE Logical Drive: /L=2 /E=SRCDRV          ;See [4] below
IF ERRORLEVEL 27 GOTO exit

ECHO SET GROUP=%GROUP%>%NETFILE%
ECHO SET SRCUNC=%SRCUNC%>>%NETFILE%          ;See [5] below
ECHO SET SRCDRV=%SRCDRV%>>%NETFILE%

ECHO SET DOMAIN=%DOMAIN%>>%NETFILE%
GOTO adapters

:getCDROMInfo
GETLINE Domain Name:  /L=15 /E=DOMAIN
IF ERRORLEVEL 27 GOTO exit

GETLINE Configuration Group: /L=10 /E=GROUP     ;See [3]  below
IF ERRORLEVEL 27 GOTO exit

GETLINE CDROM Drive Letter: /L=2 /E=SRCDRV
IF ERRORLEVEL 27 GOTO exit

ECHO SET GROUP=%GROUP%>%CDFILE%
ECHO SET SRCDRV=%SRCDRV%>>%CDFILE%
ECHO SET DOMAIN=%DOMAIN%>>%CDFILE%
GOTO adapters

:adapters
CLS

ECHO.
ECHO Main Build Menu
ECHO.
ECHO [A] Example Machine with 3c90x Network Card
ECHO [B] Example Machine with autodetected network card
ECHO.

SHOWMENU A B /E=choice
IF ERRORLEVEL 27 GOTO exit

GETLINE Computer Name:  /L=15 /E=CNAME
IF ERRORLEVEL 27 GOTO exit

IF %choice% == A GOTO 3com
IF %choice% == B GOTO autoDetect

:3com
ECHO Mode: 3c90x
COPY %SRCDRV%\ANSWER\3C90X.TXT %ANSFILE%
GOTO modifyComputerName

:autoDetect
ECHO Mode: Auto
COPY %SRCDRV%\ANSWER\GENERIC.TXT %ANSFILE%
GOTO modifyComputerName

:modifyComputerName
SET_INI! %ANSFILE% [UserData] "ComputerName = %CNAME%" ;See [6] below

:runNTInstall
:.\NT4\I386\WINNT /B /S:.\NT4\I386 /U:%ANSFILE%      ;See [7] below

:exit

Notes on START.BAT—Listing:

[1]—Paths of all files generated by this script are stored in environment variables for easy maintenance. Any legacy configuration files are erased from the destination hard disk to ensure consistency.

[2]—The SHOWMENU utility provides menu handling facilities within the batch file. It stores the user input in an environment variable called choice, which can be queried by traditional IF statements. The use of ERRORLEVEL enables phase 1 to be aborted with the ESCAPE key.

[3]—Group refers to the groups directory structure beneath $OEM$. This environment variable is used by phase 3 to detect the appropriate configuration group for phase 4.

[4]—GetLine is a command-line utility that enables the retrieval of keyboard input during a batch file. It stores the input in an environment variable defined by /E switch.

[5]—Environment variables are written to the NETWORK.BAT file.

[6]—The answer file is personalized with ComputerName information. This technique can be extended to include any data that must be unique. For example: Internet Protocol (IP) address.

[7]—Phase 2 is initialized.

NETWORK.BAT—Listing

SET GROUP=example1
SET SRCUNC=\\ZIPPY\BUILDSRV
SET SRCDRV=T:
SET DOMAIN=TSTDOM

UNATTEND.TXT—Listing

[Unattended]
OemSkipEula = yes
OemPreinstall = yes
NoWaitAfterTextMode = 1
NoWaitAfterGUIMode = 1
FileSystem = ConvertNTFS
ExtendOEMPartition = 1, nowait
ConfirmHardware = no
NtUpgrade = no
Win31Upgrade = no
TargetPath = \winnt
OverwriteOemFilesOnUpgrade = no
KeyboardLayout = "United Kingdom"

[OEM_Ads]
Banner = "Windows NT Workstation * Example Build"
Background = buildbmp.bmp

[UserData]
FullName = "Example UserName"
OrgName = "Example OrgName"
ComputerName = EXCOMP1

[GuiUnattended]
OemSkipWelcome = 1
OEMBlankAdminPassword = 1
TimeZone = "(GMT) Greenwich Mean Time"

[Display]
ConfigureAtLogon = 0
BitsPerPel = 4
XResolution = 640
YResolution = 480
VRefresh = 60
AutoConfirm = 1

[Network]
InstallAdapters = SelectedAdaptersSection
InstallProtocols = ProtocolsSection
InstallServices = ServicesSection
JoinWorkgroup = TSTWRK

[SelectedAdaptersSection]
3C905 = OEMAdapterParamSection, \$OEM$\NET\3c90x\

[OEMAdapterParamSection]

[ProtocolsSection]
TC = TCParamSection

[TCParamSection]
DHCP = YES

[ServicesSection]

Starting Phase 2

Once the answer and configuration files have been generated, START.BAT invokes the Windows NT setup routine and specifies the answer file as a command-line parameter. For example:

%SRCDRV%\NT4\I386\WINNT /B /S:%SRCDRV%\NT4\I386 /U:%ANSFILE%

Phase 2—Installation of Windows NT Walkthrough

Based on a traditional unattended Windows NT setup, Phase 2 is a combination of floppy-less and unattended installation mechanics. Before the unattended installation starts, the setup routine copies all files from the distribution server (including those ordinarily located on the retail Windows NT boot disks), and creates directories on the local hard disk.

Directories created by setup.

After files have been copied, the boot sector and BOOT.INI files are modified; the system is rebooted and the initial text mode portion of Windows NT setup begins. The load process proceeds as follows:

1. NT executive/kernel—Loads NTKRNLMP.EXE.

2. Hardware abstraction layer—HAL486C.DLL, HALAPIC.DLL, HALMCA.DLL, HALMPS.DLL, HALMPSM.DLL, HALNCR.DLL – depending on hardware detected.

3. SETUPREG.HIV—A small registry containing a minimal currentcontrolset with i8042, PCMCIA and setupDD configuration.

4. Locale specific data—Loads locale-specific codepage data.

5. Setup font—Loads VGAOEM.FON for use during GUI-mode setup.

6. Windows NT kernel mode setup—Loads SETUPDD.SYS, a kernel mode driver that performs operating system installation.

7. Video driver—Loads VGA.SYS and VIDEOPRT.SYS

8. Keyboard driver—Loads i8042prt.sys, KBDCLASS.SYS and KBDxx where xx represents country.

9. FAT driver—Loads FASTFAT.SYS.

10. SCSI port driver—AIC78XX.SYS, AMI0NT.SYS, etc.—depending on hardware detected.

11. IDE/ESDI HDD controllers—Loads ATDISK.SYS.

12. MCA HDD controllers—Loads ABIODISK.SYS.

13. ATAPI CDROM—Loads ATAPI.SYS.

14. NTFS driver—Loads NTFS.SYS.

After the low-level hardware drivers are installed (HAL, disk controllers, bus, keyboard, etc.) the hard disk is checked for errors, and the files needed to boot Windows NT into GUI are copied (from the temporary) into the destination directory specified by the answer file. Then the remaining contents of the temporary directory \$ are distributed to their appropriate locations and the computer is rebooted.

On reboot, Windows NT enters GUI mode setup. The video, network, computer-name, and locale details are automatically configured using the answer file. The remaining Windows NT programs and accessories are copied from temporary into the destination directory. Finally, the contents of the CMDLINES.TXT file are processed. This applies the Windows NT Service Pack and makes registry changes to initialize phase 3. When this is complete, temporary directories are deleted and the operating system is rebooted.

On reboot, Windows NT automatically initializes phase 3.

$OEM$ Directory Structure

The unattended installation makes extensive use of the $OEM$ directory structure. All files required for the installation or subsequent configuration of Windows NT are located within $OEM$. This ensures that they are copied to the local hard drive as an integral part of the installation. The following sub-sections detail the additional files and modifications required for the example installation.

$OEM$ Contents

• **CMDLINES.TXT—**A text file containing commands that are executed upon completion of GUI mode setup. As shown below, this file makes two registry changes using REGEDIT and begins a silent installation of Service Pack 3.

[Commands] ".\regedit /s .\run.reg" ".\regedit /s .\autolog.reg" ".\nt4sp3\update.exe -u -f -n"

• REGEDIT.EXE. The Windows NT registry editor, copied into the root of $OEM$ for convenient use within CMDLINES.TXT.

• RUN.REG. A text file that is processed by RegEdit, and modifies the registry to automatically execute the phase 3 command script at next logon.

REGEDIT4 [HKey_Local_Machine\SOFTWARE\Microsoft\Windows\CurrentVersion\Run] "NTConfiguration"="C:\BUILD\GSCRIPTS\PHASE3.CMD"

TIP: Run and RunOnce Registry Keys

You can use an alternative registry key (RunOnce) for this purpose. The advantage is that once the auto-executed application has been executed, its registry presence is automatically removed. The disadvantage of this key is that it executes application before the desktop is completely initialized, and, more importantly, its contents can be executed prematurely as discussed in Knowledge Base article 173039, Title: RUNONCE Key Is Processed Immediately When RUNDLL32 Is Called.

• AUTOLOG.REG. A text file that is processed by RegEdit; it modifies the registry to allow Windows NT to logon automatically as administrator at next reboot.

REGEDIT4 [HKey_Local_Machine\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon] "DefaultUserName"="administrator" "DefaultPassword"="" "AutoAdminLogon"="1"

• NT4SP3 (directory). A directory containing all files from Service Pack 3.

TIP: Reducing file transfers during SP3 installation

Inclusion of Service Pack 3 directly beneath the $OEM$ structure (as opposed to $OEM$\C) reduces number of file transfers during phase 2. This is because the service pack is applied directly from \$\NT4SP3, as opposed to being moved to a permanent directory first.

• NET (directory)—A directory containing a series of subdirectories (with drivers) for each network card not supported by the retail NIC drivers. This directory is referenced in the unattended answer files.

$OEM$\$$\System32 Contents

The files and directories within this portion of the $OEM$ structure are automatically copied into the System32 path of Windows NT installation directory. They provide core services to the configuration scripts of future phases.

• NETDOM. A command-line utility from the NT Resource Kit (supplement 2) that enables Windows NT to join a domain within a command-script.

• REG. A command-line utility from the NT Resource Kit that enables registry modification from within a command script.

• SLEEP. A command-line utility from the NT Resource Kit that can be used within command-scripts to cause periods of delay. This is used during application installation phase to reduce the amount of CPU activity in script loops.

• NTRIGHTS. A command-line utility from the NT Resource Kit that enables the granting and revoking of user rights from a command script.

• SHUTDOWN. A command-line utility that enables the shutdown and reboot of Windows NT from a command-script.

• ScriptIT. A utility that enables the automation of dialogs from the script file. This utility is used to configure aspects of Windows NT that cannot generally be automated, and to install applications that are not supplied with unattended installation routines.

$OEM$\C\BUILD—Contents

$OEM$ is used to deliver a build structure to the local "C" drive. This structure contains the configuration scripts for phase 3 onwards, and drivers that will be installed onto Windows NT after phase 2.

\$oem$
          \$$
          \Apps
               \System32
          \C
               \Build
                    \Drivers
                         \Audio
                    \Groups
                         \Example1
                    \Gscripts
          \Net
          \NT4sp3

Figure 11.8 Directory names in build structure.

Notes on Figure 11.8:

• Audio. Contains drivers that were not supplied on the retail CD and cannot be installed in phase 2.

• Groups. Root directory for all department-specific parent scripts. Each subdirectory contains a PHASE4.CMD file and generally multiple package files.

• Gscripts. Directory containing phase 3 (cross department) configuration scripts and all configuration scripts.

Logic Overview

Figure 11.9 is an overview of stages in phase 2, which uses the traditional Windows NT unattended installation routine. Phase 3 is initialized by setting the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run registry key to C:\\BUILD\\GSCRIPTS\\PHASE3.CMD, configuring auto-admin logon and rebooting the workstation.

Figure 11.9: Phase 2 overview.

Phase 3—Global Windows NT Configuration Walkthrough

Phase 3 allows you to apply company-wide Windows NT configuration parameters and install drivers—tasks not supported by the unattended answer file. Do not use this phase to install application software.

Phase3.CMD, the parent control routine responsible for managing phase 3, is located in the C:\BUILD\GSCRIPTS directory. It establishes connection with the deployment device based on presence and the contents of the NETWORK.BAT or CDROM.BAT file generated in phase 1.

Once connection is established, Phase3.CMD calls a sequence of child (configuration) scripts that perform the configuration. In this example the configuration scripts modify the boot-loader timeout to 5 seconds, configure Windows NT locale information for UK, and limit the size of Event Log files.

When these scripts have been executed, phase 3 removes itself from the "Run" registry key and copies the appropriate phase 4 control script into the Windows NT common "Startup" group before rebooting the workstation.

Each configuration group (department) has its own phase 4 control file, located in a separate subdirectory beneath the "groups" directory. Phase3.CMD uses the %GROUP% environment variable obtained during phase 1 (and stored in CDROM.BAT or NETWORK.BAT) to determine which phase 4 control file to copy.

PHASE3.CMD—File Listing

The following codes are spaced so that it is easier to read. Lines are broken for layout only: entries should be on a single line.

@ECHO OFF
SET netFILE=C:\NETWORK.BAT
SET cdFILE=C:\CDROM.BAT                    ;See [1] below
SET oemBuildPath=C:\BUILD

IF EXIST %cdFILE% GOTO runCDFILE
IF EXIST %netFILE% GOTO runNETFILE          ;See [2] below
GOTO noConfigFile
PHASE3.CMD      (continued)
:runCDFILE
CALL %cdFILE%                              ;See [3]  below
GOTO okCONTINUE

:runNETFILE
CALL %netFILE%
SLEEP 30
NET USE /persistent:no
NET USE %SRCDRV% %SRCUNC%               ;See [4] below
IF NOT EXIST %SRCDRV%\*.* GOTO noNetworkPath
GOTO okCONTINUE

:okCONTINUE
CALL %oemBuildPath%\gscripts\bootldr.cmd     ;See [5]  below
CALL %oemBuildPath%\gscripts\locale.cmd
CALL %oemBuildPath%\gscripts\eventlog.cmd

ECHO Y|REG DELETE "HKLM\SOFTWARE
\Microsoft\Windows\CurrentVersion\Run\NTConfiguration"

REM ** PREPARE FOR PHASE4 **
REGEDIT /S C:\BUILD\gScripts\AUTOLOG.REG
COPY %oemBuildPath%\GROUPS\%GROUP%\PHASE4.CMD "%WINDIR%
\PROFILES\ALL USERS\START MENU\PROGRAMS\STARTUP"
IF ERRORLEVEL=1 GOTO noPhase4

SHUTDOWN /L /R /T:0 /Y
GOTO end

:noConfigFile
CLS
COLOR C
ECHO ******************** ERROR
_*****************************_
ECHO Cannot Find C:\CDROM.BAT OR C:\NETWORK.BAT
ECHO Ensure BOOTDISK has created files...
ECHO
_********************************************************_
PAUSE
COLOR
GOTO END

:noPhase4
CLS
COLOR C
ECHO ******************** ERROR
_*****************************_
ECHO Cannot find script to initialise phase4
ECHO %oemBuildPath%\GROUPS\%GROUP%\PHASE4.CMD is missing!
ECHO
_********************************************************_
PAUSE
COLOR
GOTO END
:noNetworkPath
CLS
COLOR C
ECHO ************************** ERROR
_************************_
ECHO Cannot establish connection to network server
resource:
ECHO %SRCDRV% %SRCUNC%
ECHO
_********************************************************_
PAUSE
COLOR
GOTO END
:END

Notes on PHASE3CMD.CMD—File Listing:

[1]—All file paths are represented by environment variables.

[2]—Checks for presence of configuration files generated in phase 1. If neither is found, an error is reported. This could be extended to cover the eventuality of both files being present.

[3]—File is executed, instantiating the variables it contains.

[4]—Test valid network connection.

[5]—Child configuration scripts are executed.

The configuration scripts executed as part of the phase 3 parent routine are explained in the following sections.

BOOTLDR.CMD—File Listing

This uses RunDLL32 (the Windows NT utility for executing exported functions in DLLs) to configure the Windows NT setup engine for processing BOOT.INF (shown below), which contains changes relevant to BOOT.INI.

@echo off
echo Modifying BOOT.INI to 5 Seconds
START /WAIT ATTRIB -R -S -H C:\BOOT.INI
START /WAIT rundll32 setupapi,InstallHinfSection
DefaultInstall 128 C:\BUILD\GSCRIPTS\boot.inf
START /WAIT ATTRIB +R +S +H C:\BOOT.INI

BOOT.INF—File Listing

; Example INF file to modify boot loader for
; 5 second delay
[Version]
Signature = "$Windows NT$"

[DefaultInstall]
AddReg = AddReg
DelReg = DelReg
UpdateInis = UpdateInis

[AddReg]
[DelReg]
[UpdateInis]
"C:\boot.ini","boot loader",,"timeout=5"

EVENTLOG.CMD—File Listing

The following script configures each workstation's Event Log so that the Application, System, and Security logs won't exceed 1 MB each:

REM Event Log Settings

REG UPDATE "HKLM\SYSTEM\CURRENTCONTROLSET\SERVICES\EVENTLOG\APPLICATION\MAXSIZE=1048576"

REG UPDATE "HKLM\SYSTEM\CURRENTCONTROLSET\SERVICES\EVENTLOG\APPLICATION\RETENTION=0"

REG UPDATE "HKLM\SYSTEM\CURRENTCONTROLSET\SERVICES\EVENTLOG\SECURITY\MAXSIZE=1048576"

REG UPDATE "HKLM\SYSTEM\CURRENTCONTROLSET\SERVICES\EVENTLOG\SECURITY\RETENTION=0"

REG UPDATE "HKLM\SYSTEM\CURRENTCONTROLSET\SERVICES\EVENTLOG\SYSTEM\MAXSIZE=1048576"

REG UPDATE "HKLM\SYSTEM\CURRENTCONTROLSET\SERVICES\EVENTLOG\SYSTEM\RETENTION=0"

LOCALE.CMD—File Listing

This script configures the default-user and administrator locales for use in the UK. (This example shows a UK set up.)

: Define locale changes from US to UK

REM= Update Local Admin

REG UPDATE "HKCU\Control Panel\International\iCountry=44"

REG UPDATE "HKCU\Control Panel\International\iDate=1"

REG UPDATE "HKCU\Control Panel\International\iMeasure=0"

REG UPDATE "HKCU\Control Panel\International\iNegCurr=1"

REG UPDATE "HKCU\Control Panel\International\iTime=1"

REG UPDATE "HKCU\Control Panel\International\iTLZero=1"

REG UPDATE "HKCU\Control Panel\International\Locale=00000809"

REG UPDATE "HKCU\Control Panel\International\s1159=AM"

REG UPDATE "HKCU\Control Panel\International\s2359=PM"

REG UPDATE "HKCU\Control Panel\International\sCountry=United Kingdom"

REG UPDATE "HKCU\Control Panel\International\sCurrency=£"

REG UPDATE "HKCU\Control Panel\International\sLanguage=ENG"

REG UPDATE "HKCU\Control Panel\International\sLongDate=dd MMMM yyyy"

REG UPDATE "HKCU\Control Panel\International\sShortDate=0"

REM= Update Default

REG UPDATE "HKU\Default\Control Panel\International\iCountry=44"

REG UPDATE "HKU\Default\Control Panel\International\iDate=1"

REG UPDATE "HKU\Default\Control Panel\International\iMeasure=0"

REG UPDATE "HKU\Default\Control Panel\International\iNegCurr=1"

REG UPDATE "HKU\Default\Control Panel\International\iTime=1"

REG UPDATE "HKU\Default\Control Panel\International\iTLZero=1"

REG UPDATE "HKU\Default\Control Panel\International\Locale=00000809"

REG UPDATE "HKU\Default\Control Panel\International\s1159=AM"

REG UPDATE "HKU\Default\Control Panel\International\s2359=PM"

REG UPDATE "HKU\Default\Control Panel\International\sCountry=United Kingdom"

REG UPDATE "HKU\Default\Control Panel\International\sCurrency=£"

REG UPDATE "HKU\Default\Control Panel\International\sLanguage=ENG"

REG UPDATE "HKU\Default\Control Panel\International\sLongDate=dd MMMM yyyy"

REG UPDATE "HKU\Default\Control Panel\International\sShortDate=0"

Phase 4—Application Installation Walkthrough

Phase 4 automates Windows NT configuration and the installation of application software for specific department (group) requirements. It allows you to use a single build mechanism to deploy different configurations (operating system and applications) simply by specifying a configuration "group" on the boot disk.

The individualized sets of command scripts for each group are located in a group-name directory beneath "Groups" on the build tree. The example in Figure 11.10 shows that one group directory (Example1) has been created. This approach keeps the control-logic for different customizations separate, reducing the likelihood of cross-group errors resulting from manual script modifications.

     \$oem$
          \$$
               \System32
          \C
               \Build
                    \Drivers
                         \Audio
                    \Groups
                         \Example1
                    \Gscripts

Figure 11.10 Command script directory structure.

Three-Tier Command-Scripts

In addition to the group directory structure, a three-tier command-script architecture is implemented, which introduces the concept of a "package."

A package is a logical grouping of configuration changes—software installation or Windows NT configuration modifications—that are either strongly related or must be performed before a reboot. Figure 11.11 shows that a package has a parent/child relationship with multiple configuration scripts that perform the actual configuration change.

Figure 11.11: Parent/child package relationship.

Aside from the advantages of modularity, packages enable phase 4 to persist over the multiple reboots that may result from the installation of application software. One of the most important features of a package is that it can be executed only once; subsequent execution attempts are ignored. This reduces complexity of the phase 4 parent control routine.

Phase 4—Parent Control

Phase4.CMD, the parent control script for phase 4, reads the NETWORK.BAT (or CDROM.BAT) configuration file and establishes logical drive connectivity with the distribution device. Then it changes the working directory to the local configuration group (Example1) as defined by the %GROUP% variable, and sequentially executes each package file within the group.

Phase 4 is initialized using the startup group, as opposed to the "Run" or "RunOnce" registry keys. This has a couple advantages:

• All packages are executed after the desktop environment is fully initialized, significantly reducing the likelihood of failure if the setup routine requires desktop interaction.

• Some software applications have a two-part installation process that modifies the Run/RunOnce key and causes a reboot. Upon logon, the software application finalizes its configuration. If phase 4 used these keys, the two-part installer (from the previous reboot) and a new package file might execute concurrently, creating an inconsistent configuration. Use of the startup feature prevents this problem.

Once all child scripts have been executed, phase 4 passes execution control to PHASE5.CMD.

Package Script—File Listing (PKG1)

In addition to calling child configuration routines, a package has other configurable properties.

Configurable package properties.

The PKG1.CMD file from Example1 group, is listed and annotated below. The other package files (PKG2.CMD, for example) have this format and different header and child-script calls.

The following codes are spaced so that it is easier to read. Lines are broken for layout only: entries should be on a single line.

@ECHO OFF

SET reboot=WAIT                    ;See [1] below
SET autoLogon=YES
SET oemBuildPath=C:\BUILD

IF NOT DEFINED oemBuildPath GOTO definedError  ;See [2]  below
IF NOT DEFINED reboot GOTO definedError
IF NOT DEFINED autoLogon GOTO definedError

IF NOT EXIST %oemBuildPath% GOTO pathError
IF EXIST %oemBuildPath%\%0 GOTO exit            ;See [3]  below

ECHO Installing Package %0
REM ** CALL CHILD CONFIGURATION SCRIPTS HERE **
CALL %SRCDRV%\CMDFILES\OFF97.CMD             ;See [4]  below

CALL %SRCDRV%\CMDFILES\OL98.CMD
:updateStatus
ECHO Package Install Complete>%oemBuildPath%\%0 ;See [5]  below

:autoLogonCheck
IF %autoLogon%==NO goto rebootCheck
REG UPDATE
"HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion
\Winlogon\DefaultUserName=administrator"
REG UPDATE
"HKLM\SOFTWARE\Microsoft\WindowsNT\CurrentVersion
\Winlogon\DefaultPassword="
REG UPDATE
"HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion
\Winlogon\AutoAdminLogon=1

:rebootCheck
IF %reboot%==NO GOTO exit
IF %reboot%==WAIT GOTO rebootWait
ECHO Forcing System Shutdown ...                ;See [6]  below
START /WAIT SHUTDOWN /L /R /T:5 /Y
GOTO exit

:rebootWait
SLEEP 5                                   ;See [7]  below
ECHO Waiting for reboot...
GOTO rebootWait

:definedError
COLOR 4F
ECHO *************************** ERROR
_***********************_
ECHO Environment Variable Not Defined In Package: %0
ECHO Package Installation Failed!
ECHO
_********************************************************_
PAUSE
GOTO exit

:pathError
COLOR 4F
ECHO ************************** ERROR
_**************************_
ECHO Directory %oemBuildPath% not found!
ECHO Package Installation Failed!
ECHO
_********************************************************_
PAUSE
GOTO exit

:exit

Notes on Package Script—File Listing (PKG1):

[1]—Environment variables as defined in the table above this sample. Reboot is configured to WAIT because Outlook 98 (deployed in this package) forces a system reboot.

[2]—Error checking.

[3]—Test to determine if package has been executed before.

[4]—Installation of application software.

[5]—Write completion data to prevent subsequent execution.

[6]—Reboot workstation.

[7]—Loop until application causes reboot.

Example Phase 4 Control File

The phase 4 control file establishes logical drive connection to the deployment server, reads the configuration batch file from hard disk, then executes package files in sequence. Here is an example file:

The following codes are spaced so that it is easier to read. Lines are broken for layout only: entries should be on a single line.

@ECHO OFF
SET netFILE=C:\NETWORK.BAT
SET cdFILE=C:\CDROM.BAT                    ;See [1] below
SET oemDrive=C:
SET buildPath=BUILD
PHASE 4 SCRIPT      (continued)
SET oemBuildPath=%oemDrive%\%buildPath%
IF EXIST %cdFILE% GOTO runCDFILE
IF EXIST %netFILE% GOTO runNETFILE          ;See [2] below
GOTO noConfigFile

:runCDFILE
CALL %cdFILE%
GOTO okCONTINUE

:runNETFILE
CALL %netFILE%
SLEEP 30                         ;See [3] below
NET USE /persistent:no
NET USE %SRCDRV% %SRCUNC%
IF NOT EXIST %SRCDRV%\*.* GOTO noNetworkPath
GOTO okCONTINUE

:okCONTINUE
%oemDrive%                         ;See [4] below

CD %oemBuildPath%\Groups\%group%
IF %ERRORLEVEL% GEQ 1 GOTO groupError
CALL pkg1.cmd                              ;See [5]  below
CALL pkg2.cmd

CD %oemBuildPath%\gscripts
PHASE5.CMD

GOTO end

:noConfigFile
CLS
COLOR C
ECHO ************************* ERROR
_**************************_
ECHO Cannot Find C:\CDROM.BAT OR C:\NETWORK.BAT
ECHO Ensure BOOTDISK has created files...
ECHO
_********************************************************_
PAUSE

COLOR
GOTO END

:noPhase4
CLS
COLOR C
ECHO ************************ ERROR
_************************_
ECHO Cannot find script to initialise phase4
ECHO %oemBuildPath%\GROUPS\%GROUP%\PHASE4.CMD is missing!
ECHO
_*******************************************************_
PAUSE
COLOR
GOTO END
:noNetworkPath
CLS
COLOR C
ECHO **************************** ERROR
_*************************_
ECHO Cannot establish connection to network server
resource:
ECHO %SRCDRV% %SRCUNC%
ECHO
_********************************************************_
PAUSE
COLOR
GOTO END

:groupError
CLS
COLOR C

ECHO ********************** ERROR
_*****************************_
ECHO Cannot Change to Group Directory
ECHO %oemBuildPath%\Groups\%group%
ECHO
_********************************************************_
PAUSE
COLOR
GOTO END

:END

Notes on Example Phase 4 Control File:

[1]—All file paths are represented by environment variables.

[2]—Checks for presence of configuration files generated in phase 1. If neither is found, an error is reported. This can be extended to cover the eventuality of both files being present.

[3]—Test valid network connection.

[4]—Change working directory to appropriate configuration group as defined by %group%.

[5]—Execute packages then pass control to phase 5.

Installing Third-Party Applications

To keep the build as flexible and extensible as possible, vendor-supplied installation routines are used for all application software. No snapshot technology is used. Given the complexity of modern applications, and their potential interoperability with other software, this approach ensures that applications configure themselves appropriately with respect to other software on the workstation.

Most installation routines supplied with software support unattended setup (sometimes referred to as batch-mode, silent, or quiet setup), but if you have to install one that doesn't you can automate the process with ScriptIT (see page 676).

Even when applications support unattended installation, their preparation and deployment mechanics can vary. Here is a general guideline for integrating applications into the build:

1. Copy the contents of the original distribution into a unique directory on the deployment server.

2. Generate an unattended configuration file (sometimes called a response file) for the application. You may need additional tools to do this. Wherever possible, ensure that the application does not automatically reboot Windows NT; if you can't avoid this, make the application the last entry in the package file and set the package header to WAIT.

3. Create a configuration script that executes the installation routine (using a response file) and store the script in the application scripts folder on the deployment server (cmdFiles, in the example).

If the installation routine does not support unattended setup, step 2 is replaced by the manual generation of a ScriptIT script that contains automated responses to the setup dialogs. This file is stored in the same location as (3).

The next sections illustrate this process by showing the installation of four commercial applications with different installation routines.

Installing Microsoft Office 97 with Service Release 1

Microsoft Office is supplied with an installation routine that supports unattended setup when used in conjunction with the Network Installation Wizard. This is an Office Resource Kit tool (available from https://www.microsoft.com/office/ork/xp/default.htm) that modifies the administrative installation table file (.STF) for the Office setup program, enabling automated configuration of information that ordinarily requires interaction.

Here are the steps needed to integrate Office 97 into the modular build:

1. Create a unique directory beneath Apps called Office97, and copy the entire contents of the Office97 CD into it.

2. Create a unique directory beneath Office97 called SR1, and copy the contents of Service Release 1 into it.

3. Use the Network Installation Wizard to pre-configure all necessary options for Office97. Be sure to save the modified configuration files to the Office97 directory on the deployment server.

4. Create a configuration script to install Office97 and Service Release 1, and store it in the application scripts directory. An example script is shown below:

@echo off echo Installing Office97 /w Service Pack1 start /wait %SRCDRV%\apps\OFFICE97\SETUP /B2 /Q1N

rem Install Service Release start /wait %SRCDRV%\apps\OFFICE97\SR1\SR1 /q

Installing Visio5

Visio5 uses InstallShield technology to perform its setup and configuration. InstallShield has built-in support for unattended installations using response files, and requires no additional tools for configuration.

Here are the steps needed to integrate Visio5 (or any InstallShield application that supports unattended installation) into the modular build:

1. Create a unique directory beneath Apps, called Visio5 and copy the entire contents of the Visio5 distribution into it.

2. Using a pre-built workstation that does not currently have Visio installed, connect to the distribution directory and execute the Visio setup routine, specifying the -r switch to enable automatic generation of a response file.

3. Complete the attended Visio installation. Your responses to configuration questions are recorded to the response file SETUP.ISS that has been placed in the %SYSTEMROOT% directory.

4. When you have configured Visio, copy the response file from %SYSTEMROOT% into the Visio5 directory on the distribution server that contains the SETUP executable.

5. Create a command script to install Visio5, and store it in the application scripts directory. Here is an example script:

@echo off echo Installing Visio5 START /WAIT %SRCDRV%\apps\VISIO5\SETUP -S :loopBack sleep 30 IF EXIST "%TEMP%_ISTMP0.DIR" GOTO loopBack :end

TIP: Preventing premature script continuation

Using the START /WAIT parameter in the installation script causes Windows NT to stop processing further command-script lines until SETUP is terminated. During installation of an InstallShield-driven application, the SETUP executable may initialize another process to perform the actual installation, terminating the original process. If SETUP.EXE terminates before the application is installed, Windows NT resumes (premature) execution of phase 4 command scripts.

To prevent this, the script checks for the presence of a temporary directory (_ISTMP0.DIR) created by InstallShield in the %temp% directory. InstallShield automatically removes this directory when the installation is complete, so its is used to determine script termination.

TIP: Using

The sleep command is used to reduce the high CPU utilization that would result from a loop structure in a command-script.

Installing Outlook 98

Due to the complexity and potential configuration variance possible in Outlook 98, you should use the Outlook Deployment Kit to manage the installation. It enables the pre-configuration of both Outlook 98 and Internet Explorer 4.01 by generating the executables, configuration data, and setup routine for automated deployment.

Here are the steps needed to integrate Outlook 98 into the modular build:

1. Create a unique directory beneath Apps called OL98 but do not copy any files into it.

2. Install the Outlook Deployment Kit on a workstation that has network connectivity to the build server.

3. Execute the ODK on the local workstation and specify all the configuration parameters (including silent installation option) for Outlook 98. During this process, you will be prompted for a directory to store the packaged Outlook 98 product. Specify the directory created in step 1. When you have specified all the configuration information, the ODK will populate the directory with all files required for the deployment.

4. Create a command script to install Outlook 98, and store it in the application scripts directory. Here is an example script:

@echo off echo Installing Outlook98 start /wait %SRCDRV%\apps\OL98\CD\EN\PACKAGES\SETUP

TIP: Outlook reboot cannot be suppressed via ODK

You can specify a command-line parameter that suppresses an automatic reboot of the operating system, but it has no effect in an ODK environment. To keep this from derailing the build, make sure Outlook 98 is the last application in a package, and reset the Reboot package header to WAIT.

Installing WinZIP

WinZIP is an example of an application that does not have an unattended installation routine, but you can still automate installation by creating a ScriptIT script.

Here are the steps needed to integrate WinZIP into the modular build:

1. Create a unique directory beneath Apps, called WinZIP and copy the entire contents of the WinZIP distribution into it.

2. Manually install WinZIP using the keyboard to interact with the dialogs. Record the window titles and keystrokes required, then use this information to create a script file and store it in the cmdFiles directory. Here is an example script file:

[SCRIPT] RUN=%SRCDRV%\apps\WinZIP\SETUP.EXE WinZip Setup+Setup will={ENTER} WinZip Setup+Thank you=!N License Agreement and Warranty Disclaimer=!Y WinZip Setup+Select=!C!N WinZip Setup+Click=!E!N WinZip Setup+Installation={ENTER}

3. Create a command script to begin the WinZIP installation, and store it in the application scripts directory. Here is an example script:

@echo off echo Installing WinZIP START /WAIT SCRIPTIT %SRCDRV%\apps\cmdFiles\WinZIP.TXT

Phase 5—Finalize/Domain Membership Walkthrough

This is the final stage of the modular build process. It joins the workstation to an existing domain, sets the local administrator password to the word SECRET, enables a legal warning message, and removes the BUILD structure on the local hard disk.

Joining the Domain

In a traditional unattended Windows NT setup, automated membership of a domain is achieved through the Windows NT answer file. Unfortunately, this requires that the workstation must be able to communicate with the domain controller for the remainder of the build process, imposing domain-dependence.

Often, this is not practical. For example, if you want to replace 2000 legacy PCs with new equipment, you can supply the hardware vendor with the unattended build, and ask that the hardware be pre-loaded before delivery. But to use the traditional mechanism (with domain dependency), the vendor must also be supplied with a valid backup domain controller (BDC).

To eliminate this problem, the modular build process does not use the Windows NT answer file to perform domain membership. Instead it uses a Resource Kit (Supplement 2) utility called NETDOM, which permits computer-account creation and domain membership from within a command-script.

Computer Account

For a workstation to join a domain, a computer account must already exist on the domain controller. There are two ways to create this account:

1. The NETDOM utility can automatically create the account prior to joining the domain, although to do this you have to encode an administrative user ID and password into the build scripts, presenting a possible security issue.

2. Before the workstation joins the domain, the administrator can manually create the accounts. This removes any security issues, and ensures that only valid computers join the domain.

Administrative Password

Prior to PC deployment, it is advisable to set a password for the local administrator account using the NET USER command. In the simple example shown in the "CHGPASS—Listing" section (page 636) the password is changed to the word SECRET.

TIP: Automated secure passwords

If a more secure (unique) password is required for each workstation, it would be easy to author a password generation program that creates a unique password based on computer name. These passwords could be cryptic and unique, and the administrator could obtain them by entering the computer name into the password generator.

Phase 5 CMD—Listing

Below is a simple phase 5 parent script. Like the previous scripts, it employs a parent/child relationship to effect the various configuration changes.

TIP: Existing network connections causes

Notice that this phase establishes no logical drive network connections. A workstation cannot join a domain until all existing network connections are terminated. If you don't establish any, you won't have to terminate any.

The following codes are spaced so that it is easier to read. Lines are broken for layout only: entries should be on a single line.

@ECHO OFF
SET netFILE=C:\NETWORK.BAT
SET cdFILE=C:\CDROM.BAT
SET oemBuildPath=C:\BUILD

IF EXIST %cdFILE% GOTO runCDFILE
IF EXIST %netFILE% GOTO runNETFILE
GOTO noConfigFile

:runCDFILE
CALL %cdFILE%
GOTO okCONTINUE

:runNETFILE
CALL %netFILE%
GOTO okCONTINUE

:okCONTINUE
ERASE /Q "%WINDIR%
\PROFILES\ALL USERS\START
MENU\PROGRAMS\STARTUP\PHASE4.CMD"

CALL %oemBuildPath%\GSCRIPTS\JOINDOM
IF %ERRORLEVEL% EQU 2453 GOTO joinFAILED
IF %ERRORLEVEL% EQU 5 GOTO noCompACCT
IF %ERRORLEVEL% NEQ 0 GOTO genericERROR
REG UPDATE "HKLM\SOFTWARE\Microsoft\Windows NT
\CurrentVersion\Winlogon\DefaultDomainName=%DOMAIN%"

CALL %oemBuildPath%\GSCRIPTS\CHGPASS
CALL %oemBuildPath%\GSCRIPTS\LEGAL

RD /S /Q %oemBuildPath%
SHUTDOWN /L /R /T:0 /Y
GOTO end

:noConfigFile

CLS
COLOR C
ECHO ***************** ERROR
_*****************************_
ECHO Cannot Find C:\CDROM.BAT OR C:\NETWORK.BAT
ECHO Ensure BOOTDISK has created files...
ECHO
_*****************************************************_
PAUSE
COLOR
GOTO END

:joinFAILED
CLS
COLOR C
ECHO****************** ERROR
_*****************************_
ECHO Cannot Find Domain %DOMAIN%
ECHO******************************************************
PAUSE
COLOR
GOTO END

:noCompACCT
CLS
COLOR C
ECHO***************** ERROR
_*****************************_
ECHO Cannot join domain - NO COMPUTER ACCOUNT
ECHO******************************************************
PAUSE
COLOR
GOTO END

:genericERROR
CLS
COLOR C
ECHO***************** ERROR
_*****************************_
ECHO Cannot join domain - Generic Error.  Consult NETDOM
tool.
ECHO******************************************************
PAUSE
COLOR
GOTO END
:END

JOINDOM—Listing

Here is a child script that executes the NETDOM utility with appropriate parameters, and uses the DOMAIN environment variable defined during phase 1 to specify the domain name.

@echo off
NETDOM /DOMAIN:%DOMAIN% MEMBER /JOINDOMAIN

CHGPASS—Listing

Here is a child script that changes the password of the local administrator to SECRET using the built-in NET USER command.

@ECHO OFF
NET USER ADMINISTRATOR SECRET

LEGAL—Listing

This script adds a legal warning message to the Windows NT logon process.

@ECHO OFF
REG UPDATE
"HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogo
n\LegalNoticeCaption=Example Legal Notice"
REG UPDATE
"HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\LegalNoticeText=Example 
Legal Notice Text"

Tips on Common Procedures

How to Determine Which Registry Keys an Application Uses

To develop an in-depth understanding of Windows NT (and application) configuration, you have to understand the significance and use of individual registry keys. Many software products do not provide detailed registry information, so you sometimes have to use tools to get this information.

Warning: Incorrect modification of the registry can lead to system instability and/or loss of application functionality. Before implementing registry changes, make sure the software vendors support the modifications you make.

During the normal execution of an application, both Windows NT and the application will make regular reference to the registry. There are two easy ways to discover which registry keys are being accessed:

Real Time Monitoring. REGMON is a real-time registry monitor available from the System Internals Web site (https://www.sysinternals.com). It displays all activity in an easy to read format, showing the process that accessed the registry, data that was read/written, and whether the access was successful. You can store captured data in text files for later analysis.

Snapshot Analysis. Windows NT has a snapshot/deployment tool called SYSDIFF (in support\deptools\i386 directory on the distribution CD), which you can use to record the various registry (and file) changes made during manual configuration of Windows NT or applications.

For example, suppose a Windows NT workstation is configured to operate at a video resolution of 640x480, and you want to determine which registry modifications are required to automate the configuration to 800x600. You can do this by using SYSDIFF this way:

1. SYSDIFF /SNAP BASE.IMG

   Causes SYSDIFF to record the state of all files and registry settings to the BASE.IMG file.

2. Change video resolution using the control panel in the usual manner.

3. C. SYSDIFF /DIFF BASE.IMG NEW.IMG

   Causes SYSDIFF to read the current state of all files and registry, compare them to the contents of BASE.IMG, and write the differences to NEW.IMG.

4. SYSDIFF /INF NEW.IMG C:\

   Causes SYSDIFF to generate a $OEM$ directory on C:\. Within this structure, the file NEW.INF contains all the registry changes made during stage 2. You can manually transpose these into the configuration script format used throughout the modular build process.

Note: It is possible that additional (non-related) registry activity will occur before the difference snapshot is taken, resulting in an .INF file that contains data that does not directly relate to the original configuration change. Prior to including all information in a configuration file, it is important to analyze and understand the impact of the registry changes you intend to make.

How to Automate SHARE Creation

You can use the NET SHARE command to create network shares within configuration scripts. The example below creates a share called EXAMPLE, which points to directory C:\EX.

NET SHARE EXAMPLE=C:\EX

How to Automate User Account Creation

You can use the NET USER command to create local user accounts within configuration scripts. The example below creates a user called tester, with comment, password expiration, home directory, and profile path configured:

NET USER tester /add /comment:"Example Account for User"
/expires:never
/homedir:\\zippy\%username%$
/profilepath:\\zippy\profile

How to Remove the Recycle Bin from the Desktop

You can do this by creating a configuration script that deletes the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion
\Explorer\Desktop\NameSpace
\{645FF040-5081-101B-9F08-00AA002F954E}"

How to Prevent Windows NT Workstation from Providing Browser Services

Use this configuration script prevents Windows NT from providing browser services to the other computers on the network:

REG UPDATE "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services
\Browser\Start=4"
REG UPDATE "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services
\Browser\Parameters\MaintainServerList=No"

How to Assign System Rights to Users During Setup

You can use the NTRIGHTS utility (in the resource kit) to assign system rights to users. The example below assigns user TESTUSER the right to shut down the system:

Ntrights –u testuser +r SeShutDownPrivilege

How to Automate Printer Creation

You can use the ZAK utility CON2PRT to create printers within a configuration script. Here is an example:

CON2PRT /CD \\PRNTSVR\HP550C

How to Prevent a Computer from Appearing on a Browse List

Use the NET CONFIG command to prevent workstations or servers appearing in browse lists. Here is an example:

NET CONFIG SERVER /HIDDEN:YES

How to Install AGP Graphics Drivers

Video adapters that use the new AGP standard require the added functionality of the hardware abstraction layers (HALs) supplied in Windows NT SP3 or later. Since SP3 is applied after the answer file has been processed, AGP video cards cannot simply be added into the answer file. There are two ways to solve this problem:

• Copy the HAL(s) from SP3 into the distribution directory, and create an answer file with the appropriate configuration data for the video card. Here is a list of HALS:

  486c_up = hal486c.dll

  astmf_mp = halast.dll

  cbus2_mp = halcbus.dll

  cbusmc_mp = halcbusm.dll

  e_isa_up = hal.dll

  mca_up = halmca.dll

  mps_up = halapic.dll

  mps_mp = halmps.dll

  mps_mca_mp = halmpsm.dll

  ncr3x_mp = halncr.dll

  oli5030_mp = haloli.dll

  syspro_mp = halsp.dll

  wyse7000_mp = halwyse7.dll

Since most new video cards are supplied with an interactive installation routine, use ScriptIT to install the drivers after SP3 has been applied. A discussion of ScriptIT begins on page 676.

How to Install Sound Cards

The answer file does not support sound card installation, but you can easily automate the process with ScriptIT. Here is a script that installs the wave drivers for the Sound Blaster AWE card.

[SCRIPT]
RUN=CONTROL.EXE
Control Panel=##MU{enter}
Multimedia Properties={RIGHT 4}!A
Add={ENTER}C:\Build\Drivers\Audio\Creative\NT40\{ENTER}
Add Unlisted or Updated Driver=#{DOWN} {ENTER}
Sound Blaster Base I/O Address={ENTER}
Sound Blaster 16 Configuration={ENTER}
System Setting Change=!D
Multimedia Properties=!+{F4}
Control Panel=!+{F4}

[ADLIB]
Driver Exists=!N
File Installation Error={ENTER}

How to Set DNS Search Order

The Windows NT answer file does not provide a mechanism to specify the search order of Domain Name System (DNS) suffix. You can automate this using a configuration script as follows:

REG UPDATE "HKLM\SYSTEM\CurrentControlSet\Services\TCPIP
\Parameters\SearchList=EXAMPLE1.COM EXAMPLE2.COM"

How to Activate a Control Panel Applet

Use the RunDLL32 command from a configuration script. This is a utility that enables the execution of exported functions in a dynamic link library. The shell32 library is used to load various control panel applets defined in the table beginning on the next page.

Note: Some applets have multiple panels, and are accessed by specifying an index value.

Control panel applets.

The following example activates the multimedia control panel and displays multimedia properties:

rundll32.exe shell32.dll,Control_RunDLL mmsys.cpl @0

How to Configure Crash Recovery

The system control panel provides various options to define what Windows NT will do in the event of a crash. The example below configures Windows NT to write the crash details to the event log and automatically reboot:

REG UPDATE
"HKLM\SYSTEM\CURRENTCONTROLSET\CONTROL\CRASHCONTROL\LOGEVENT=1"
REG UPDATE
"HKLM\SYSTEM\CURRENTCONTROLSET\CONTROL\CRASHCONTROL\AUTOREBOOT=1"

How to Remove Briefcase from the Installation

By default, the briefcase application (SYNCAPP.EXE) is installed onto each user's desktop. You can disable this by editing the TXTSETUP.SIF and LAYOUT.INF files on the distribution server, and inserting a semicolon before each line that begins with SYNCAPP.EXE.

Answer File Information

An answer file consists of section headers, parameters, and values for those parameters. Most of the section headers are predefined (although users can define some of them). You don't have to specify parameters and keys in the UNATTEND.TXT file if your installation does not require them. The file format is based on the sectioned, parameter/value schema as used in Windows .INI files.

[Unattended]

This header identifies whether an unattended installation is being performed. If it does not exist, the UNATTEND.TXT file is ignored. Parameters that can exist in this section are discussed below.

OemPreinstall
Value: Yes | No

Determines whether an OEM pre-installation is being performed. When the value is Yes, any existing subdirectories are copied. No means a regular unattended Setup is being performed and only the Inetsrv, System32 and Drvlib.nic subdirectories are copied.

NoWaitAfterTextMode
Value: 0 | 1

Determines whether the text mode portion of Setup should automatically boot into GUI mode. It is valid only when OemPreinstall = Yes. The default behavior is to halt after text mode during a pre-installation. 0 indicates that Setup should halt after text mode and 1 indicates that Setup should automatically reboot into GUI mode after text mode is complete.

NoWaitAfterGuiMode
Value: 0 | 1

Determines whether the GUI mode portion of Setup should automatically reboot to the logon screen. It is valid only when OemPreinstall = Yes. The default behavior is to halt at the end of GUI mode Setup. 0 indicates that Setup should halt after GUI mode and 1 indicates that Setup should automatically reboot after GUI mode is complete.

FileSystem
Value: ConvertNTFS | LeaveAlone

Specifies whether the primary partition should be converted to NTFS or left alone. In general, partitions greater than 512 MB should be converted to NTFS. If this value is set to "ConvertNTFS" it is done after the first reboot of an unattended setup.

ExtendOemPartition
Value: 0 | 1

Enables installation of Windows NT on a hard disk larger than 2 GB. This key causes text mode Setup to extend the partition containing the temporary Windows NT sources into any available unpartitioned space that physically follows it on the disk. The temporary install source must be a primary partition limited to 1024 cylinders. Writing beyond the 1024th cylinder causes the installation to fail. 0 implies that the partition will not be extended, and 1 indicates that it should be extended. When the value is 1, the FileSystem key must be set to ConvertNTFS. When the value is set to 1, OemPreinstall must be equal to yes.

ConfirmHardware
Value: Yes | No

Determines whether a user should manually confirm hardware and mass storage devices detected by the Setup program. Yes indicates that a user must manually confirm the hardware detected and No implies that Setup should install the detected devices. For a complete unattended installation, this key should be set to No.

NtUpgrade
Values: Yes | No | Manual | Single

Determines whether a previous version of Windows NT Workstation or Server should be upgraded. It should be set in order to perform an upgrade. Yes indicates that the detected Windows NT installation should be upgraded. If multiple installations are detected, the first installation found is upgraded. No implies that the upgrade should be aborted if a Windows NT installation is found—this is the appropriate value when OemPreinstall = Yes. Manual implies that the user must specify which previous installation should be upgraded. Single indicates that the upgrade should continue only if a single Windows NT installation is found. If multiple installations are found, the user must manually select which installation to upgrade.

Win31Upgrade
Values: Yes | No

This key determines whether previous installations of 16-bit should be upgraded to Windows NT. Yes indicates that the Windows installation should be upgraded, and No means do not upgrade the installation if found.

OverwriteOemFilesOnUpgrade
Values: Yes | No

Determines whether OEM-supplied files that have the same name as Windows NT system files should be overwritten during an unattended upgrade or not. Yes means overwrite the files and No means do not. The default behavior is to overwrite OEM-supplied files.

TargetPath
Values: * | <path name> | Manual

Determines which directory Windows NT should be installed into and implies that Setup should generate a unique directory name for the installation. This is usually WINNT.x where x is 0, 1, and so on. <path name> is user-defined installation directory. Manual indicates that Setup should prompt the user to enter the installation path. Do not use drive letters in this value.

ComputerType
Values: <hal description> [, Retail | OEM]

Indicates the type of hardware abstraction layer (HAL) to be loaded by the Setup Loader, and installed by text-mode Setup. If this key is not present, Setup attempts to detect the type of computer and install the appropriate retail HAL. Only valid when OemPreinstall = Yes. The <hal description> string identifies the HAL to be installed. It must match one of the strings in the [Computer] section of the TXTSETUP.SIF file (for a retail HAL), or the TXTSETUP.OEM file (for an OEM HAL). Retail informs Setup that the HAL to be installed is part of the Windows NT product. OEM indicates that the HAL to be loaded is OEM-supplied. If the HAL is OEM-supplied, the driver name must also be listed in the [OemBootFiles] section of the UNATTEND.TXT file.

KeyboardLayout
Value: <layout description>

Indicates the type of keyboard layout to be installed. If this key does not exist, Setup will detect and install a keyboard layout. <layout description> must match one of the right hand strings (in "") in the ["Keyboard Layout"] section of the TXTSETUP.SIF file.

[MassStorageDrivers]

This section contains a list of SCSI drivers to be loaded by the Setup Loader, and installed during text mode Setup. If this section is missing or empty, Setup attempts to detect the SCSI devices on the computer, and install the corresponding retail drivers.

<mass storage driver description>
Value: RETAIL | OEM

This string identifies the driver to be installed. It must match one of the strings defined in the right-hand side of the [SCSI] section of the TXTSETUP.SIF file (for a retail driver), or the TXTSETUP.OEM file (for an OEM driver). You can specify multiple <mass storage driver description>s. RETAIL indicates that the driver is part of the retail Windows NT product. OEM indicates that the driver is OEM-supplied. If the value is OEM, the driver must also be listed in the [OemBootFiles] section of the UNATTEND.TXT file.

[DisplayDrivers]

This section contains a list of display drivers to be loaded by the Setup Loader, and installed during text mode Setup. It is valid only when OemPreinstall = Yes. If this section is missing or empty, Setup attempts to detect the display devices on the computer, and installs the corresponding retail drivers. You can get the same functionality by using the settings in the [Display] section described on page 656.

<display driver description>
Value: RETAIL | OEM

This string identifies the driver to be installed. It must match one of the strings defined in the right-hand side of the [Display] section of the TXTSETUP.SIF file (for a retail driver), or the TXTSETUP.OEM file (for an OEM driver). You can specify multiple *<display driver description>*s. RETAIL indicates that the driver is part of the retail Windows NT product. OEM indicates that the driver is OEM-supplied.

[KeyboardDrivers]

This section contains a list of Keyboard drivers to be loaded by the Setup Loader, and installed during text mode Setup. It is valid only when OemPreinstall = Yes. If this section is missing or empty, Setup attempts to detect the keyboard devices on the computer and installs the corresponding retail drivers.

<keyboard driver description>
Value: RETAIL | OEM

This string identifies the driver to be installed. It must match one of the strings defined in the right-hand side of the [Keyboard] section in TXTSETUP.SIF file (for a retail driver) or the TXTSETUP.OEM file (for an OEM driver). You can specify multiple *<keyboard driver description>*s. RETAIL indicates that the driver is part of the retail Windows NT product. OEM indicates that the driver is OEM-supplied.

[PointingDeviceDrivers]

This section contains a list of pointing device drivers to be loaded by the Setup Loader, and installed during text-mode Setup. It is valid only when OemPreinstall = Yes. If this section is missing or empty, Setup attempts to detect the pointing devices on the computer, and installs the corresponding retail drivers.

<pointing device driver description>
Value: RETAIL | OEM

This string identifies the driver to be installed. It must match one of the strings defined in the right-hand side of the [Mouse] section of the TXTSETUP.SIF file (for a retail driver), or the TXTSETUP.OEM file (for an OEM driver). You can specify multiple *<pointing device driver description>*s. RETAIL indicates that the driver is part of the retail Windows NT product. OEM indicates that the driver is OEM-supplied.

[OEMBootFiles]

This section is used to specify OEM-supplied boot files. It is valid only if OemPreinstall = Yes and the files listed here have been placed in the $OEM$\Textmode directory of the OEM's distribution share point.

Txtsetup.oem

This file contains descriptions of all the OEM-supplied drivers listed in this section and instructions on how to install them. It must exist if this section is listed.

<hal file name>

This maps to a HAL description that has been defined by the ComputerType key in the [Unattended] section of the UNATTEND.TXT file.

<scsi driver file name>

This maps to a mass storage driver description defined in the [MassStorageDriver] section of the UNATTEND.TXT file. There can be multiple *<scsi driver file name>*s listed in the [OemBootFiles] section.

[OEM_Ads]

This section instructs Setup that the default end-user interface will be modified by the keys below.

Banner
Values: <text string>

Specifies a text string to be displayed in the upper left corner of the computer screen. The text must contain the Windows NT sub-string or it will be ignored. To specify more than one line, you can separate the lines using asterisks ( * ).

Logo
Values: <file name> [,<resource id>]

Specifies a bitmap to be displayed in the upper right corner of the screen. If this line has only one field, it is assumed to be a .BMP file located in the $OEM$ directory of the distribution share point. However, if two fields are specified, the first field is the name of a DLL and the second is a base-10 number that represents the resource ID of the bitmap in the DLL. The DLL specified should be located in the $OEM$ directory.

Background
Values: <file name> [,<resource id>]

Specifies a background bitmap to be displayed. If this line has only one field, it is assumed to be a .BMP file located in the $OEM$ directory of the distribution share point. However, if two fields are specified, the first field is the name of a DLL and the second is a base-10 number that represents the resource ID of the bitmap in the DLL. The DLL specified should be located in the $OEM$ directory.

[GuiUnattended]

OemSkipWelcome
Value: 0 | 1

Used to specify whether the introductory Welcome to Windows NT Setup page is skipped. Default behavior is to show the page.

OEMBlankAdminPassword
Value: 0 | 1

Specifies whether the user should be shown the Administrator Password Wizard page. Default behavior is to show the page. In Windows NT 4.0 you cannot automate the setup of the administrator password unless you specify it to be blank (OEMBlankAdminPassword = 1). The only way to set this is to let Windows NT prompt for it either during GUI mode or after the install is complete.

TimeZone
Value: <text string>

Determines the time zone of the computer. If the key is empty, the user is prompted to indicate a time zone.

DetachedProgram
Value: <detached program string>

Used to indicate the path of the custom program that should run concurrently with the Setup program. If the program requires any arguments, the Arguments key must be specified.

[UserData]

FullName
Value: <string>

This is used to specify the user's full name. If the key is empty or missing, the user is prompted to enter a name. This should contain the name of the person or company to which the software is registered, not the name of the user who will be using the machine or the user account.

OrgName
Value: <string>

Specifies an organization name. If this is empty, the user is prompted to enter one.

ComputerName
Value: <string>

Specifies the computer name. If this is empty or missing, the user is prompted to enter one.

ProductID
Value: <string>

Specifies the Microsoft product identification (productID) number. It is on the CD jewel case.

[Display]

This section is used to specify display settings for the particular graphics devices being installed. In order for this to work properly, the user must know what settings are valid for the graphics. If the pre-specified settings are not valid, the user is prompted to select them.

ConfigureAtLogon
Value: 0 | 1

Specifies when the graphics devices are configured: 0 indicates configure during Setup and 1 indicates configure during the first logon by the user. For a fully automated installation this key should not be used.

BitsPerPel
Value: <valid bits per pixel>

Specifies the <valid bits per pixel> for the graphics device being installed.

Xresolution
Value: <valid x resolution>

Specifies a <valid x resolution> for the graphics device being installed.

Yresolution
Value: <valid y resolution>

Specifies a <valid y resolution> for the graphics device being installed.

Vrefresh
Value: <valid refresh rate>

Specifies a <valid refresh rate> for the graphics device being installed.

AutoConfirm
Value: 0 | 1

Indicates whether the graphics device should be configured using pre-specified display settings. 0 implies do not use the pre-specified settings and 1 means use them. AutoConfirm = 1 requires that all the necessary parameters have already been specified in the UNATTEND.TXT file.

 [Display]
   BitsPerPel = 8
   XResolution = 1024
   YResolution = 768
   VRefresh = 70
   Flags = 0
   AutoConfirm = 1

[Modem]

This section header is used to identify whether a modem should be installed. It is used by Remote Access Service (RAS) to install a modem if DeviceType = Modem in the list of RAS parameters. This section cannot be empty if you want to install modems using RAS in unattended mode.

InstallModem
Value: <modem parameter section>

Defines a section where modem installation parameters are defined. The key must exist in order to install any modems.

[<modem parameter section>]

This lists the keys and values required to install a modem on a particular COM port. If this section is blank, RAS performs modem detection on its pre-configured ports and installs any modems it finds.

<COM port number>
Values: <Modem description> [, <Manufacturer>, <Provider>]

The <COM port number> key specifies the COM ports on which modems are installed. The COM port numbers must match ports configured or to be configured by the RAS installation. <Modem description> must match a modem description in a MDMXXXXX.INF file that corresponds to the modem to be installed. This string must be enclosed in quotation marks. The <Manufacturer> and <Provider> fields are optional; they identify the manufacturer and provider of a particular modem in cases where the <modem description> string is not unique to a particular manufacturer.

[Network]

This section informs Setup that networking should be installed. If empty, the user is presented with various error messages. If this section header is missing, network installation is skipped.

Attended
Value: Yes | No

Specify this key if you want the user to install networking manually during an unattended installation.

JoinWorkgroup
Value: <workgroup name>

Used to define the workgroup in which the computer will participate.

JoinDomain
Value: <domain name>

Use this to define the domain in which the computer will participate.

CreateComputerAccount
Values: <username>, <password>

Allows the machine account to be created during setup. The username and password are for a domain account that has the right to "Add Workstations To Domain." Note that for this value to work, the network card must be able to contact the domain controller. This is crucial for computers that are using only Transmission Control Protocol/Internet Protocol (TCP/IP) and when the domain controller is on a different segment. There must be a way to resolve the IP address. If the account does not have the right to add workstations to the domain or cannot contact the domain controller, setup informs you that it failed to create the account and returns to the Join Domain dialog.

DetectAdapters
Value: <detect adapters section> | ""

Used to detect network adapter cards installed on a computer. Either this key or the InstallAdapters key must exist in order to install network cards. If the value is "" the first card detected will be installed.

InstallAdapters
Value: <install adapters section>

Defines a section in which the network adapters to be installed are listed. Adapters are not detected, but if this key is present the adapters listed in the section are installed by default.

InstallProtocols
Value: <protocols section>

Defines a section in which the network protocols to be installed are listed.

InstallServices
Value: <services section>

Defines a section listing the network services to be installed. These services can be installed during unattended setup:

• NWWKSTA = Client service for NetWare

• SNMP = SNMP service

• RAS = Remote Access Service

• NETMON = Network monitor

• STCPIP = Simple TCPIP

• TCPPRINT = TCPIP Printing service

• INETSTP = Install Internet server

• SAP = SAP service

[<Detect Adapters Section>]

This section is pointed to by the DetectAdapters key described earlier.

DetectCount
Value: <number of detection attempts>

Indicates the number of detection attempts Setup should make.

LimitTo
Value: <netcard inf option>

This specifies a list of netcard information options to which the detection should be limited. To find the options for particular cards look in the [Options] section of the corresponding OEMNADXX.INF file.

[<Install Adapters Section>]

<Netcard Inf option>
Value: <netcard parameter section>

This points Setup to the section that contains descriptions for a particular network adapter card. To find the options for particular cards look in the [Options] section of the corresponding OEMNADXX.INF files.

<oem path>

This points to the location of the OEM-supplied files. If the path starts with a drive letter, then the literal path is used to find the OEM driver; if it starts with a back slash (\), then the path given is appended to the path to the installation source.

[<netcard Parameters Section>]

This section contains the parameters for a network adapter card for which the <netcard inf option> has been specified in the [<Detect Adapters Section>] or the [<Install Adapters Section>] of the UNATTEND.TXT file. You can find these values by parsing the appropriate OEMNADXX.INF or OEMSETUP.INF file for the network card. Or you can look in the registry of a Windows NT machine with the adapter already installed and functioning properly. Use REGEDT32.EXE and look in:

HKEY_LOCAL_MACHINE\system\currentcontrolset\services\<%netcardkeyname%>X

where X = 1 or ordinal of adapter installed. In this key, look at the parameter's key and note the values. Note: All values in the registry appear as hexadecimal but they are converted to decimal in your UNATTEND.TXT file. For instance, the value of IOBaseAddress =0x300 in the registry must be set to IOBaseAddress = 768 in the answer file. Example:

[EE16Params]

!AutoNetInterfaceType = 1

Transceiver = 3

!AutoNetBusNumber = 0

IoChannelReady = 2

IoBaseAddress = 768

InterruptNumber = 10

[<Protocols Section>]

This section contains a list of .INF file options for network protocols and the corresponding UNATTEND.TXT file section in which the parameters for the particular protocol are listed.

NBF
Value: <Netbeui Parameters>

Indicates that NetBEUI should be installed in unattended mode. The corresponding parameter section must exist or Setup fails.

NWLNKIPX
Value: <IPX Parameters>

Indicates that IPX should be installed in unattended mode. The corresponding parameter section must exist or Setup fails.

TC
Value: <Tcpip Parameters>

This key indicates that TCP/IP should be installed in unattended mode. The corresponding parameter section must exist or Setup fails.

DLC
Value: <DLC Parameters>

This key indicates that DLC should be installed in unattended mode. The corresponding parameter section must exist or Setup fails.

RASPPTP  (Point to Point Protocol)
Value: <Ras PTPP Parameters

Indicates that RAS Point-to-Point Protocol should be installed in unattended mode. The corresponding parameter section must exist or Setup fails.

STREAMS
Value: <Streams parameters>

Indicates that STREAMS should be installed in unattended mode. The corresponding parameter section must exist or Setup fails.

ATALK  (Apple talk protocol)
Value: <ATALK parameters>

Indicates that Apple-Talk Protocol should be installed in unattended mode. The corresponding parameter section must exist or Setup fails.

[<NetBEUI Parameters>]

This parameter is left empty because NetBEUI does not require any extra parameters to be installed.

[<IPX Parameters>]

This parameter is left empty because IPX does not require any extra parameters to be installed.

[<TCPIP Parameters>]

DHCP
Value: Yes | No

Specifies whether Dynamic Host Configuration Protocol (DHCP) should be used.

ScopeID
Value: <scope ID>

Specifies the computer's scope identifier if required on a network that uses NetBIOS over TCP/IP. If DHCP = No, the following keys must be specified:

IPAddress
Value: <IP address>

Used to specify the IP address for the computer.

Subnet
Value: <subnet address>

Specifies the subnet mask address.

Gateway
Value: <gateway address>

Identifies the default gateway address for the computer.

DNSServer
Value: <IP Addresses>

Used to specify up to 3 DNS servers.

WINSPrimary
Value: <IP Address>

Used to specify the IP address of the primary WINS server.

WINSSecondary
Value: <IP address>

Used to specify the IP address of the secondary WINS server.

DNSName
Value: <DNS domain name>

This key is used to specify the DNS domain name.

[<Services Section>]

NETMON
Value: <Netmon Parameters section>

Points to <Netmon Parameters>.

STCPIP
Value: <Simple TCPIP Parameters section>

Points to <Simple TCPIP Parameters>.

TCPPRINT
Value: <TCPIP Printing Parameters section>

Points to <TCPIP Printing Parameters>.

INETSTP
Value: <Internet server parameters section>

Points to <Internet server parameters>.

SAP
Value: <SAP Parameters section>

Points to <SAP Parameters>.

SNMP
Value: <Snmp Parameters>

Points to <Snmp Parameters>.

RAS
Value: <Ras Parameters>

Points to <Ras Parameters>.

NWWKSTA
Value: <NetWare Client Parameters>

Points to <NetWare Client Parameters>.

[Netmon Parameters Section]

No values are needed here but the section header must exist for the service to install.

[Simple TCPIP Parameters Section]

No values are needed here but the section header must exist for the service to install.

[TCPIP Printing Parameters Section]

No values are needed here but the section header must exist for the service to install.

[SAP Parameters Section]

No values are needed here but the section header must exist for the service to install.

[<NetWare Client Parameters>]

!DefaultLocation
Value: <server_location>

This identifies the default logon server for the NetWare client. For NDS logins use this syntax: !DefaultLocation = "*ABC\MARKETING.US."

!DefaultScriptOptions
Values: 0 | 1 | 3

Defines the default action to perform with scripts. 0 implies that no scripts will be run, 1 indicates that only NetWare 3.x-level scripts will be run, and 3 implies that either NetWare 3.x or NetWare 4.x-level scripts can be run.

[<Snmp Parameters>]
Accept_CommunityName
Value: <community names>

Specifies a maximum of three community names from which the computer on which the Simple Network Management Protocol (SNMP) service is running accepts traps. Separate the <community names> with commas.

Send_Authentication
Value: Yes | No

This indicates whether an authentication trap should be sent when an unauthorized community or host requests information.

Any_Host
Value: Yes | No

This specifies whether the computer on which the SNMP service is being installed should accept SNMP packets from any host.

Limit_Host
Values: <host names>

You can specify up to three <host names>, separated by commas. This key is valid when Any_Host = No.

Community_Name
Value: <community name>

Indicates the <community name> for the computer.

Traps
Values: <IP addresses> | <IPX addresses>

Use this to specify up to three IP or IPX addresses to which traps should be sent.

Contact_Name
Value: <name>

Use this to specify the computer user's name.

Location
Value: <computer location>

Use this to specify the physical location of the computer.

Service
Values: Physical, Applications, Datalink, Internet, End-to-End. 

Any combination of the five SNMP services listed here can be specified as values. They must be separated by commas.

[<RasParameters>]

PortSections
Values: <port section name>

Use this to define a port section name. You can specify multiple port section names but they must be separated by commas. See [<port section names>] definition below.

DialoutProtocols
Value: TCP/IP | IPX | NETBEUI | ALL

ALL implies all installed protocols.

DialinProtocols
Value: TCP/IP | IPX | NETBEUI | ALL

ALL implies all installed protocols.

NetBEUIClientAccess
Value: Network | ThisComputer

The default is Network.

TcpIpClientAccess
Value: Network | ThisComputer

The default is Network.

UseDHCP
Value: YES | NO

The default is Yes.

StaticAddressBegin
Value: <IP_address>

This key is required if UseDHCP = NO.

StaticAddressEnd
Value: <IP_address>

This key is required if UseDHCP = NO.

ExcludeAddress
Value: <IP_address1 - IP_address2>

Use this to exclude a range of IP addresses when you are assigning a range of IP addresses manually. It requires that StaticAddressBegin and StaticAddressEnd be specified already.

ClientCanRequestIPAddress
Value: YES | NO

The default is No.

IpxClientAccess
Value: Network | ThisComputer

The default is Network.

AutomaticNetworkNumbers
Value: YES | NO

The default is YES.

NetworkNumberFrom
Value: <IPX_net_number>

Valid numbers range from 1 to 0xFFFFFFFE. This key is required if AutomaticNetworkNumbers = NO.

AssignSameNetworkNumber
Value: YES | NO

The default is YES.

ClientsCanRequestIpxNodeNumber
Value: YES | NO

The default is NO.

[<port section name>]

PortName
Value: COM1 | COM2 | COM3-COM25

Indicates the names of the ports to be configured in a particular port section.

DeviceType
Value: Modem

This key indicates the type of device RAS should install. Currently, the only available device type is a modem.

PortUsage
Value: DialOut | DialIn | DialInOut

This defines the dialing properties for the ports being configured.

MS-DOS Utilities

SHOWMENU

This makes it easy to create interactive menus within a batch file environment. Menu items are passed to SHOWMENU as parameters and the user selects the appropriate item using the cursor. The items can be stored in an environment variable, aiding clarity of script.

Syntax:
SHOWMENU Choice1 [Choice2] [Choice3] .. [/E=VarName]

If /E switch is not specified, MS-DOS ErrorLEVEL is set to the choice sequence number. ErrorLEVEL is set to 0 if the menu terminated with escape.

If the /E is specified, an environment variable [VarName] is created and contains value of user-selected item. ErrorLEVEL is set to 27 if the menu terminated with escape. Here is an example:

SHOWMENU A B /E=choice
IF ERRORLEVEL 27 GOTO exit
IF %choice% == A GOTO getNetInfo
IF %choice% == B GOTO getCDROMInfo

GETLINE

This enables easy retrieval of keyboard input within a batch file environment. User response is stored in an environment variable, aiding clarity of script.

Syntax:
GetLine [Prompt][/L=n][/D=String][/I=String][/X=string][/U][/P][/E=VarName]
[Prompt] = Optional input prompt, displayed prior to accepting input. 

[/L] = Defines maximum length of input string.

[/D] = Provides a default response.

[/X] = Defines prohibited ASCII characters.

[/I] = Defines allowed ASCII characters.

[/P] = Private input (no echo).

If the /E switch is specified, an environment variable [VarName] is created that contains the value of user input. If Escape is pressed, the environment variable is not changed. An MS-DOS ErrorLevel of 0 on exit signifies the environment has been changed.

If the /E switch is not specified, the MS-DOS ErrorLEVEL is set to the first letter of the response, or 0 if Escape was pressed. Here is an example:

GETLINE Computer Name:  /L=10 /E=CNAME

SET_INI!

SET_INI! enables modification of text files stored in .INI format from within a batch file.

Syntax:
Set_ini! IniFileSpec [Section] "Parameter=Value"
IniFileSpec – Complete DOS path to the ".INI" file which will be modified.
[Section] – Represents the section within the ".INI" file which will be modified.
"Parameter=Value" –  Section parameter which will be modified.  

Notes:

• If no parameter value is specified (for example: Parameter=) the line is removed from file.

• [Section] is optional, enabling the utility to be used with non .INI files.

• New sections are added at the end of the .INI file.

• New parameters are added at the beginning of the section.

Here is an example:

SET_INI! %ANSFILE% [UserData] "ComputerName = %CNAME%"

SCRIPTIT

ScriptIT is a command-line utility for automating interactive software installations and system configuration tasks. It automates any traditional window or dialog interaction by sending keystrokes from a specially defined script file to the window or dialog that requires automation.

ScriptIT uses a script file to determine the sequence of keyboard events it will generate and the windows into which it will insert keystrokes. The example below illustrates a simple ScriptIT script that opens Notepad, types Hello and saves the file as C:\TEST.TXT:

[SCRIPT]
run=NOTEPAD.EXE
Untitled - Notepad=Hello
Untitled - Notepad=!FA
Save As=C:\TEST.TXT+{ENTER}

ScriptIT scripts are simple text files that must begin with a section labeled [SCRIPT]. A list of values/parameters that (with the exception of run) relate to window name/keyboard action begins on page 678.

In the above example, ScriptIT runs the notepad executable, and waits for the presence of a window called "Untitled – Notepad". When this is found, ScriptIT sends five keystrokes (which represent the word hello) to that window. It repeats this process on the next line, sending the key sequence <ALT>FA (activating the File->Save AS keyboard shortcut), then ENTER.

Once a script file has been generated, ScriptIT can process it simply by specifying it as a command-line parameter. For example: SCRIPTIT EXAMPLE.TXT.

As the example script shows, ScriptIT can simulate the use of all keys on the PC keyboard, including the non-printable characters. The tables below list various key-to-value translations.

Control and shift keys.

Key-to-value translations.

Sending Window Commands

In addition to sending keystrokes, ScriptIT has several commands that enable it to determine or change the state of a given window. For example, the following script runs Notepad, then hides the window:

[SCRIPT]
run=NOTEPAD.EXE
Untitled - Notepad=~WINHIDE

Additional ScriptITwindow-based commands.

winwaitclose

Untitled – Notepad=~winshow

You can find more detailed information on ScriptIT and a copy of the software in Microsoft TechNet (The MS ScriptIt Utility).

This is a reprint of the chapter in the book, Managing a Microsoft Windows NT Network: Notes from the Field . Copyright 1999 by Microsoft Press (ISBN: 0735606471). For more information, go to https://www.microsoft.com/mspress/.