What's New in Windows 2000 Directory Replication?

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.

   Previous  [1]  2  Next