As most of us know, Windows NT uses the PDC to synchronize the directory database to each of the BDCs in a domain. NT calls its domains single-master domains because the OS performs synchronization, or replication, in one direction—from the PDC to each of the BDCs. Windows 2000 (Win2K) uses a significantly different synchronization process based on a multiple-master scheme. Win2K lets any domain controller receive Active Directory (AD) changes, then replicates those changes to all other domain controllers. (For definitions of some key Win2K AD terms, see the sidebar "Helpful Directory Terms," page 112.) If you're considering upgrading from NT to Win2K, you need to understand these synchronization differences. Let's review NT 4.0's directory synchronization process and contrast that process with Win2K's new and improved scheme.
NT 4.0 Synchronization
Full synchronization in NT 4.0 occurs when the PDC sends a copy of the entire directory database to a BDC. Full synchronization of the directory database's complete contents occurs under two conditions: when the system deletes changes from the change log before replication can take place, and when you add a new BDC to the domain. Because initial synchronization can be time-consuming, perform BDC initial synchronization on site or over a high-speed link. The most efficient synchronization method for sites that have low-speed or RAS access is to set up the BDC on the same site as the PDC, then ship the BDC to its intended location.
After full synchronization, partial synchronization takes place automatically from the PDC to the BDCs, with a default synchronization interval of 5 minutes. In other words, the directory database for any given BDC will be out of date for no longer than 5 minutes. The directory database is out of synchronization when, for example, the system makes a change to the master copy of the directory database on the PDC and hasn't yet replicated that change to the other BDCs in the domain. If you make many changes to the master copy of the directory database and you want the changes to take effect immediately, you can use Server Manager to perform a manual partial synchronization of the entire domain from the PDC or with a specific BDC. You perform the partial synchronization from Server Manager by highlighting the BDC you need to synchronize, then selecting Synchronize with Primary Domain Controller from the Computer menu.
NT 4.0 uses timestamps to propagate changes, so keeping the clocks on all directory servers synchronized is important. When servers aren't thus synchronized, you can potentially lose updates to the BDCs' directory databases.
A few Registry values in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\Netlogon\Parameters subkey are important to the synchronization process and deserve a closer look. The first of these values, ReplicationGovernor, is a Netlogon parameter that controls the percentage of network bandwidth the system can use during directory synchronization. If ReplicationGovernor isn't already in the Netlogon\Parameters subkey, you need to add it with a REG_DWORD data type. ReplicationGovernor's default value is 100, which means that Netlogon will use 100 percent (up to 128KB) of the network bandwidth during transmission. Using 100 percent of network bandwidth, of course, can create problems for users who need bandwidth, especially in a WAN environment. You might find it more practical to set ReplicationGovernor's value to 50, which will cause Netlogon to buffer only 50 percent of network bandwidth. The value range is from 0 to 100, but you should never set the percentage lower than 25 because such a low value can result in synchronization never completing. You must set the value individually on each BDC in the domain you want to adjust.
If you make many changes on your network daily, you might need synchronization to occur more frequently than the at default 5-minute interval. Or perhaps you're running a network in which changes occur infrequently and don't need to synchronize as often. The Pulse Registry value specifies the time interval, in seconds, at which the PDC transmits signals to the BDCs that trigger the synchronization requests to the PDC. If the Pulse value isn't already in the Netlogon\Parameters subkey, you need to add it to the PDC with a REG_DWORD data type. The default value is 300 seconds, or 5 minutes. The value range is from 60 seconds (1 minute) to 172,800 seconds (48 hours).
Although partial synchronization occurs by default, full synchronization can occur when the system overwrites entries stored in the change log on the PDC before those entries replicate to the BDC. The change log stores a list of changes the system makes to the master copy of the directory database. The system maintains the log on disk at \winnt\netlogon.chg and in a buffer on the PDC. When a BDC requests a directory synchronization from the PDC, the PDC sends all changes added since the last synchronization, from the change log to the requesting BDC. Because the change log is a circular file, when it becomes full, the system overwrites the oldest entries. As a result, if an entry that the PDC hasn't sent to a requesting BDC is overwritten, the PDC will perform a full synchronization with that BDC the next time the BDC requests synchronization. For example, if a RAS-connected BDC performs a synchronization by dialing in to the PDC nightly and logs more than 2000 changes to the directory database since the last synchronization, the PDC will perform a full synchronization on the remote BDC. Synchronization performed this way is time-consuming and can be expensive, especially if a WAN link is involved. Avoid it whenever possible.
If you notice that full synchronizations between your PDC and BDCs are occurring frequently, consider increasing the size of the change log on the PDC. A default 64KB change log can hold about 2000 change entries, each of which is typically 32 bytes. You can adjust the change log's size by editing the ChangeLogSize value in the Netlogon\Parameters subkey on the PDC. If the value doesn't exist, you need to add it with a REG_DWORD data type.
The ChangeLogSize value specifies the size of the change log in bytes; the value range is from 64KB to 4MB. Because the setting for this value doesn't degrade system performance, you can go ahead and set it at 4MB (i.e., 0x4000000). Doing so will usually give you a log large enough to accommodate a list of all changes made between synchronizations, so you can avoid full replication even with a large number of changes. If you change the ChangeLogSize value on the PDC, you need to also change it on all BDCs to ensure that, if you need to promote a BDC to a PDC, the ChangeLogSize value remains the same. After changing the value, you need to reboot the machine to put the new setting into effect.
Sometimes you might want to force a full synchronization—for example, if one of your domain controllers has been offline for some time. You can manually perform a full synchronization in two ways. First, you can type
net accounts /sync
at a BDC's command prompt. Second, you can run the Nltest utility in the Microsoft Windows NT Server 4.0 Resource Kit. You run this command from the PDC's command prompt. At the prompt, type
nltest /sync /server:<BDC name>
What's New in Windows 2000 Synchronization?
In contrast to NT, Win2K employs a multiple-master scheme for synchronization within domains. This new process means that every domain controller can receive AD changes, and those changes replicate to all other domain controllers.
The AD replication system doesn't depend on timestamping for synchronization but instead uses update sequence numbers (USNs). The USN is a 64-bit number that each AD server maintains. Any time the system writes a change into an object in the directory, Win2K assigns a new USN to the object. Each AD server stores these changes in a table with the USN, which increments any time the system writes a change to an object. Each AD server also uses this table to store a unique signature for the machine that wrote the change and to store the USNs it receives from replication partners.
When a replication partner notifies a server that replication is required, the replication partner requests all changes with USNs greater than the last value received. The server searches its directory for each object whose USNs match what the partner machine requested.
When two domain controllers receive an update of the same attribute of the same object at the same time, a collision occurs. In such a case, the last writer wins. An algorithm determines last-writer status by checking the attribute version number, attribute timestamp, and globally unique IDs (GUIDs) of the domain controllers that performed the write operation. When necessary, the algorithm uses the timestamps as a tiebreaker.
Intrasite replication. Replication between domain controllers in the same domain (i.e., intrasite replication) tries to complete as quickly as possible with the fewest CPU cycles possible. The system assumes that plenty of bandwidth is available to accomplish this task. (Microsoft's recommended topology for efficient replication is a 10Mbps Ethernet or comparable network.) Limiting replication to the fewest possible CPU cycles frees domain controllers for other tasks that occur within the domain, such as client logons. Because data compression of the changes to the database would cause an additional CPU load, data compression isn't available for intrasite replication. Intrasite replication always uses remote procedure call (RPC) over TCP/IP.
To avoid unnecessary network traffic, Win2K intrasite replication introduces a change-notification mechanism that replaces NT's method of polling replication partners for updates. When a change occurs in its directory database, a domain controller waits for the default 5-minute interval, accepts more changes within this period, then notifies its replication partners of the changes. If no changes occur on a domain controller's directory database within a default 6-hour period, the domain controller initiates a replication sequence with its replication partners to ensure accuracy. Security-sensitive attribute changes—changes in domain trust passwords, lockouts of user accounts, and changes in domain controller roles—replicate immediately.
Intersite replication. Win2K replication in a WAN (i.e., intersite replication) assumes the WAN is connected by slow links and thus minimizes traffic rather than CPU cycles. The system compresses data to 10 to 15 percent of its original volume before sending the data. Intersite replication doesn't use the notification process that intrasite replication uses; instead, administrators can use Administrative Tools, Active Directory Sites and Services to schedule intersite replication on a per-site basis. To set the intersite replication schedule, right-click the site link whose replication frequency you need to set, then choose Properties from the pop-up menu. In the Replicate every field, enter the number of minutes you want to set between replications. Screen 1 shows an example of the Properties dialog box. The system processes the Replicate every value to the nearest multiple of 15, from 15 minutes to 10,080 minutes (1 week).
Two transports are available for intersite replication: synchronous transport via RPC over TCP/IP, and asynchronous transport via SMTP. SMTP uses the Collaboration Data Objects (CDO) interface and the SMTP component in Microsoft Internet Information Server (IIS), which Windows 2000 Server (Win2K Server) uses.
Intersite RPC-based replication supports data compression, and you can use it for any type of replication, including intradomain, configuration information, or Global Catalog (GC) information. Intersite SMTP transport has some restrictions. For example, SMTP can't replicate between domain controllers that belong to the same domain (intradomain).
Two considerations exist for choosing between the intersite synchronous and asynchronous transports. First, if reduced network traffic is a priority and the connection between domain controllers is reliable, use the RPC-over-TCP/IP replication connection. Second, if domain controllers have no direct network connection or the network connection isn't always reliable, the SMTP replication connection is best. Be aware that you can use SMTP only for schema, configuration, and intersite replication. You can't use it for replication between two domain controllers in the same domain.
Windows 2000 Operations Masters
Some Win2K synchronization operations aren't multiple-master operations and must occur at only one place and time. Specially designated domain controllers—operations masters—manage these operations. An AD forest has five operations master roles.
Infrastructure master. Certain types of infrastructure changes, such as moving or deleting objects, must occur on one domain controller, which Win2K designates the infrastructure master. When you rename or move a member of a group, the infrastructure master of the group's Win2K domain is responsible for updating the group in its database so that the domain knows the new name or location of the member. The infrastructure master then uses multiple-master replication to deliver the update to the other domain controllers. Only one domain controller can act as the infrastructure master in each domain.
Domain naming master. One domain controller, the domain naming master, controls domain removal and addition in the AD forest. The domain naming master ensures that a new domain name is unique. The forest can contain only one domain naming master.
Schema master. Directory schema changes are single-master operations that the schema master domain controller performs. The schema master controls all modifications and updates to the schema. The schema master replicates a copy of the schema to all domain controllers in the forest. Using one domain controller to handle all schema changes ensures consistency and data integrity throughout the forest. Only one schema master can exist in the forest.
PDC emulator. When you migrate from an NT 4.0 or 3.51 domain, the former PDC is the first domain controller that you upgrade to Win2K. This new Win2K domain controller retains the role of PDC to maintain compatibility with NT 4.0 and 3.51 servers that are still operating as BDCs in the NT domain. These BDCs perceive the Win2K domain controller as the PDC and replicate from it. Win2K calls the first domain controller the PDC emulator. Only one PDC emulator can exist per Win2K domain.
The PDC emulator in a fully upgraded Win2K domain retains some functionality. For example, other domain controllers in the Win2K domain replicate password changes to the PDC emulator. If an authentication request contains an invalid password, the domain controller passes the authentication request to the PDC emulator before failing the request, in case the PDC emulator has received a password change.
Relative ID master. Win2K assigns Relative Identifiers (RIDs) whenever a domain controller creates a computer, user, or group object. A RID is a unique SID that consists of the domain's SID plus a unique RID, which the relative ID master assigns. The relative ID master allocates RID sequences to each domain controller in its domain. You must initiate moving an object between domains on the relative ID master of the domain that contains the object you need to move. Only one relative ID master can exist in each domain in the AD forest.
You can transfer the operations master role for the domain naming master with the Operations Master feature in Administrative Tools, Active Directory Domains and Trusts. Screen 2 shows the Change Operations Master dialog box, which you use to change the domain naming master to another computer. To transfer the schema master role for a domain controller, you must use the Active Directory Schema Manager snap-in, which is part of the Microsoft Windows 2000 Resource Kit. You can transfer operations master roles for the infrastructure master, PDC emulator, and relative ID master with the Operations Master feature in Administrative Tools, Active Directory Users and Computers. Screen 3 shows the Operations Master dialog box.
When you create your first Win2K domain by installing its first domain controller, the system assigns all single-master operations roles to that domain controller. Thereafter, when you create a new child domain or a root domain of a new tree in an existing forest, the system assigns to the first domain controller in the new domain the roles of infrastructure master, PDC emulator, and relative ID master. The domain naming master and schema master roles remain with the first domain created in the forest because only one of each can exist in the entire forest. If you have a small network with only one domain and one domain controller, that domain controller will manage all five operations master roles.
Mastering the New Process
With Win2K's revamped synchronization process, you no longer need to depend on one server to perform directory database synchronization. Win2K's multiple-master scheme propagates changes to all domain controllers in a timely manner—even if one or more domain controllers aren't available at a given time. With little effort, you'll master this new process and experience firsthand Win2K's significant improvements in AD replication.
