If you're planning a Windows 2000 (Win2K) enterprise structure, forget forests and trees and go for a single domain. Under Windows NT 4.0, administrators build multidomain enterprises for political and technical reasons. The technical reasons include slow WAN links, too many accounts to fit in one domain, local control of servers, and too many preexisting domains and no easy way to flatten them to a single domain. Win2K provides a solution for each of these technical concerns.
Better Bandwidth Use
When an NT 4.0 PDC replicates SAM changes to BDCs, the PDC doesn't control the communication. The PDC asks the BDCs to begin a session with the PDC so that the PDC can replicate the SAM changes to each BDC, one at a time. When the invited BDCs have time, they direct the PDC to replicate the SAM changes. The PDC replicates the changes in the same way regardless of whether it's replicating over a high-speed LAN link or a slower WAN link. In addition, an NT 4.0 PDC replicates the entire user record to the BDCs. For example, if Joe changes his password but not his name, description, profile path, or logon hours, the PDC still replicates Joe's entire user record to the BDC.
In contrast, Win2K replicates only the fields that the user has changed. For example, a Win2K domain controller that replicates Joe's password change to another domain controller will transmit only the new password. In addition, you tell Win2K's Active Directory (AD) which domain controllers connect with high-speed links and which domain controllers talk via slower, more expensive links. So, a Win2K domain controller can examine how it's connected to another domain controller before it starts communicating. If the link is slow, the first domain controller compresses its data before it sends the data over the WAN link.
Suppose an NT 4.0 PDC is replicating SAM domain changes to 10 BDCs in a different location, and the two locations are connected with only a low-speed link. The PDC updates the BDCs separately, so the "Joe changed his password" conversation takes place 10 times over the WAN link. Win2K handles this situation more effectively. To update 10 remote domain controllers, a Win2K domain controller hands the new information to only one of the remote domain controllers. The receiving remote domain controller then distributes the new information to the other nine domain controllers. This solution is a more conservative approach to WAN bandwidth use.
Bigger Account Database
NT 4.0's SAM database doesn't have a theoretical maximum size, but its practical limit is about 10,000 users. Thus, the administrator of an enterprise with 100,000 employees must spread user accounts over several domains into a multimaster domain model.
Win2K doesn't have this limitation. Microsoft claims that Boeing has had good luck testing an AD database that contains 1.5 million objects, and people at Compaq tell me that they've had good results testing a 20-million-object database.
Local or Departmental Control of Servers
Most companies centralize their IT functions in an IT department—this group creates user accounts, looks after the network cabling and WAN links, and might even buy servers. However, the data on the servers isn't usually the IT department's property, and the integrity of that data is less the worry of the IT department than the worry of, for example, the accounting department. If the IT department doesn't properly back up the data and a server goes down, the IT department is accountable for the mistake, but the accounting department might be out of business. As a result, the head of the accounting department might want the administrators of the servers that hold the accounting data to work for him or her rather than for the IT department.
Granting local or departmental control of servers is difficult to implement under NT 4.0. The only way to segregate a set of servers from the other servers in the enterprise is to create a resource domain (i.e., a new domain) for the separate servers (e.g., the accounting servers). These extra domains mean administrators must worry about trust relationships, which are an administrative headache.
To solve this problem, Win2K uses subdomain folders called organizational units (OUs). For example, within the enterprise's large domain, the accounting department has an Accounting Servers OU that contains the machine accounts for the accounting department's servers. Win2K lets the enterprise cede control of the Accounting Servers OU to a group of administrators who work for the accounting department. The accounting folks thus retain control of their servers without having to maintain a separate domain.
Consolidating Existing Domains Isn't Easy
One of the most common reasons that enterprises maintain many domains is simply, "Hey, we found it like that." Some organizations implemented NT years ago without a plan for a central domain model. These firms now have a mishmash of domains in neither a master resource nor a multiple-master resource model. Some companies had organized domain models but then acquired another firm, a situation that resulted in more domains that administrators had to somehow assimilate into the corporate network.
Under NT 4.0, administrators consolidate (the new industry term for merge) domains the hard way. If you have 1000 accounts in domain A and 1000 accounts in domain B, you consolidate A and B by rebuilding domain B's 1000 accounts in domain A. Many brave souls use the Microsoft Windows NT Server 4.0 Resource Kit's Addusers tool to accomplish this feat, but consolidating domains is never easy.
I'd like to tell you that Win2K includes a tool that simplifies this process, but whether Microsoft will include the domain-consolidation tool it promised to ship with Win2K remains to be seen. If Win2K doesn't include this feature, many third-party programs, such as FastLane Technologies' DM/ Manager, can simplify or automate the domain-migration process. In addition, Mission Critical Software is developing Domain Migrator, migration technology that is part of Mission Critical's OnePoint suite, and Microsoft recently announced that it will license this technology. Although Microsoft claims it will ship this technology with Win2K, this announcement isn't a guarantee. Whether Microsoft releases this tool or uses its guts as a starting point for developing a Microsoft domain-consolidation tool is uncertain. Stay tuned to see how this interesting situation develops.
Stop Fussing
Multidomain enterprises have been the bane of many a network administrator's existence. Fussing with trust relationships, shuffling global groups from master domains to resource domains, and running programs such as Nltest and Netdom to keep existing trust structures working is staff-intensive and time-consuming. Under NT 4.0, administrators had solid reasons for building multidomain enterprises. But those reasons don't hold up under Win2K. Simplify your life: Set up a single-domain model for your Win2K implementation.
