6 Essential Tools for Troubleshooting AD Replication

Ahead of the pack, your company has already deployed Windows 2000 and Active Directory (AD). Everything worked perfectly for a while, but you're beginning to realize that Win2K doesn't perform exactly as Microsoft promised it would. Many administrators are unprepared to troubleshoot problems that arise when good directories go bad. Unfortunately, AD replication is one of the least understood functionalities in Win2K. Now's the time to develop a better understanding of replication's inner workings and discover the troubleshooting tools that are available to you.

Replication Overview
AD is a database. By default, each domain controller (DC) stores a copy of this database as ntds.dit in its \winnt\ntds folder. The database is logically divided into three directory partitions, or naming contexts (NCs)—the Schema NC, the Configuration NC, and the Domain NC. All DCs in the forest contain the same Schema NC and Configuration NC because this information is defined forestwide. Each DC in an AD domain holds the same copy of the domain's Domain NC. If the DC is designated as a Global Catalog (GC) server, then that DC also holds a partial copy of every other domain's Domain NC. This partial copy includes all the objects from the respective domains, but only a subset of the attributes.

Replication is the mechanism that AD uses to synchronize all this information across all the DCs in the domain or forest that hold the information. AD uses the Knowledge Consistency Checker (KCC), sites, site links, and connection objects to accomplish this replication.

The KCC, a built-in process that runs on all DCs, creates the forest's replication topology. You use sites to group well-connected DCs that are within close network proximity. Your network and your AD architects determine whether a DC is well connected. Many companies consider DCs connected at network speeds of 10Mbps bandwidth to be well connected. To create a site, you configure AD with your network's IP subnet addresses. If one or more subnets are well connected, you can group them into a site. Replication between DCs in one site is called intrasite replication. To establish an intrasite replication topology, the KCC automatically creates connection objects between the DCs in a site. Connection objects are one-way connectors that link DCs across a site. Each of these links—like a traffic lane—represents an in-bound connection from the source DC to the destination DC. Before two DCs in a site can replicate directory data between themselves, you must establish two separate connection objects.

If some of your DCs aren't well connected, you need to create multiple sites. Replication between separate sites is called intersite replication. Your AD administrator uses the Microsoft Management Console (MMC) Active Directory Sites and Services snap-in to create site links, which provide roadways between sites. After the AD administrator establishes these pathways, the KCC creates connection objects between the linked sites. Typically, not all DCs share the same information. (For example, DCs in separate domains might maintain different data.) Therefore, the KCC might need to establish multiple connection objects to ensure that each NC replicates completely throughout the enterprise. In Figure 1, which shows an example of intersite connection objects, Site A and Site B are connected by a manually created site link. In this example, the KCC has created two one-way in-bound connection objects to replicate the three NCs between two DCs from the same domain.

The bridgehead server is another component of the replication topology. If you've worked with Microsoft Exchange Server, you're familiar with this server role. To increase the efficiency of replication, the KCC doesn't create individual connection objects between all the DCs in one site with all the DCs in another site. Instead, the KCC uses a store-and-forward mechanism that replicates information between two bridgehead servers—one in each site. The bridgehead server then uses intrasite replication to replicate the information to the rest of the DCs in its site. For more information about bridgehead servers, see the sidebar "Bridgehead Servers," page 48.

What Gets Replicated?
Considering its ability to make changes to a DC's directory objects, AD needs an efficient way to determine which objects have changed and whether to replicate those changes to the DC's replication partners. AD uses update sequence numbers (USNs) to track when changes occur in the directory. USNs are 64-bit counters that AD assigns locally per DC. When AD, users, administrators, or applications update an attribute, the DC looks at the attribute's current USN value for the directory, increments it, and assigns the new value to the updated object as its local USN.

Within the AD replication topology, replication partners use a high-watermark value to keep track of the most recent changes they receive from source DCs. When a destination DC requests changes from the source DC, the destination DC sends its high-watermark value to the source DC as a benchmark for sending back changes. As a result, the source DC will send only directory-object changes that have a value higher than the high-watermark value, thereby eliminating any unnecessary flow of replication data across the wire.

The up-to-dateness vector works in conjunction with the high-watermark value to minimize the amount of replicated data. Whereas the high-watermark value concerns objects, the up-to-dateness vector concerns attributes. Otherwise, the two values have similar functionality. During an exchange of replication data, a destination DC sends its up-to-dateness vector to the source DC, which uses this value to determine whether the destination DC has an up-to-date value for a particular attribute. If the value is up-to-date, the source DC filters the value from the data it sends to the requesting DC.