Chapter 2 - Customizing Setup

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

You can customize the installation of Windows NT Workstation that you distribute to your users. Customization can be as simple as specifying which features in the retail product you want to use. Or, you can include applications or additional files, such as corporate-specific help files, along with the installation of Windows NT Workstation. You can even tailor the customized setup so that different computers get different configurations. And with Unattended Setup, you can supply answers to all the prompts the user would normally need to respond to during setup. Even the computername and username for each computer can be supplied via Unattended Setup.

This chapter is loosely organized according to the features you will most likely need to implement, and the order in which you would perform the tasks. It does not parallel the order of the setup process.

Overview of the Setup Process

Cc722944.spacer(en-us,TechNet.10).gif Cc722944.spacer(en-us,TechNet.10).gif

The key to deploying Windows NT Workstation is the winnt or winnt32 command. These commands use a network connection to access the installation files, which are in one central location. This central location is called the distribution sharepoint. The winnt command is used to install Windows NT Workstation on a computer currently running a 16-bit Windows operating system, such as Windows 3.1 or Windows for Workgroups 3.1, MS-DOS, or Windows 95. The winnt32 command is used to upgrade from an earlier version of Windows NT Workstation. Either of these commands can be issued directly from the keyboard, or as a line in a .bat file, or via Systems Management Server.

When you use the winnt or winnt32 command, all the files needed to complete the installation are copied over the network to a temporary directory. Then Setup continues as it would if you were performing the installation from a local drive, going through first text mode setup, and then GUI mode setup.

In text mode setup, all the files required for installation are copied from the temporary directory into the installation directory on the hard disk of the target computer. After text mode setup is complete, GUI mode begins. In GUI mode, the user is presented with a Graphical User Interface (GUI), and is prompted for information used to customize the setup. For example, the user may be given the opportunity to choose components to install. During GUI mode Setup, computer-specific information such as the computername and username are supplied.

The winnt and winnt32 Commands

Cc722944.spacer(en-us,TechNet.10).gif Cc722944.spacer(en-us,TechNet.10).gif

Before using the winnt or winnt32 command, there must be a network connection between the computer being upgraded (the destination computer) and the distribution sharepoint. If the destination computer is already using networking software, the connection can be made in the usual way. If the computer is not yet running networking software, you can use a Network Installation Startup Disk to start the computer and make the network connection. See "Network Installation Startup Disks," later in this chapter, for information on creating and using a Network Installation Startup Disk.

The winnt or winnt32 command is run from the destination computer. The command can be issued in any of the following ways:

  • Typed from the keyboard

  • Run from a batch file

  • Included in the Network Installation Startup Disk

  • Issued via Systems Management Server

The syntax of the winnt command is as follows:

winnt [/s:sourcepath] [/i:inf_file] [/t:drive_letter] [/x] [/b] [/o[x]]
[/u:answer_file] [/udf:id, [UDF_file]]

The syntax of the winnt32 command is as follows:

winnt32 [/s:sourcepath] [/i:inf_file] [/t:drive_letter] [/x] [/b]
[/o[x]] [/u:answer_file] [/udf:id, [UDF_file]]

where:

/s: sourcepath  Specifies the location of the Windows NT files. /i:inf_file Specifies the filename (no path) of the setup information file. The default is DOSNET.INF. /t:drive_letter Forces Setup to place temporary files on the specified drive. /x Prevents Setup from creating Setup boot floppies. Use this when you already have Setup boot floppies (from your administrator, for example). /b Causes the boot files to be loaded on the system's hard drive rather than on floppy disks, so that floppy disks do not need to be loaded or removed by the user. /o Specifies that Setup only create boot floppies. /ox Specifies that Setup create boot floppies for CD-ROM or floppy-based installation. /u:answer_file Specifies the location of an answer file that provides answers the user would otherwise be prompted for during Setup. /udf:id [,UDF_file] Specifies the identifier that is to be used by the Setup program to apply sections of the UDF_file in place of the same section in the answer file. If no UDF is specified, the Setup program will prompt the user to insert a disk that contains a file called $UNIQUE$.UDF. If a UDF is specified, Setup will look for the identifier in that file.

Computers running an earlier version of Windows NT Workstation can upgrade to Windows NT Workstation 4.0 using the winnt32 command. These computers do not need a Network Installation Startup Disk, because they can connect to the network using the built-in networking features of Windows NT Workstation. The options for winnt32 are the same as those for winnt.

Note If you are using winnt to install Windows NT Workstation, and you want convert to the NTFS file system, you must do the conversion as a separate step, after installing Windows NT Workstation.

After Windows NT Workstation is installed, restart the computer and use the command convert /fs:ntfs to change the file system.

Options for Customizing Setup

Cc722944.spacer(en-us,TechNet.10).gif Cc722944.spacer(en-us,TechNet.10).gif

The tools for customizing setup include the following:

  • Answer files (Unattend.txt)

  • Uniqueness Database Files (UDFs)

  • The $OEM$ directory and its subdirectories

  • The $OEM$\$$ directory, added to your distribution sharepoint and referenced from the $OEM$\Cmdlines.txt file

  • The sysdiff utility

Answer Files (Unattend.txt)

Answer files are text files that provide the answers to some or all of the prompts that the end user would otherwise need to respond to during Setup. The answer file is specified with the /u option to the winnt or winnt32 command.

The simplest way to use this feature is to specify in the answer file those features of the Windows NT Workstation retail product that you want to include in the installation. However, you can also use the answer file to display company information during GUI-mode setup, to specify a keyboard layout, to join a domain or workgroup, and to install device drivers, protocols, or network adapters.

A sample answer file, Unatttend.txt, is included on the Windows NT Workstation 4.0 product CD. Using this file as a template, you can create one or more answer files to customize your installation of Windows NT Workstation. For a general discussion of answer files see "Answer Files (Unattend.txt)," later in this chapter. See Appendix A, "Answer Files and UDFs," for a discussion of the sections and syntax you can use in your answer files.

Note The options available in Unattend.txt have changed since earlier versions of Windows NT Workstation.

Uniqueness Database Files (UDFs)

Uniqueness Database Files (UDFs) are an extension of the answer file functionality. A UDF has a structure similar to that of an answer file. However, the UDF begins with an additional section in which uniqueness IDs are specified and mapped to sections in the UDF. If a uniqueness ID is specified in the winnt or winnt32 command, any values specified in the sections associated with that uniqueness ID override the values in the sections in the answer file that have the same section names.

One UDF can have numerous uniqueness IDs, and each uniqueness ID can specify a slightly different configuration. For example, you can have a uniqueness ID for each computer in your organization, with a different computername for each uniqueness ID— all in one UDF.

The $OEM$ Directory

To install components, files, or applications that are not included with the Windows NT Workstation retail product, the required files must be added to subdirectories of the $OEM$ directory on the distribution sharepoint.

Place hardware-dependent files that are loaded during text mode setup in subdirectories of $OEM$\Textmode. Create one directory for each device.

Place files that replace or supplement the system files included with the retail product in subdirectories of $OEM$\$$.

Place files for network components, such as protocols, adapters, or network services, in subdirectories of $OEM$\Net. Create one directory for each component.

Place files for applications that support a scripted (silent) installation, and any other files you want to copy to the destination computers, in subdirectories of $OEM$\drive_letter, where drive_letter is the drive on the destination computer in which the application is to be installed. For example, if you want Microsoft Office to be installed on drive C of the destination computers, you would put the installation files in $OEM$\C\MSOffice.

To include in your installation of Windows NT Workstation applications that must be installed interactively, use sysdiff.

About Sysdiff

To pre-install applications that do not support a scripted installation, you must use sysdiff. You can also use sysdiff to install other applications.

To use sysdiff, first create a snapshot of a reference system. Then install the applications you want to distribute. After you've installed the applications, create a difference file*.* The information in the difference file includes all the binary files for the applications, as well as the initialization file settings and registry settings for the applications.

A command in the $OEM$\Cmdlines.txt file is used to apply the difference file to new installations of Windows NT Workstation. Or, the difference file can be applied to a computer that is already running Windows NT Workstation 4.0 by issuing the same command from the command line.

Because the difference file includes all the files and all the initialization and registry settings for the applications, it can be a very large package, depending on the number and complexity of the applications you have added. Applying such a large package can increase the time required for setup considerably. As an alternative, you can create an information file (INF) from the difference file, which contains only registry and initialization file directives. The command that creates the INF also creates a directory tree within the $OEM$ directory structure, that contains all the files contained in the difference file package. These files are then copied along with other files required by setup during the early phases of setup, and are in place when the INF is invoked from the $OEM$\Cmdlines.txt file.

Adding Applications

Cc722944.spacer(en-us,TechNet.10).gif Cc722944.spacer(en-us,TechNet.10).gif

You can install any number of applications along with Windows NT Workstation, using the procedure that follows.

To use unattended setup to distribute applications with the Windows NT Workstation installation

  1. If any of the applications you want to preinstall require an interactive installation, prepare the snapshot and difference files, and optionally an INF file generated from the difference file, as described under "The Sysdiff Utility," later in this chapter. Install the applications after creating the snapshot file and before creating the difference file. Place the difference file (or, if you prefer, the INF file and directory structure generated from the difference file) on the distribution sharepoint.

  2. For each application that has not been installed in step 1, create a subdirectory of the $OEM$\$$ directory on your distribution sharepoint. Copy all the installation files (including any directory structure) to this directory you have created.

  3. Edit Unattend.txt, adding the line OemPreinstall = Yes to the [Unattended] section. The edited file is the answer file.

  4. Add the installation commands to the $OEM$\cmdlines.txt file.

  5. If you created a difference file as described in step one, add the sysdiff /apply command to the $OEM$\Cmdlines.txt file. This command is described under "The Sysdiff Utility," later in this chapter. Or, if you generated an INF from the difference file, add the command to apply the INF to the $OEM$\Cmdlines.txt file.

  6. Optionally, create a UDF to further customize the sections of the answer file for individuals or groups. The use and format of the UDF is discussed in the section, "Tailoring the Installation with Uniqueness Database Files" later in this chapter.

  7. With all the required files in place on the distribution share, use the winnt or winnt32 command at the destination computer to perform the installation. The winnt and winnt32 commands are discussed earlier in this chapter, under "The winnt and winnt32 Commands."

Using Sysdiff

Cc722944.spacer(en-us,TechNet.10).gif Cc722944.spacer(en-us,TechNet.10).gif

Sysdiff is used in several steps.

  1. First, run sysdiff /snap to take a snapshot of the Windows NT retail version of the system after it has been installed on a reference computer. The reference computer needs to be of the same general hardware type (x86, MIPS, Alpha, or PowerPC) as the destination computers. The %systemroot% (for example, C:\Winnt) must be the same on the reference and destination computers.

  2. Then, after the system has been customized by installing applications, run sysdiff /diff again to create the difference file.

  3. Finally, run sysdiff /apply as part of an Unattended Setup to apply the difference file to a new installation. The sysdiff /apply command can also be run at any time after installation is complete.

    Alternately, run sysdiff /inf to create an INF and add the files included in the difference file to the $OEM$ directory tree. Then invoke the INF with a command in the $OEM$\Cmdlines.txt file, or at any time after installation is complete.

  4. Optionally, you can run sysdiff /dump to dump the difference file information in a form that you can read. Use the sysdiff /dump command to review the contents of the difference file.

If you want to distribute computers or hard disks that are ready for GUI-mode setup, use the winnt /u or winnt32 /u command to install your customized version of Windows NT Workstation, including the difference file — but stop the process after text mode Setup is complete by turning off the computer. Then duplicate the hard disk, using the xcopy command. The duplicated disks will include all the information copied during text mode, including the contents of the $OEM$ directory and its subdirectories. These directories will be deleted, along with other temporary directories used by Setup, after GUI mode setup is completed. GUI mode setup proceeds the first time the computer is turned on.

The sysdiff process is shown in the following illustrations (Figures 2.1 and 2.2).

Cc722944.xwr_b01(en-us,TechNet.10).gif

Figure 2.1 Pre-installation using sysdiff 

Cc722944.xwr_b02(en-us,TechNet.10).gif

Figure 2.2 Creating and applying a sysdiff package 

To create the snapshot file

  1. Install the retail version of Windows NT Workstation or Windows NT Server on a computer of the same general type (x86, Alpha, MIPS, or PowerPC) as the destination computers.

  2. At the command prompt, type the following command: 

    sysdiff /snap [/log:log_file] snapshot_file
    
where: 

log_file is the name of an optional log file created by sysdiff. snapshot_file is the name of the file containing the snapshot of the system. Specify any valid Win32-based filename.

To create the difference file

  1. After the snapshot file has been created, install the applications that you want to include in the distributed version of the system.

  2. At the command prompt, type the following command: 

    sysdiff /diff [/c:title] [/log:log_file] snapshot_file difference_file
    
where: 

/c: title  specifies a title for the difference package log_file is the name of an optional log file created by sysdiff. snapshot_file is the name of the file containing the snapshot of the system. This file must be created from the same installation as you modified in step one. If you use a file created on another computer or from another installation, sysdiff will fail. difference_file is the name of the file containing the differences between the system as it existed when the snapshot file was created and the system as it currently exists. Specify any valid Win32®-based filename.

To apply the difference file

  1. Place the difference file in a subdirectory of the $OEM$\$$ directory.

  2. Add the following command to the $OEM$\Cmdlines.txt file: 

    sysdiff /apply /m [/log:log_file ] difference_file
    
where: 

/m causes the file changes in the per-user profile structure to be mapped to the Default User profile structure, rather than to the profile structure for the user logged on when the difference file was created. For example, if you were logged on as Administrator when you installed the applications to be included in the difference file, then the .lnk files and other user profile files would be created in the %WinDir%\Profiles\Administrator directory (where %WinDir%\ is the value of the %USERPROFILE% environment variable). But this directory does not yet exist when the files are copied during GUI-mode setup. For a preinstallation, these files should be placed into %WinDir%\Profiles\Default User instead of %WinDir%\Profiles\Administrator. By using the /m switch to place the files in the Default User profile structure, you ensure that the applications are available to all users when they first log in. log_file is the name of a log file to which sysdiff writes information describing its actions. This parameter is optional. difference_file specifies a file generated by an earlier invocation of sysdiff /diff. The %SystemRoot% must be the same as it was on the system that was used to generate the original difference_file. For example, if a difference file was generated on a Windows NT Workstation installation in C:\Winnt, then that difference file can be applied on other computers only if those computers are running Windows NT installed in C:\Winnt.

Note You can also run the sysdiff /apply command from the command line. For example, you can use this command to apply a difference file that contains applications to an existing installation of Windows NT Workstation 4.0.

To create an INF

Run the following command:

SYSDIFF /inf /m [/u] sysdiff_file oem_root 

where:/m causes the file changes in the per-user profile structure to be mapped to the Default User profile structure, rather than to the profile structure for the user logged on when the difference file was created. For example, if you were logged on as Administrator when you installed the applications to be included in the difference file, then the .lnk files and other user profile files would be created in the %WinDir%\Profiles\Administrator directory (where %WinDir%\ is the value of the %USERPROFILE% environment variable). But this directory does not yet exist when the files are copied during GUI-mode setup. For a preinstallation, these files should be placed into %WinDir%\Profiles\Default User instead of %WinDir%\Profiles\Administrator. By using the /m switch to place the files in the Default User profile structure, you ensure that the applications are available to all users when they first log in. /u specifies that the INF file be generated as a Unicode text file. By default, the file is generated using the system ANSI codepage. sysdiff_file is a Win32 path to a file that was created by sysdiff's difference mode. oem_root is the Win32 path of a directory. The $OEM$ structure will be created in this directory, and the INF will be placed there with the name Instapp.inf.

The output of this command is a file with the name dif_file.inf, where dif_file is the name of the difference file (without the three character filename extension). If the difference filename is more than eight characters long, it will be truncated to eight characters. For example, if sysdiff_file was named Custom.dif, the INF created by the sysdiff /inf command will be Custom.inf. If sysdiff_file was named Marketing.dif, the INF created by the sysdiff /inf command will be Custom_m.inf.

Because the INF file is copied during text mode Setup, it should be placed in the $OEM$\Textmode directory and listed in the Txtsetup.oem file in that directory. On x86 machines, Txtsetup.oem and all files listed in it must also be listed in the [OEMBootFiles] section of the answer file.

To invoke the INF

Add a line to $OEM$\Cmdlines.txt to invoke the INF you created from the sysdff difference file. The command is of the same form as you would use to invoke any Windows 95-style INF. The format is as follows:

"RUNDLL32 syssetup,SetupInfObjectInstallAction section 128 inf"

where:

Section specifies the name of the section in the INF file. Inf specifies the name of the INF file. This should be specified as a relative path to avoid invoking Setup's default INF rules, which look for an unqualified filename in the system inf directory instead of the current directory. For example, specify ..\newtools.inf, not just newtools.inf.

The command is always enclosed in double quotation marks.

To dump the contents of a difference file

  • Use the command, 
sysdiff /dump difference_file dump_file

This creates a text file with the name specified in the dump_file parameter that contains information regarding the contents of the difference file.

Sysdiff.inf

When sysdiff is run, it looks for a file called Sysdiff.inf in the directory containing Sysdiff.exe. This file contains information used by sysdiff to exclude certain files and registry entries from snapshots or difference files. The Sysdiff.inf file can be customized, but you should use at least a basic Sysdiff.inf when performing the sysdiff /snap and sysdiff /diff commands. Otherwise, sysdiff will attempt to include such files as Pagefile.sys, which will almost certainly cause sysdiff to fail.

Example Sysdiff.inf File

The following is an example of a typical Sysdiff.inf file. It is heavily commented to serve as a guide if you choose to customize the file.

[Version]
;
; This section is required, as it identifies the file as
; a Win4-style INF. Just leave this section as-is.
;
Signature = $chicago$

;
; General notes for file/dir exclusion sections:
;
; *: refers to all drives.
; ?: refers to the drive with the system on it.
; :: is substituted with %systemroot%
;
; Lines that are not in valid format (such as those that
; don't start with *:\, ?:\, ::, or <x>:\) are ignored.
;

[ExcludeDrives]
;
; By default, all valid local hard drives are scanned from the root during
; snapshots and diffs. This section can be used to exclude entire drives.
; The first character on each line is the drive letter of a hard drive to exclude.
;

[ExcludeDirectoryTrees]
;
; By default, all directories on a drive are scanned during snapshots/diffs.
; This section allows entire directory trees to be excluded.
; Each line is a fully-qualified path of a tree to be excluded -- the directory
; and all of its subtrees are excluded from the snapshot or diff.
;
*:\recycled
*:\recycler

[ExcludeSingleDirectories]
;
; Each line is a fully-qualified path of a directory to be
; excluded. The directory's subdirs are NOT excluded.
;
::\system32\config

[ExcludeFiles]
;
; By default, all files in all directories are included in snapshots/diffs.
; This section allows exclusion of individual files.
; Each line is a fully-qualified path of a file to be excluded.
; If it does not start with x:\ then we assume it's a filename part
; for a file to be excluded whereever it is found.
;
*:\pagefile.sys
ntuser.dat
ntuser.dat.log

[IncludeFilesInDir]
;
; Each line in here is a fully qualified path of a directory
; whose files are all to be included in a diff (marked as
; added/changed). Use this if you want to include files in the diff
; that might not have actually been changed.
;

[ExcludeRegistryTrees]
;
; By default, all registry keys in HKEY_LOCAL_MACHINE \System,
; HKEY_LOCAL_MACHINE \Software, and HKEY_CURRENT_USER are scanned during
; snapshots and diffs. This section allows exclusion of entire registry subkeys.
; Each line indicates a registry key and subkeys to be excluded.
; The first field is one of HKLM or HKCU
; The second field is the subkey, which must NOT start with a \.
;
HKLM,SYSTEM\ControlSet001
HKLM,SYSTEM\ControlSet002
HKLM,SYSTEM\ControlSet003
HKLM,SYSTEM\ControlSet004
HKLM,SYSTEM\ControlSet005
HKLM,SYSTEM\ControlSet006
HKLM,SYSTEM\ControlSet007
HKLM,SYSTEM\ControlSet008
HKLM,SYSTEM\ControlSet009

[ExcludeRegistryKeys]
;
; Each line indicates a single registry key to be excluded.
; Subkeys of this key are not excluded.
;
; The first field is one of HKLM or HKCU
; The second field is the subkey, which must NOT start with a \.
;
HKCU,Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU

[ExcludeRegistryValues]
;
; Each line indicates a registry value entry to be excluded.
;
; The first field is one of HKLM or HKCU.
; The second field is the subkey, which must NOT start with \.
; The third field is the value entry name.
;

Answer Files (Unattend.txt)

Cc722944.spacer(en-us,TechNet.10).gif Cc722944.spacer(en-us,TechNet.10).gif

You can make unattended answer files for the various setup configurations used in your organization, and then customize them with UDFs as needed. For example, you can make one answer file for each geographic location, or for each division. To tailor the information to individual users, create a UDF with a section for each user or computer that specifies the user name and computer name. Each user can then receive a tailored installation by specifying both the answer file and the UDF in the winnt or winnt32 command.

Answer files and UDFs are text files with specific section names and keys. For a description of these sections and keys, and the customizations you can perform through these files, see Appendix A, "Answer Files and UDFs."

If you are using Microsoft Systems Management Server (SMS) to manage computer resources in your organization, you can use package definition files (PDFs) to install or upgrade Windows NT. See the Microsoft Systems Management Server documentation for information on using PDFs to install operating systems.

Creating an Unattended Answer File

You can create one or more unattended answer files for your organization by editing a copy of the Unattend.txt included with the Windows NT Workstation 4.0 Resource Kit. Use any text editor to modify the file, and save the modified copy as a text file. The modified Unattend.txt can be given any legal filename.

The options available in answer files and UDFs are documented Appendix A, "Answer Files and UDFs."

Using Uniqueness Database Files

Cc722944.spacer(en-us,TechNet.10).gif Cc722944.spacer(en-us,TechNet.10).gif

When you are deploying a complete, unattended installation of Windows NT Workstation to numerous computers, some of the information you need to supply via answer files (such as the computername) must be unique to each computer. With Windows NT Workstation 4.0, you can use a single answer file for the information that applies to all users, and one or more uniqueness database files (UDFs) to supply information that is specific to a single computer or a small group of computers.

Uniqueness database files (UDFs) are used to provide replacements for sections of the answer file, or supply additional sections. The replacement sections are specified in a text file similar to the answer file. This file is indexed via strings called uniqueness IDs.

The uniqueness database file is used to specify a set of sections that should be merged into the answer file at the start of GUI Setup. This merging takes place before any affected components actually read the internal representation of the answer file. Thus this entire mechanism is totally transparent.

For a discussion of the sections and keys used in answer files and UDFs, see Appendix A, "Answer Files and UDFs."

Creating the UDF

The first section of the UDF is the [UniqueIds] section. This section lists all uniqueness ids that are supported by this database. The left hand side is a uniqueness ID. The uniqueness ID can be any string but must not contain the star (*), space ( ), comma (,), or equals (=) character. The right hand side is a list of sections, each of which should match the name of a section in the answer file. The format is as follows:

[UniqueIds]
id1 = section1,section2
id2 = section1,section2
id3 = section1,section3,section4

For example, if you were using computernames for the uniqueness IDs, this section might look like this:

[UniqueIds]
janeayer = UserData,Unattended
emilybr = UserData,Unattended
jconrad = UserData,KeyboardDrivers, PointingDeviceDrivers

Following the [UniqueIds] section are the sections referenced in [UniqueIds]. These section names can take either of two forms: They can be exactly like the section name in the answer file (for example, [Unattended]); or, the section name can be preceded with the uniqueness ID and a colon (for example, [janeayer:UserData]). This allows you to create specialized replacement sections for each computer name.

If both a general section (such as [Unattended]) and an ID-specific section (such as [jconrad:Unattended]) are available, Setup will use the section for the uniqueness ID specified in the winnt or winnt32 command line.

The sections in the UDF can contain any keys and values that the same-named sections could contain in the answer file. During setup, each key specified in a referenced section overrides the value for the same key in the answer file. Values are substituted as follows.

  • If a key is specified in the answer file but not in the UDF section referenced by the uniqueness ID, the value specified in the answer file is used.

  • If a key is specified in the UDF section referenced by the uniqueness ID, the value specified in the UDF is used.

  • If a key is specified in the answer file, and it appears in the UDF section referenced by the uniqueness ID with no value to the right of the equals sign, the default value will be used. This is equivalent to commenting out the key in the answer file.

  • If a key is specified in the UDF, but the value is left blank, no value will be used for that key. This might result in the user being prompted for the information.

  • If a section or key is used in the UDF, but there is no section by that name in the answer file, the section will be created and used by Setup.

  • If a section is referenced in the [UniqueIds] section but does not exist, the user will be prompted to insert a floppy with a valid uniqueness database on it.

Specifying a UDF During Installation

To specify a uniqueness ID during setup, the user must run the winnt or winnt32 command with the following parameter:

/UDF:ID[,database_filename]

where:

ID  is the uniqueness ID to use while installing Windows NT Workstation on this computer. database_filename is the filename, including the full path, of the UDF.

If both the uniqueness ID and the filename of the UDF are specified, the UDF is copied to the local drive during text-mode Setup, and is used during GUI Setup without user intervention. The UDF can have any legal filename.

If only the uniqueness ID is specified on the winnt or winnt32 command line, Setup requires a floppy disk with a UDF file named $Unique$.udf. This disk must be prepared by the administrator and made available to the user in advance. The user is prompted for this disk during GUI mode setup.

In either case, if the supplied UDF is corrupt or if Setup cannot locate the specified uniqueness ID in it, the user is prompted either to insert a floppy with the fixed UDF, or Cancel. If the user chooses Cancel, the values in the answer file will be used. These values might not be appropriate for the computer.

The $OEM$ Directory and its Subdirectories

Cc722944.spacer(en-us,TechNet.10).gif Cc722944.spacer(en-us,TechNet.10).gif

To install components, files, or applications that are not included with the Windows NT Workstation retail product, the required files must be added to subdirectories of the $OEM$ directory on the distribution sharepoint.

The $OEM$ directory includes the following subdirectories:

  • $OEM$

  • $OEM$\Textmode

  • $OEM$\$$

  • $OEM$\NET

  • $OEM$\drive_letter 

  • $OEM$\drive_letter 

The following sections discuss these directories and their uses.

Cc722944.xwr_b03(en-us,TechNet.10).gif 

The $OEM$\Cmdlines.txt File

To install files located in the subdirectories of $OEM$, list the installation commands in a text file named Cmdlines.txt. Place the Cmdlines.txt file in the $OEM$ directory of the distribution sharepoint. The syntax is as follows:

[Commands]
"command 1"
"command 2"
"command 3"
.
.
.

Enter the entire command line, in double quotation marks. The following is an example of a Cmdlines.txt file with a single command:

[Commands]
"Rundll32 setupapi,InstallHinfSection sectionname 128 ..\newtool.inf"

The $OEM$\Textmode Directory

The $OEM$\Textmode directory contains all of the files that the Setup Loader needs to load, and that Text Mode Setup needs to copy to the target computer, so that the system can boot into GUI setup.

If you are installing SCSI, keyboard, video, or pointer device drivers, or HALs, that are not included with the Windows NT Workstation 4.0 retail version, this directory should also contain a standard Txtsetup.oem file. This file contains pointers to all the files required by the Setup Loader and Text Mode Setup to load and install these components. On x86 machines, Txtsetup.oem and all files listed in it (HALs and drivers), must also be listed in the [OEMBootFiles] section of the answer file.

The $OEM$\$$ Directory

This directory contains system files (either new files or replacements to files included in the retail product) that need to be copied to the various subdirectories in the Windows NT system directory. Maintain the directory structure used in the retail product. In each subdirectory, place the files that need to be copied to the corresponding system directory on the destination computer. If some of the files use long filenames, add the file $OEM$\$$\$$Rename.txt. This file lists all files that have long names, and their corresponding short names.

The $OEM$\Net Directory

This directory contains only subdirectories. In each subdirectory place the files for a particular network component, such as network cards, network services, and network protocols. Files in this directory will be used by the network setup module.

The $OEM$\drive_letter Directories

The $OEM$\drive_letter directories are used to hold files that are to be copied by the Setup program to corresponding drives on the destination computers. For example, files in the $OEM$\C directory will be copied to drive C on the destination computer during text mode setup.

Place files for applications that you want to install along with Windows NT Workstation in subdirectories of the $OEM$\drive_letter directories on the distribution sharepoint. The files in these subdirectories must have short filenames. To rename them with long filenames after they have been copied to the destination computer, list them in a file named $$rename.txt, in the same directory.

Applications included in the $OEM$\drive_letter directories must support a scripted (silent) installation; to include applications that require interactive installation, use the sysdiff utility.

Setup uses commands specified in the $OEM$\Cmdlines.txt file to install applications or copy files that are available in subdirectories of $OEM$\drive_letter on the distribution sharepoint. You can use these commands to invoke a Win95-style INF file, run the sysdiff command, or perform other actions.

For example, to install MS Office on the C drive, in the \MSOffice directory, place the files in $OEM$\C\MSOffice. Then specify the command to install the application in the $OEM$\Cmdlines.txt file.

You can also place files that you only want copied (but not "installed") in subdirectories of $OEM$\drive_letter. For example, if you have written help files that cover policies and procedures used in your organization, you can place them in a subdirectory of $OEM$\C. Then use a command in the $OEM$\Cmdlines.txt file to copy them to the destination computers.

The $$Rename.txt Files

To map short filenames used in subdirectories of $OEM$ to long filenames that should be assigned to those files after they are copied to the destination computers, list them in a $$Rename.txt file. Each subdirectory of $OEM$ requires its own $$Rename.txt file, if the files in that directory need to be assigned long filenames on the destination computer. For example, if some of the system files in $OEM$\$$ use long filenames, they must be mapped in the file $OEM$\$$\$$Rename.txt. If some of the application files in $OEM$\C use long filenames, they must be mapped in the file $OEM$\C\$$Rename.txt. The format for the $$Rename.txt file is as follows:

[section name]
short name 1 = "long name 1"
short name 2 = "long name 2"

where:

section name  is the path to the directory that contains the files. To indicate that the section contains the names of files or subdirectories that are on the root of the drive, use a backslash as the section name, as follows: [\]

short name  is the name of the file or subdirectory in this directory, to be renamed. "long name" is the new name of the file or subdirectory. This name must be in double quotes.

Network Installation Startup Disks

Cc722944.spacer(en-us,TechNet.10).gif Cc722944.spacer(en-us,TechNet.10).gif

To deploy Windows NT Workstation to computers that are not currently running networking software, you need to provide some way for them to connect to the distribution sharepoint and begin the installation process. This is done with a Network Installation Startup Disk.

A Network Installation Startup Disk is a bootable MS-DOS system disk containing just enough network client software to connect to the distribution server. You can then use the winnt command to install Windows NT Workstation over the network. You can include the winnt command line in the Autoexec.bat file on the disk, so that installation begins automatically when the computer is started with the Network Installation Startup Disk in the drive.

This disk can be used to do additional tasks, by adding lines to the Autoexec.bat file on the disk. For example, a series of Network Installation Startup Disks can be produced for an entire division or organization, with each disk specifying a different uniqueness ID in a common UDF. The end users can simply insert the disk into their primary floppy drive , turn on the computer, and walk away, returning to a completed custom installation of Windows NT Workstation.

Creating a Network Installation Startup Disk

Before you create a Network Installation Startup Disk, you need to determine the following:

  • The name to be assigned to the computer.

  • The username to be used. The username identifies a member of the workgroup or domain. Choose a unique name within the workgroup or domain.

  • The name of the user's workgroup and/or domain.

  • The manufacturer and model of the network adapter.

  • The network protocol used on this network.

To create a Network Installation Startup Disk
  1. Make sure that the disk has been formatted using the MS-DOS operating system. Use a high-density system disk that fits the destination computer's primary floppy drive. (On most computers this will be drive A. If your system is configured differently, substitute the drive name which acts as your primary floppy drive.) Insert this disk in drive A of a computer running the MS-DOS operating system.

  2. At the MS-DOS command prompt, type sys a: and then press ENTER to copy the hidden MS-DOS system files (Io.sys and Msdos.sys) and the MS-DOS command interpreter (Command.com) to the network installation startup disk.

  3. On the Windows NT Server computer, double-click on the Network Client Administrator Utility in the Network Administration program group. Follow the directions displayed on the screen to create a Network Installation Startup Disk.

  4. When prompted to insert a disk, insert the disk created in step 2 in the floppy drive.

  5. Continue following the directions displayed on the screen. You now have a Network Installation Startup Disk.

  6. The Network Client Administrator utility configures the Network Installation Startup Disk with default settings for the network adapter. Verify that the default settings are correct for your network adapter and modify them if necessary. (The settings are in the A:\Net\protocol.ini file.)

Using the Network Installation Startup Disk

Once the answer files, along with any UDFs or other customization files, are available on the distribution sharepoint, your technicians or end users can use the Network Installation Startup Disk to install Windows NT Workstation over the network.

To use the Network Installation Startup Disk
  1. Insert the Network Installation Startup Disk in drive A of the destination computer.

  2. Turn on the destination computer. The MS-DOS Network Client installation program is run automatically if the Network Installation Startup Disk is in drive A.

  3. When prompted for a username and password, supply the username and password for an account with permission to connect to the directory on the Windows NT Server computer where Windows NT Workstation Setup files are stored. When the computer displays a message about creating a password-list file, type n and then press ENTER.

  4. The client computer must now make a connection to the shared directory on the Windows NT Server computer. To do so, type the following at the command prompt: 

    net use x: \\corpnet\ver4.0
    

cd x:

where:

*x*:

is the letter assigned to the network drive, \\\\*corpnet* is the name of the distribution server, and \\*ver4.0* is the shared directory containing the Windows NT installation files.
  1. Use the command winnt /u:answer_file to run the setup program.

For more information, see the guidelines for Computers Running MS-DOS Network Client in Chapter 4, "Deployment on Existing Client-Server Networks."

Troubleshooting

If the computer displays an error message saying that "the specified shared directory cannot be found," make sure that the directory containing the Windows NT installation files is indeed shared on the Windows NT Server computer.

The NetBEUI protocol can only be used in a LAN or a setup staging area because NetBEUI does not support traffic across routers. Both IPX and TCP/IP can be used in a WAN with Setup Manager. However, not all companies route IPX, so you may need to create boot floppies with TCP/IP for use in a WAN environment.

If the computer displays an error message about lack of memory, modify the Config.sys file on the network installation startup disk to use extended memory. For example, EMM386.exe and Himem.sys provide extended memory for MS-DOS 5.0 and later. If you do not have extended memory, use the NetBEUI or IPX protocols instead of TCP/IP.

Creating .inf Files

Cc722944.spacer(en-us,TechNet.10).gif Cc722944.spacer(en-us,TechNet.10).gif

Device information (INF) files provide information used by the Windows NT Workstation Setup program to install software that supports a given hardware device. INF files may also be created to permit scripted installations of applications.

Some Windows NT Workstation 4.0 .inf files use the same format as Windows 95 .inf files. Other .inf files use the format used in earlier versions of Windows NT Workstation. See the Windows 95 Resource Kit for a discussion of Windows 95-style INFs.

Using Windows 95-style .inf Files

You can use a Windows 95-style .inf file to install applications and other components into Windows NT. For complete details about the syntax and use of statements in Windows 95 INF files, see the Win32 Software Development Kit for Windows 95 and Windows NT.

The command line to invoke a Win95-style INF in Windows NT 4.0 is:

RUNDLL32 syssetup,SetupInfObjectInstallAction section 128 inf

where:

section  specifies the name of the section in the INF. inf specifies the name of the INF file. This should be specified as a relative path to avoid invoking Setup's default INF rules, which look for an unqualified filename in the system inf directory instead of the current directory. For example, specify ..\newtools.inf, not just newtools.inf.

For example if you want to install MyGame application into Windows NT, create a Mygame.inf file, such as the following, and place it in the $OEM$ directory.

This inf is a sample win95 style INF
mygame.inf
installs a game program into Windows NT

[version]
signature="$Windows NT$"
ClassGUID={00000000-0000-0000-0000-000000000000}

Destination Directories for CopyFiles Sections

[DestinationDirs]
BaseCopyProgramFiles = 24,%INSTALL_DIR%
MygameDeleteFiles = 24,%INSTALL_DIR%
MygameCopyFilesHelp = 18 LDID_HELP

[BaseWinOptions]
BaseSection

[Optional Components]
Mygame

[BaseSection]
AddReg = BaseAddReg

[Mygame]
OptionDesc = %MYGAME_Desc%
Tip = %MYGAME_TIP%
IconIndex = 64 Windows mini-icon for dialogs
Parent = Games
InstallType = 0 Manual only.
CopyFiles = BaseCopyProgramFiles, MygameCopyFilesHelp
AddReg = MYGAME.AddReg
UpdateInis = MYGAME.Inis
Uninstall = MYGAME.Remove
Upgrade = MYGAME.Upgrade
Detect = %24%\%INSTALL_DIR%\mygame.exe

[MYGAME.Remove]
AddReg = MYGAME.DelReg
DelReg = MYGAME.DelPath
DelFiles = BaseCopyProgramFiles, MygameCopyFilesHelp, MygameDeleteFiles
UpdateInis = MYGAME.Rem.Inis
Reboot=0

[MYGAME.Upgrade]
CopyFiles = BaseCopyProgramFiles, MygameCopyFilesHelp
DelFiles = MygameDeleteFiles
AddReg = MYGAME.AddReg

[MYGAME.Inis]
setup.ini, progman.groups,, "group15=%GAMES_DESC%" creates folder
setup.ini, group15,, """%MYGAME_Desc%"",""""""%24%\%INSTALL_DIR%\mygame.exe"""""",,,,""%24%\%
INSTALL_DIR%"""

[MYGAME.Rem.Inis]
setup.ini, progman.groups,, "group15=%GAMES_DESC%"
folder
setup.ini, group15,, """%MYGAME_Desc%"""
deletes link

[MYGAME.AddReg]
HKLM,%KEY_OPTIONAL%\Mygame,Installed,,"1"
HKLM,"%KEY_APP_PATH%\mygame.exe",,,"%24%\%INSTALL_DIR%\mygame.exe"

[MYGAME.DelPath]
HKLM,"%KEY_APP_PATH%\mygame.exe"

[MYGAME.DelReg]
HKLM,%KEY_OPTIONAL%\Mygame,Installed,,"0"

[BaseAddReg]
Create entries for Maint Mode Setup, set all initially to uninstalled:
HKLM,%KEY_OPTIONAL%,"Mygame",,"Mygame"
HKLM,%KEY_OPTIONAL%\Mygame,INF,,"mygame.inf"
HKLM,%KEY_OPTIONAL%\Mygame,Section,,"Mygame"
HKLM,%KEY_OPTIONAL%\Mygame,Installed,,"0"

[BaseCopyProgramFiles]
FONT.DAT
MYGAME.DAT
MYGAME.EXE
MYGAME.MID
MYGAME2.MID
SOUND1.WAV
SOUND2.WAV
SOUND3.WAV

table.bmp
wavemix.inf

[MygameDeleteFiles]
mygame.cnt
mygame.hlp
mygame.inf

[MygameCopyFilesHelp]
mygame.cnt
mygame.hlp

[Strings]
KEY_APP_PATH = "SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths"
KEY_OPTIONAL = "SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\OptionalComponents"
GAMES_DESC = "Accessories\Games"
MYGAME_Desc = "Mygame"
MYGAME_TIP = "Company X 3-D mygame game"
INSTALL_DIR = "Program Files\Windows NT\Mygame"

To install MyGame, you would include the following command line in the $OEM$\Cmdlines.txt file on your distribution sharepoint.

"RUNDLL32 syssetup,SetupInfObjectInstallAction Version 128 ..\mygame.inf"

Note All the files needed for this application should be placed in the distribution share point.

Special Issues: Dual Boot Computers

Cc722944.spacer(en-us,TechNet.10).gif Cc722944.spacer(en-us,TechNet.10).gif

In the deployment lab, you might want to set up some computers to run either Windows NT Workstation 3.51 or Windows NT Workstation 4.0, with the choice of operating system to be made during system startup. This is referred to as dual booting. The following considerations apply in this case:

  • If the configurations using Windows NT Workstation 3.51 and Windows NT Workstation 4.0 are members of the same domain, they must have different computernames.

  • The installation of Windows NT Workstation 4.0 must be done interactively, without using the winnt /u or winnt32 command.

Cc722944.spacer(en-us,TechNet.10).gif