NT Rollout Options

NT Rollout Options

Microsoft has aimed Windows NT at corporate environments since the product's inception. To Microsoft, a corporate environment includes everything from a small business with a handful of computers, to midsized companies with tens or hundreds of computers, to enterprise-level giants with thousands of computers. The first job NT administrators face in a corporate environment is installing and configuring NT. A common follow-on requirement is setting up individual users with the group of applications that are standard in the company's computing environment. These applications might include an office suite, an email client, and proprietary company tools.

The straightforward way to perform a mass installation (commonly referred to as a rollout) of NT and add-on software is to move from machine to machine, running NT Setup manually and executing the setup programs for each application. This method gets the job done, but it's time-consuming. Performing one full installation of NT takes from 20 minutes to an hour, and installing an additional large suite such as Microsoft Office can take a similar length of time. If you take 2 hours to install NT on each computer in your enterprise, you'll average four installations per day--a rate

that's not feasible for sites with 100 or more systems. Even spending 2 days of repetitive manual work installing NT on 10 computers is not efficient use of a systems administrator's time.

But you do have choices, and in this article I'll review the alternative rollout techniques of unattended installation and cloning. I won't provide a rollout recipe, but I will give you an overview of your options and the processes involved with different rollout methods. Cloning is the most time-efficient way to mass-install NT, but concern exists that cloning multiple machines on an NT network will distribute identical computer security IDs (SIDs). I'll clarify the issues cloning raises and present possible solutions to the problems cloning can cause. I'll also discuss Microsoft's stand on cloning NT (Microsoft's Ken Smiley, Program Manager of Enterprise Program Managers--EPMs--and Partner Program Managers--PPMs--provided me with valuable information and comments about this subject).

Preparing for Rollout
Before you can apply any NT installation method, your target machines must have a functional operating system (OS) and access to your network or a CD-ROM drive. You place the files for your particular installation on the network or in the CD-ROM drive.

For example, if you are implementing a setup-based rollout, the NT distribution CD-ROM will contain the required setup files. You place these setup files on a server with a network share, or you place the CD-ROM in a CD-ROM drive that the target computers can access.

If you are performing upgrades from a previous version of NT or have machines with Windows 95 installed, you probably have access to a CD-ROM drive, or a network. However, if any of your target computers have no OS, you must use a DOS boot disk to install NT. There are two ways to proceed in this case. First, if the target computer has a CD-ROM drive, you can use a CD-ROM with the NT installation files. Use the DOS boot disk to partition and format the computer's hard disks, then perform the NT install from the CD-ROM to the hard disks.

Second, if the target computers don't have a CD-ROM drive, or if you want to run a remotely managed installation with installation files on a central network-accessible drive, you must obtain and install DOS network drivers for the network cards on the target machines. Installing DOS network drivers usually means installing a protocol driver (e.g., TCP/IP) and a network interface card driver. Microsoft makes this process straightforward for most common network cards. Simply run the Network Client Administrator utility in the NT Administrative Tools program group, which enables you to create a Network Installation Startup Disk. A Network Installation Startup Disk is nothing more than a DOS boot disk populated with the correct protocol and network card drivers. With the Network Installation Startup Disk, you can boot your client machines and mount the network share point for access to installation files.

The Microsoft Windows NT Workstation 4.0 Resource Kit clearly describes the steps and options for creating Network Installation Startup Disks. Although the resource kit discusses the process of making startup disks in the context of rollouts based on NT Setup, you can create startup disks as part of a rollout based on cloning in which a cloned image is located on a network.

Another rollout option worth your consideration is the use of Systems Management Server. SMS is a BackOffice application that enables NT Server to remotely administer NT, Win95, and DOS clients. This facility is particularly useful in environments in which you want to push NT installation, rather than manually execute each install or have your users initiate installations. With SMS clients configured on target computers with network access, you can prepare installation files on a network share and then start the installation process remotely. If you're basing your remote rollout on the use of NT Setup, use unattended setup techniques, which I'll discuss shortly. You can learn more about the use of SMS in rollout situations in the resource kit.

Setup-based NT Rollouts
You can perform a setup-based rollout in a variety of ways. I've mentioned the most basic method: moving physically from machine to machine, running NT Setup and installing individual software applications. Although Microsoft approves this approach, installing NT this way is not an efficient use of your time, unless you're installing a small number of machines.

The resource kit documents methods for rolling out NT and add-on software. It describes an efficient NT installation procedure that is based on an automated form of NT Setup known as unattended installation. You use the same NT Setup program for unattended installs as you use for manual installation, but a file that contains answers and entries for the questions and forms that the Setup program presents during the install process guides the unattended installation setup. The answer file is divided into sections such as [UserData] and [Network] that you configure with elements such as computer name, domain or workgroup selection, and network card configuration.

In an unattended installation, instead of writing an answer file, you start with a template, called unattend.txt, on the NT distribution CD-ROM under processor-specific directories (e.g., i386, alpha). To specify to NT Setup that you want to use an answer file, run the NT Setup program (winnt from DOS, or winnt32 from Win95 and NT) with the /u switch followed by the path of the file. For instance, entering

winnt32/u:c:installunattend.txt

tells NT's Setup to use the unattended answer file C:installunattend.txt. Figure 1 shows the sample answer file the resource kit provides.

One answer file probably won't be appropriate for all the computers you are configuring; each computer can require a different computer name, network adapter identifier, and other identifiers. Fortunately, unattended installa-
tion provides a mechanism--Uniqueness Database Files (UDFs)--for coping with these differences without forcing you to write a custom unattended answer file for each computer. UDFs are structured in much the same way as answer files, with sections containing settings that address specific configuration options for NT Setup. UDFs are different from answer files in that, at the top of the UDF in a section called [UniqueIds] you define unique identifiers that are related to specific computers or groups of computers at your site. To the right of each identifier you list the sections specific to that identifier, as this example shows:

[UniqueIds]

Mark = UserData,Unattended

Fred = UserData,KeyboardDrivers

The remainder of the file consists of the sections you referenced under [UniqueIds]. You can name these sections with titles that match those in the answer file, or you can name them in the form sectionname:identifier, in which identifier is one of the identifiers you specified in the [UniqueIds] section. To tell NT Setup that you want it to use answers included in a UDF, you give Setup one of the uniqueness identifiers. As Setup runs, it checks for answers associated with the uniqueness identifier in the UDF and overrides the corresponding answers in the answer file.

For instance, say that a UDF contains the identifiers from the previous example and a section called [Mark:UserData] that has the value MarksComputer for ComputerName. If NT Setup uses the Mark ID and the UDF during setup, NT Setup will override the computer name in the answer file with MarksComputer. This procedure lets you assign each system a different name and enter all the system names you've assigned in the same UDF file.

The syntax for NT Setup's UDF command-line switch is /UDF:ID,UDF Filename. For example, you might enter

winnt32/u:n:unattend.txt /udf:mark,n:udf.txt

Specifying the UDF filename and path is optional. If you omit the UDF filename, NT Setup will look for a file named $Unique$.udf on a disk in the machine's 3.5" disk drive and use that file as the UDF. Setup will prompt you to insert a disk containing the $Unique$
.udf file during the install and will resort to using the answer file only if the UDF is unreadable or not present.

Add-on Application Rollouts
You can roll out NT with unattended installation and UDFs, but how do you install your company's add-on software efficiently, preferably at the same time you install NT? If the add-on products support scripted setup, you can integrate their installation into part of the unattended NT installation. To do so, place the add-on application's install files in a directory named $OEM$drive letter, in which drive letter represents the drive on the target computer where you want to install the add-on program. For example, if you want to install Microsoft Office in C:MSOffice, place the installation files in $OEM$CMSOffice.

Using the sysdiff utility. Many applications do not support scripted setup, but Microsoft's sysdiff utility, included in the resource kit, lets you work around this problem. Sysdiff gives you an application-independent way to create an image file that contains all the information necessary to make a computer appear as if an application's setup program has run. The technology behind this feat is fairly simple. First, run sysdiff with its /snap option before installing the application on a template computer. Configure the template system in the same way you plan to configure the target systems, with the same NT root directory (e.g., C:winnt) and CPU type (e.g., x86, Alpha). The /snap option causes sysdiff to record the state of the machine in a snapshot file before the application installation.

Second, install the application, and then execute sysdiff using /diff. Sysdiff will analyze the disk drives and Registry. Based on the information in the snapshot file, sysdiff will determine what changed during the installation. Sysdiff writes these changes to the difference file that you specify, and you can apply this file to destination computers with sysdiff's /apply option.

An important part of running sysdiff is specifying the names of files and Registry keys that you want sysdiff to ignore during the difference comparison. Sysdiff will look for the sysdiff.inf file, which contains these exclusions. Consider placing all files and Registry keys that are not relevant to an application in sysdiff.inf. For example, you typically place paging files in sysdiff.inf.

You can install an application with sysdiff manually after you complete the NT Setup, or you can include the sysdiff application installation in an unattended NT installation. To install an application as part of an unattended NT installation, place the difference file you've designated in a directory on the distribution share point called $OEM$$$appdirectory (appdirectory stands for the name of the application). Then create a file called cmdlines.txt under $OEM$. This file should begin with a section titled [Commands], followed by each command on a subsequent line. The commands can be arbitrary and do not have to be associated with sysdiff. An example of a sysdiff command to apply a difference file in $OEM$$$appdirectory is

sysdiff/apply $$appdirectory
differencefile

Clone-based Rollouts
Throughout the past year and a half, installing OSs by cloning has become popular. The word cloning does a good job of describing the process involved. To clone, you simply install NT on a template computer that is identical to the computers you will be rolling out NT to, configure it for your network, and then use a third-party cloning tool to create an image file that represents the contents of the template computer's disk drives. Again using the cloning software, you copy the copied disk images from a network share onto the disks of your target computers. Assuming everything goes according to plan, the target systems will be indistinguishable from the template system, and they will appear to have undergone a full NT installation.

Rather than reading files from the template machine, cloning tools read raw data from its disks. Reading raw data is easier for cloning tools than reading files, and reading raw data captures information (such as the boot sector's contents that point to NT's OSLOADER bootstrapping program) that NT stores on disks and that isn't visible with file-based copying. Most third-party cloning tools compress image files to make them as small as possible.

Cloning is attractive because it is fast. Instead of executing NT Setup and applying sysdiff image files for add-on programs, a clone-based installation copies a disk image file onto a target computer. Cloning can shorten installation time by minutes or hours, depending on the speed of the computer and the number of applications you're installing. Another attractive feature of cloning is that it takes the same amount of time to install NT and 1 application as it does to install NT and 20 applications. The size of image files may vary depending on whether you install 1 or 20 applications, but copying an image file is a very fast process. Finally, installing NT with cloning saves you the trouble of having to learn how to perform an unattended installation and use sysdiff, and you don't end up with install scripts and configuration files to debug.

But cloning has a disadvantage: All the target computers must be identical to the template computer. NT 3.51 and 4.0 Setup programs perform hardware-device detection and configure NT according to what they find on a computer. If you use cloning to install NT on a computer with hardware that differs even slightly from the template computer's hardware, NT might not function properly on the target machine. (See the sidebar "Where to Find Cloning Software and SID Changers," page 144, for a list of vendors offering cloning software.)

SIDs and Cloning
When you clone template computers, the clone machines are identical byte-for-byte to one another and to the template computer, including the unique SID that NT Setup generates to identify the template computer. This special SID is known as the computer SID or the machine SID. Before you can understand the issues duplicate SIDs raise, you need to understand how NT creates and uses SIDs.

A SID consists of several numeric components, including a revision number, a 48-bit authority identifier, and a variable number of subauthority identifiers, or relative IDs (RIDs). The authority value identifies the entity, such as an NT domain, that issued the SID. Subauthority values identify a trustee relative to the authority entity. You've prob-
ably seen textual representations of SIDs, which are of the form S-R-I-S-S ..., where R is the revision number of the SID, I is the 48-bit authority value, and the trailing S's are subauthority values, or RIDs. NT generates SIDs in a way that ensures that no two SIDs will be equal (the probability that two SIDs will be equal is infinitesimally small).

SIDs identify computers, local user accounts and groups, domains, and domain user accounts and groups. However, NT derives local user accounts and group SIDs from the computer SID, and domain user accounts and group SIDs from the domain SID. NT constructs a SID for a local account or group by concatenating a locally unique RID to the computer SID, whereas NT constructs domain accounts and groups by concatenating a RID that is unique to the domain to the domain's SID. For example, the SID of the first local account NT creates on a computer will have a RID of 1001 added to the computer SID: ComputerSID-1001, S-1-5-21-452234-34999344-5962386-1001. The second account's SID will be ComputerSID-1002, S-1-5-21-452234-34999344-5962386-1002. You can easily see the SID for the account you're logged on to by opening regedit and looking under the HKEY_USERS key. As Screen 1 shows, you'll find two subkeys: .DEFAULT (the profile NT applies when nobody is logged on) and the SID of the account.

When you have two or more computers with the same computer SID, local user and group accounts of different computers get the same SID. If Mark is the first account NT creates on one computer and Fred is the first account NT creates on another computer with the same computer SID, NT will issue the same RID to both accounts, which therefore will have the same SID.

There are two scenarios in which aliased SIDs confuse NT's security mechanisms. The first scenario is a workgroup environment. In a workgroup, a number of NT machines are connected in a peer-based model, and they can share resources such as disks and printers with one another through a network. When a user on a workgroup member machine accesses a resource on another workgroup member machine, the user's local SID (a workgroup has no domain SIDs) identifies the user to the remote computer. Consider the case Figure 2 shows, in which Mark on Computer1 accesses files on a shared drive served off Computer2. If Computer1 and Computer2 are clones with the same computer SID, and if the Fred account on Computer2 has the same RID as the Mark account, Mark will look exactly like Fred to Computer2. Mark can therefore view all the files Fred can view, including Fred's private files, and vice versa.

The second scenario in which SID duplication causes security confusion concerns removable media, such as Jaz drives, which can include security information when their formatting includes NTFS. In the example in Figure 2, Fred can view any files on removable media that Mark can view, because neither Computer1 nor Computer2 can distinguish between the two users with respect to the security permissions assigned to files on the removable drive.

Contrary to common belief, these two scenarios are the only known situations where duplicate computer SIDs cause problems. Duplicate computer SIDs will not cause networks to fail, nor will they cause other problems in an upgrade from NT 4.0 to 5.0.

SID Changers
In response to demand from cloning-software customers for a solution to the duplicate-SID problem, several third-party SID changers have appeared in the past 6 months. You apply SID changers to cloned machines to prevent the security problems I just described.

A SID changer generates a new SID to replace the cloned computer's SID, which is in the Registry under HKEY_
LOCAL_MACHINESECURITYSAM
DOMAINSACCOUNTV. Then the SID changer scans security information in files and the Registry, changing all instances of the old computer SID to the new SID. This process changes the SIDs of all of the computer's local user accounts and groups, and at the same time, updates references to them in file and Registry security information. Except for changing the SIDs and addressing the workgroup and removable media issues, a SID changer does not change the computer. (See the sidebar for a list of vendors who offer SID changers.)

Microsoft's Stand on Cloning
Microsoft has documented its position on cloning in its recent white paper, "Binary Image Copying of Microsoft Operating Systems" (available at http://
www.microsoft.com/ithome). In this white paper, Microsoft states that it enforces a restricted support policy for NT 4.0 systems that are cloned after NT Setup has entered its GUI-based phase (i.e., after Setup completes its text-based portion and reboots the computer). If you call Microsoft with a problem that is occurring on a machine that was cloned after NT Setup entered the GUI phase and the support technician cannot quickly correct the problem, the technician will ask you to either reinstall NT and see whether the problem persists or verify that you can reproduce the problem on a noncloned computer. Otherwise, Microsoft support will not escalate the incident to Quick Fix Engineering (QFE) or Critical Problem Resolution (CPR) levels

.

Microsoft has taken this stance not because of the duplicate-SID issue, but because subtle, nonidentical hardware or software configuration problems can result from copying configurations from one computer to another. Even if you buy two computers of the same model from the same vendor at the same time, you might find minute hardware- or software-configuration differences between the machines if you clone them after NT Setup enters the GUI phase.

Microsoft plans to release its SID changer by mid-1998. Some people will view the release of this tool as a mixed message from Microsoft, but the tool is simply a way for Microsoft to facilitate the rollout of NT 4.0. At the same time, the company is making clear that it won't tie up support technicians by requiring them to track down bizarre problems that systems administrators can cause by bypassing NT Setup.

Microsoft has stated that it will fully support NT 5.0 cloning on computers that adhere to certain hardware standards. The subtle hardware differences that can affect NT 4.0 clones are not an issue when NT 5.0 is cloned on machines constructed to NT 5.0-compatible PC98 hardware standards.

The Choice Is Yours
If you're rolling out NT, you can choose between using Microsoft-endorsed unattended Setup and sysdiff, or cloning. Although cloning has several advantages, you should carefully assess the effect its use has on computer security and Microsoft's support policy.