Unattended installation is a feature that may seem of little use to small IT shops with only a few NT boxes. But in reality, it’s most useful in smaller businesses, where manpower is limited and an admin’s time is valuable. With it, a system administrator or technician can install a system without wasting an hour or two just clicking OK every three minutes. Here’s how to take advantage of unattended installations.

What you need to get started
There are three major components to setting up a complete automatic installation: the UDF, the Unattend.txt script file, and the SYSDIFF tool. We’ll talk about the UDF in this article.
I recommend that you download a copy of the applicable Microsoft online documentation for reference if and when you get into the more difficult features. Unfortunately, space limitations prevent me from detailing each section of the Unattend.txt, SYSDIFF tool, and UDF.

In our discussion, we’ll assume that you’re installing NT on an x86 computer with an active operating system and a network link between your target computer and distribution server. All the NT files from the CD are on a system named \\installer acting as a distribution server, with the NT source files in the \\installer\source directory and any custom files we generate in the \\installer\custom directory.

Using Setup Manager
There are limits to what the Setup Manager and the Unattend.txt can do, and the primary limitation is that all systems configured with a given Unattend.txt file will be identical. This limitation immediately prevents the use of disk duplication systems for computers destined for networks with assigned IP addresses or other mutually exclusive settings. (Disk duplication is done after the initial text-mode installation when the system is rebooted and before the GUI starts. See the “Automatic Windows NT Setup Deployment Guide” document for more details.)

Fortunately, Microsoft has included a unique database file (UDF) that can be used to modify NT’s settings after the character-mode phase of installation has completed but before the first GUI boot. It can add, modify, or remove lines that appeared in the setup script.

The installation has to expect the use of a UDF or it will not be able to index the file. This is done by using the /UDF switch with Winnt.exe or Winnt32.exe and specifying a unique ID and the name of the UDF, including the path. Note that while the uniqueness database file is referred to as a UDF, the actual file extension is .udb and cannot be replaced. Further, the unique ID cannot contain asterisks [*], spaces, commas, or equal [=] signs.

If only the unique ID is listed, the installation will prompt the user for a disk containing the file $Unique$.udb during the graphical phase of installation. Very useful when no one’s sure exactly what use the machine will be put to. Of course, if no one has a disk with a valid UDF, the install will abort.

Here is the proper install syntax using the unique ID of CLEANPC on our sample system. Later you’ll need to create a floppy with the file $Unique$.udb to complete the installation.
\\installer\source\WINNT.EXE /U:\\installer\custom
\UNATTEND.TXT /S:\\installer\source /UDF:CLEANPC

The other option is to include the UDF at installation, which will be used during setup without any user intervention. It may not be obvious why you would want to include the UDF at setup instead of providing the UDF on floppy or simply creating multiple setup scripts. There are two situations where it makes sense to go this route:

  1. 1.      The users can’t be trusted to read simple instructions and/or keep up with the floppy disks.
  2. 2.      You want to use disk duplication to install a large number of machines in a much shorter time, and the time configuring and editing the UDF will be worth it in the long run.

The format of the UDF is identical to that of the Unattend.txt file except that the any ID-specific setting has a header in the format of [uniqueID:header]. To modify the [userdata] part of the setup script for machines with the unique ID of “IAMSPECIAL” the UDF would have a section with the header [IAMSPECIAL:userdata]. Microsoft’s Deployment Guide contains a sample UDF you can refer to.

Continuing our example, we’ve created a UDF located in the \\installer\custom directory called Specialbox.udb that has four different configurations keyed to the IDs “standard,” “programmer,” “engineer,” and “executive,” where standard is the default configuration. If the system will need one of the other configurations, the administrator will use a boot floppy to edit the Specialbox.udb file on the hard disk and rename the correct configuration to standard. When the box is booted next, it will become the type of machine needed without the user doing anything or the admin sitting through the rest of the install.
The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.