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_MACHINE\SECURITY\SAM\
DOMAINS\ACCOUNT\V. 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.
End of Article
Prev. page
1
[2]
next page -->
