SUPPORT FOR CLONED SYSTEMS
BUILDING LARGE NETWORKS takes time. The more systems you need to build, the longer the rollout will take. Suppose you have to build 500 Windows NT 4.0 workstations from scratch. If each system build takes an hour, this 500-hour rollout will take one administrator 12 forty-hour weeks and 1 day to complete, or four administrators 3 weeks and 5 hours to complete—assuming each workstation takes only 1 hour to build. With applications added to the OS installation, the build-time increases exponentially, right with the total cost of owning those workstations.
Disk-cloning software can solve the increased cost of ownership problem. With cloning software, you can install and configure complete system software packages once and clone the installation to numerous additional workstations. After you achieve the initial installation, the cost of cloning that installation onto other systems drops tremendously, because all cloning requires is the time to copy one disk to another.
To determine which required drivers and configuration settings to install for a particular computer system, OSs rely on the hardware platform. Therefore, to clone systems, you must ensure that all cloned machines use identical hardware. Otherwise, the wrong drivers will install and the machines will fail to operate correctly. Administrators who use dissimilar hardware must reinstall the proper hardware drivers after the cloning, and that task defeats the purpose of cloning.
In the past, Microsoft hasn't supported cloned systems because of problems inherent in the cloning mechanism. NT systems require unique security IDs (SIDs) to operate correctly in a networked NT environment. Correspondingly, each cloned NT system requires a unique SID. SID generators, such as Norton Ghost Walker and Systems Internals' NewSID shareware software, create unique SIDs to assign to cloned NT systems. SID generators work well, as long as you understand the limitations and pitfalls involved in cloning one system to another. However, Microsoft supports only proprietary software and cloned systems with SIDs that the company's new System Preparation (SysPrep) tool generates. (For information about obtaining SysPrep, go to the Microsoft Web site at http://www.microsoft.com/ntworkstation/deployment/ deployment/syspreptool.asp.)
Introducing SysPrep
SysPrep is a SID generator that works with third-party disk-cloning tools such as Norton Ghost. SysPrep generates a unique SID and sets a few vital system parameters, such as the machine's NetBIOS name and the initial administrator account password.
SysPrep requires that you install NT Workstation 4.0 using a CD-ROM and that you participate in Microsoft's Select, Open, or Enterprise licensing programs. (For more information about Microsoft volume software licensing and program requirements, go to the Microsoft Web site at http://www.microsoft.com/licensing.)
Be aware that a difference exists between the various NT master installation CD-ROMs. SysPrep can detect the difference and enforce the licensing program restriction. Therefore, Open and Enterprise license customers need to run SysPrep with a -defeat commandline switch to override the detection mechanism. NT installations using the Select CD-ROMs don't require overriding the detection mechanism.
SysPrep supports NT Workstation 4.0 and can support NT Server 4.0 as a standalone server. Microsoft plans to ship SysPrep with the Windows 2000 (Win2K) release. SysPrep won't work with Primary Domain Controllers (PDCs) and Backup Domain Controllers (BDCs); NT 3.51 or earlier; NT Server, Enterprise Edition; NT Server 4.0, Terminal Server Edition; or BackOffice Small Business Server (SBS).
Besides these limitations, SysPrep has other caveats, which the product's README file explains. For example, you can't preinstall Systems Management Server (SMS) client software on the source PC you clone to other systems. You must install the SMS client to each cloned system after you boot the cloned system for the first time.
Hazards of Cloning NT
Let's examine the pitfalls of cloning systems and generating SIDs outside a normal NT installation. First, NT generates many identifiers on the fly. For example, when you create a user account, create a new user group, and join an NT system to a domain, the OS generates unique IDs. Additionally, certain software installations, such as third-party system services, might require the use of a unique ID if the service requires an account to run under.
NT uses SIDs to learn where actions originate and to determine whether those actions have authorization. Because SIDs are the heart of NT system security, SID generators must create unique SIDs correctly. SID generators need to know when to create the SIDs. Any software you install before SysPrep generates a unique SID during the initial boot sequence will become invalid after SysPrep generates the new SID.
The reason the software becomes invalid is because of the way SID generators create SIDs. Here's what happens. When you first install NT, the setup routine generates a unique SID. The computer uses this SID as a unique prefix for all the machine's local accounts. Suppose, for example, that the SID for a system is XYZ123, and you create two new user accounts for system services to run on that system. The SIDs for those accounts are XYZ123-1000 and XYZ123-1001. When you first run SysPrep on the computer, SysPrep will change the system's SID prefix. Let's assume the new SID prefix is PEG4555. When the system services try to start using their SIDs of XYZ123-1000 and XYZ123-1001, they will fail their security authorization, because the system expects their SIDs to be PEG4555-1000 and PEG4555-1001.