Windows NT Server organizes groups of computers into domains so that all the machines in a domain can share a common database and security policy. Domain controllers are systems that run NT Server and share the centralized directory database that stores user account and security information for one domain. When users log on to a domain account, the domain controllers authenticate the users' username and password against the information in the directory database. (You might know the directory database as the security domain database or as the SAM database.)
During NT Server installation, you must designate the role that servers will play in a domain. NT gives you three choices for this role: PDC, BDC, and member server (i.e., a standalone server). You create a domain when you designate a PDC. PDCs and BDCs are crucial elements in domain theory and practice. To maintain control of and get the most out of the domains you establish in your NT network, you need to understand what PDCs and BDCs are, how to synchronize the directory database from a PDC to the BDCs in its domain, how to promote a BDC to a PDC when the PDC is offline, how to determine the optimum number of BDCs for a domain, and how to manage trust relationships between the PDCs of separate domains.
PDCs and BDCs: What's the Difference?
Although NT 4.0 and NT 3.51 domains can contain multiple servers, only one server in a domain can be a PDC. The PDC stores domain accounts and security information in the master copy of the directory database, which the PDC maintains. When you make changes to user accounts or security information, the PDC records the changes on the directory database master copy. A PDC is the only domain server that directly receives these changes. In other words, PDCs store a read-write copy of the directory database.
A domain can have multiple BDCs. Each BDC in a domain maintains a read-only copy of the PDC's master directory database. You can't make changes to a BDC's copy of the directory database. Because directory database duplication occurs between the PDC's master directory database and the BDCs' directory database copies, you can promote any BDC in a domain to the PDC if the original PDC fails or you must shut it down for maintenance. BDCs also help share the load of authenticating network logons.
Having at least one BDC in a domain is crucial. If the PDC fails, you can keep the domain functioning by promoting the BDC to PDC. Promoting the BDC ensures that you can make changes to the directory database and propagate those changes throughout the network. BDC promotion also guarantees access to network resources and keeps the directory database accessible to the domain. If the directory database isn't accessible to the domain, users can't log on and become authenticated to the domain. Computers can't identify themselves to the domain and therefore can't create the secure channel necessary for communication between machines in the domain. Group accounts won't have access to resources in the domain. In short, without a BDC to promote to PDC, you'll have a lot of explaining to do when your network comes to a halt.
Windows 2000 (Win2K) approaches domain controllers differently than NT does. As NT domain controllers do, Win2K domain controllers store a copy of the directory database. However, NT 4.0 and NT 3.51 implement a single master replication model in which only a domain's PDC holds the directory database master copy. In contrast, all Win2K domain controllers hold a read-write copy of the directory database. Further, in NT 4.0 and NT 3.51, a domain's PDC must always be accessible for changes to take place to the directory database. Such is not the case with Win2K because Active Directory (AD) implements the multimaster replication model. This replication model lets an administrator make changes to the directory database on any domain controller in a domain. The domain controller then replicates the changes to all other domain controllers in the domain. The result is 100 percent availability of the directory database, even if individual domain controllers are temporarily unavailable. All domain controllers in the multimaster replication model are equal; that is, the PDC and BDC designations don't exist. The sidebar "Migrating to a Windows 2000 Domain from an NT 4.0 or NT 3.51 Domain" explains what happens to your domain controllers when you migrate to Win2K.
Domain Controller Synchronization
Directory database replication occurs when a domain's PDC synchronizes the database with each BDC in its domain. The system regularly synchronizes all the BDCs in a domain to maintain centralized security. When you first set up a BDC, the BDC fully synchronizes with the PDC. For that reason, setting up the connection over a high-speed link is advantageous. After the first full synchronization, partial synchronizations to the BDC occur when you or the system makes changes to the PDC's directory database.
Occasionally, the domain directory database can become unsynchronized on a BDC. For example, the BDC might go down or experience timing problems during network communication. If a BDC becomes unsynchronized, you can perform a manual synchronization. In NT 3.51, to effect a full synchronization of a specific BDC, you select Synchronize with Primary Domain Controller from Server Manager's Computer menu. However, making this selection in NT 4.0 will trigger only a partial synchronization if the PDC and BDC are both running NT Server 4.0. (See the sidebar "Domain Administration from an NT Workstation" for information about how to administer domains from an NT workstation.) Therefore, you need to execute the Net Accounts /synch command at a command prompt on the unsynchronized BDC to force a full synchronization. To manually synchronize all domain controllers in a domain, select the domain's PDC in Server Manager, then choose Synchronize Entire Domain from the Computer menu.
Promoting Domain Controllers
At times, you'll need to promote a BDC to a PDC. For example, you might need to perform routine maintenance on the PDC, or you might experience hardware problems on the PDC. When you promote a BDC to a PDC, the system automatically demotes the original PDC to a BDC after replication takes place.
To promote a BDC to a PDC, use Server Manager to select the BDC that you want to promote. From the Computer menu, choose Promote to Primary Domain Controller, as Screen 1 shows. If Server Manager can't locate the PDC, you'll receive a message stating that fact. Server Manager will give you the option of proceeding without demoting the PDC or of waiting until Server Manager can find and demote the PDC.
Promoting a BDC when the PDC isn't available. In general, a domain can function without its PDC for a short time. However, taking a PDC offline for longer than an hour without promoting a BDC to replace it isn't good policy. If you must take a PDC offline for longer than an hour, or if the unimaginable happens and your PDC crashes, you can't implement user account and security policy changes while the PDC is unavailable. However, the domain will continue to authenticate users, who can still log on to the domain.
When you promote a BDC while the PDC is offline, Server Manager will display the warning message Server Manager cannot find the Primary Domain Controller for DomainName. You may administer the domain, but certain command-wide operations will be disabled. Other difficulties arise if you promote a BDC while the PDC is offline. When the original PDC comes back online, Server Manager might still list it as the PDC, but such is not the case. When the original PDC detects the PDC that you promoted from a BDC, the original PDC will shut down its Netlogon and Remote Management services, dim its icon under Server Manager, and quit participating in user logon authentication or synchronization with the current PDC. At this point, the original PDC will do little more than act as an NT workstation.
To restore an original PDC to its role as PDC, you need to first demote it to a BDC and effect a synchronization with the replacement PDC. If you don't do so, any changes that you or the system made to the replacement PDC—including changes to Local Security Authority (LSA) secrets—can't synchronize with the original PDC. As a result, the changes made to the replacement PDC are lost. Therefore, in order to restore the original PDC, you must demote it to a BDC, synchronize it with the replacement PDC, then promote it to PDC. Here's how to accomplish such a promotion.
First, when you demote the original PDC to a BDC, make sure to clear the Show Domain Members Only entry in Server Manager's View menu, as Screen 2 shows. When you clear this entry, the browser service presents the list of domain controllers in Server Manager. The browser list informs Server Manager that the original PDC is configured as a PDC and that the system will allow the PDC's demotion to BDC. If you don't clear the entry, Server Manager scans the current PDC's Registry and doesn't let you demote the original PDC. The current PDC will consider the original PDC to be a BDC because the current PDC's Registry doesn't contain the original PDC's role in the domain. The current PDC's role is the only PDC role the system will maintain.
To demote the original PDC, select its computer name in the Server Manager browser list and choose Demote to Backup Domain Controller from the Computer menu. Next, select Synchronize with Primary Domain Controller to synchronize this machine with the current PDC. Finally, choose Promote to Primary Domain Controller and the system will demote the current PDC and promote the original PDC.
BDCs and Replication
Theoretically, no limit exists to the number of BDCs that a domain can include. However, real-world situations do affect the number of BDCs that a domain can practically deploy. Replication time and traffic are two crucial considerations that determine the optimum number of BDCs in a given domain.
By design, the replication process limits network bandwidth consumption. NT 3.51 will attempt to replicate only as many as 10 BDCs at a time. NT 4.0 will attempt to replicate as many as 20 BDCs at a time. Technically, Netlogon can support between 500 and 1000 BDCs in one domain over a fast link. Slower links (e.g., RAS, 56Kbps or 128Kbps modems) can handle as many as 700 BDCs. However, having a large number of BDCs in a domain isn't practical because limiting the amount of traffic among a large number of BDCs would require making few directory changes at a time. The optimum domain design calls for a small number of powerful domain controllers connected over fast network links. Table 1 lists Microsoft's recommended ratios for user accounts to BDCs.
Problems with BDC Secure Channels
When Netlogon on NT Server 4.0 starts on a PDC, the system enumerates all computer accounts in the domain and builds a structure that establishes a secure channel between the PDCs and BDCs. Netlogon enumerates a group of 250 accounts on each call to the directory database. Because of an inherent fault, Netlogon misses one account within each group of 250. This miss isn't a problem when it involves workstation computer accounts. However, on BDC computer accounts, the Netlogon service can fail to start on a particular BDC.
If Netlogon doesn't start on a BDC, the BDC will record one of two Netlogon errors: Error 3210, Failed to authenticate with ComputerName, a Windows NT domain controller for domain DomainName; or error 5721, The session setup to the Windows NT Domain Controller Unknown for the domain DomainName failed because the Windows NT Domain Controller does not have an account for the computer ComputerName. The PDC might also record one of two Netlogon errors in the event log: Error 5722, The session setup from the computer ComputerName failed to authenticate. The name of the account referenced in the security database is AccountName. The following error occurred: Text; or error 5723, The session setup from the computer ComputerName failed because there is no trust account in the security database for this computer. The name of the account referenced in the security database is AccountName.
This authentication problem appears to be random and can affect more than one BDC. To resolve the problem, install NT 4.0 Service Pack 4 (SP4) or later. The problem also occurs with NT Server 4.0, Terminal Server Edition (WTS). Installing SP4 for WTS resolves the problem.
Limiting Domain Controller Trust Traffic
The PDCs of two domains with a trust relationship have the potential to generate traffic between themselves every 15 minutes. The 15-minute interval is the default value for the ScavengeInterval Registry parameter. NT uses ScavengeInterval to determine when Netlogon performs miscellaneous work on a PDC and BDCs. This work includes locating a domain controller, attempting to add a DomainName \[B1\]NETBIOS name to a BDC, discovering whether a secure channel has been idle too long, or deciding whether a password on a secure channel must change. (NT 4.0 and NT 3.x domain controllers automatically change passwords every 7 days, and Netlogon scans for this change by default every 15 minutes.)
You can tune ScavengeInterval to optimize traffic flow because none of the foregoing operations is crucial. For example, if you're using a leased line for which you're charged by the amount of network traffic your network produces, you'll find that tuning ScavengeInterval is beneficial. In addition, tuning ScavengeInterval will let you reduce traffic that trust-relationship polling of domain controllers over a WAN generates.
If ScavengeInterval doesn't exist on a PDC, you need to use regedt32 to modify the appropriate Registry subkey. Take the following steps to create ScavengeInterval and adjust the scavenge interval default setting:
- Select the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\Netlogon\Parameters Registry Key.
- Add ScavengeInterval for the value name.
- Choose REG_DWORD for the data type.
- Adjust the decimal data value.
The default decimal data value is 900 seconds, or 15 minutes. The data value ranges from 60 to 172,800 seconds (i.e., 1 minute to 48 hours). You need to determine the optimum value for your domain.