Active Directory (AD) supports two distinct types of replication: intrasite, which covers all domain controllers within a site, and intersite, which covers replication between different sites. Intrasite replication is managed pretty much automatically by the AD Knowledge Consistency Checker (KCC). The KCC is responsible for ensuring that each domain controller within the site participates in replication in a timely fashion. The KCC also plays a role in generating the replication topology between sites. Although the KCC generally works flawlessly, it's a good idea to understand exactly how it works so that you can troubleshoot it when problems arise.
The KCC is physically implemented as a component of a service that runs on all domain controllers.
One of the KCC's most important tasks is to generate the intrasite replication topology, a sort of logical map that decides which domain controllers will replicate with each other. AD does not use a fully enmeshed replication topology in which each domain controller in a site replicates with every other domain controller in the site; such a topology would generate an unacceptably high level of replication traffic, especially in sites with a large number of domain controllers. Instead, the KCC tries to generate a topology that minimizes latency and network utilization while providing fault tolerance.
Latency refers to the amount of time it takes a change to replicate from the domain controller on which the change was made to all other domain controllers. A high degree of latency can create inconsistent results for users and can even be the source of potential security problems, so reducing latency is a big priority for the KCC.
By default, the KCC tries to ensure that each domain controller in the site has at least two replication partners. That way, if one becomes unavailable, replication can still continue. Additionally, the KCC tries to ensure that no single domain controller is more than three partners away from any other domain controller. This configuration reduces latency because any change to AD would require no more than three replication cycles. Generally, the KCC creates a bidirectional ring topology, as Figure 16.1 shows. In this pattern, each domain controller replicates with the domain controllers to its left and right (two partners apiece).
Figure 16.1: Bidirectional ring topology.
In a site with many domain controllers, a ring topology can quickly violate the no-more-thanthree-hops rule, so the KCC will generate shortcuts across the ring to reduce the number of hops between domain controllers. Figure 16.2 shows a ring topology with a larger number of domain controllers in which shortcuts are used to reduce hops. Note that some domain controllers are therefore required to carry more than the minimum two connections. However, to reduce domain controller overhead, no domain controller is required to have more than three replication partners.
Server5, which would have been four hops away from Server1 in a bidirectional ring without shortcuts, is reduced to a single hop by the shortcut. Note that the two-way arrows indicate two individual connection objects apiece; I've simplified them into a single arrow for this drawing.
Figure 16.2: Bidirectional ring topology with shortcuts.
As I've mentioned, this topology is automatically generated by the KCC. Actually, the KCC builds several different, independent replication topologies: One for each AD partition. This setup results in a schema replication topology, a configuration topology, a domain topology, and an application topology. Although the various topologies will often be similar, they might not be identical. Note, however, that the KCC never creates duplicate connection objects.
For example, suppose the KCC generates an identical topology for both the schema and configuration partitions. Only one entire site of connection objects will be created for both topologies. If the KCC generates a different topology for the domain partition, then it might create different connection objects. The KCC will never, for example, create two objects from Server1 to Server2; if different topologies require such a connection, they will all share a single connection.
You can't directly affect the KCC's operation. When it creates its replication topology, the result is a set of replication objects. The security on these objects sets the KCC itself as the owner, although members of the Domain Administrators group have permission to modify those objects. As an administrator, you can create your own intrasite replication objects. The KCC won't have the ability to modify any objects you create. (For information about AD connection objects, see the sidebar "AD Connection Objects.")
Keep in mind that each connection object represents a one-way, inbound replication path from the domain controller on which the change occurred to the local domain controller. AD replication is pullbased, meaning domain controllers request changes from other domain controllers. This concept is important for security: domain controllers do not accept pushed changes, meaning there's no way for an intruder to send fake replication data around your network and mess up your domain.
When the KCC wants two domain controllers to replicate with each other, it must create two connection objects with each object representing one direction of replication traffic.
You can use the Active Directory Sites and Services console to see the connection objects that exist for each domain controller. Open the console, and expand Sites. Then select the appropriate site (such as Default-First-Site), and expand Servers. Locate the server you're interested in, expand it, and select NTDS Settings. You'll see the connection objects that control replication to other servers within the site. You'll also see the intrasite replication schedule, which is about every 5 minutes by default. Connection objects created by the KCC will have a name of <automatically generated>; connection objects you create will have a descriptive name that you assign.
How does the KCC have permission to perform its job? The AD partitions each grant special permissions to both the Enterprise Domain Controllers group and the built-in Administrators group:
When the KCC is automatically generating connections, why should you bother? There are a number of reasons. Perhaps the most common reason is to reduce latency. You might, for example, want to have no more than two hops between any two domain controllers to decrease replication latency. You can accomplish this setup by manually creating connection objects. To do so
Keep in mind a couple of things regarding manually created connections:
Be very careful when creating manual connections. In fact, unless you plan to regularly monitor your connections, don't create any at all. Manual connection objects can easily create additional domain controller overhead by requiring domain controllers to maintain connections that aren't as efficient. Also, the more connections you create, the fewer the KCC will create (remember that it tries to minimize the number of connections maintained by each domain controller), which can result in an inefficient replication topology.
You can use the Repadmin.exe command-line tool to manipulate some of the KCC's functionality and to check its performance. For example, executing
repadmin /kcc servername
will force the KCC on the designated server to run and immediately begin recalculating the replication topology. As Figure 16.3 shows, you can omit the server name to run the KCC on the local domain controller.
Figure 16.3: Forcing the KCC to run.
Or you can run
repadmin /showreps servername
to show the replication topology as viewed from the designated server. The output of this command displays both inbound and outbound neighbors, or replication partners.
Inbound neighbors are ones from which the reporting domain controller will request and pull changes. Outbound neighbors are those that will receive change notifications from the reporting domain controller.
Manually drawing the replication topology based on this information can be complex. The Windows Support Tools includes Replmon, a graphical tool that can draw a graphical picture of the replication topology to help you more easily spot topology issues.
The KCC also generates the topology for intersite replication. However, it cannot do so completely on its own. Instead, it must rely on information that you supply about the intersite networking infrastructure (generally WAN links). You supply this information by accurately configuring AD sites to represent your LANs, and by creating site links that represent the WAN links between LANs.
The KCC on a single domain in each site is designated as the intersite topology generator and is responsible for managing that site's connections to other sites. The generator uses a fancy algorithm—called a least-cost spanning tree algorithm—to calculate the most efficient way to replicate information across sites.
By default, the intersite topology generator is the first domain controller in the site. However, this can change if that domain controller becomes unavailable for more than an hour; you can check Active Directory Sites and Services to see which server holds the role. You cannot, however, designate a server to hold this role. If the existing generator becomes unavailable, the domain controller with the next-highest AD GUID will become the new generator.
The KCC has to consider several factors when generating the intersite topology. These factors include the availability of site links, which tells the KCC which sites it can reach and which sites can be used to reach other sites. It must also consider the network protocols available on site links, which will usually include IP and/or SMTP. The KCC must also consider the cost of site links. In the event that multiple possible paths are available to a site, the KCC will choose the least expensive option. You configure the cost of site links when you create them.
For intersite replication, the KCC chooses a single domain controller as the bridgehead for each domain in the site. The bridgehead is responsible for all replication traffic to a particular site. If the bridgehead fails, the KCC will choose another from the same domain.
Remember that only the KCC on the intersite topology generator deals with intersite replication topologies.
You can also manually designate bridgehead servers by manually creating connection objects between two domain controllers in the same domain but in different sites. The KCC will detect the existing connection object when it generates the intersite topology and use the manually created connection rather than creating a new connection. Manually designating bridgeheads ensures that you can select a server that can support the additional traffic that intersite replication entails. You can also ensure that, if desired, a single domain controller acts as the bridgehead for its domain to all other sites, providing a consolidated bridgehead (and putting all of your replication eggs in one basket, so to speak). If your designated bridgehead fails, the KCC will automatically select a new bridgehead for each site connection.
Finally, as Figure 16.4 shows, you can designate particular domain controllers as preferred bridgeheads. Simply right-click the server in Active Directory Sites and Services, and indicate which transport protocols the domain controller is preferred for. The KCC will always choose a preferred server as the bridgehead if one is available.
Figure 16.4: Making a domain controller the preferred bridgehead for IP connections.
The KCC is configured to automatically recheck the network topology every so often. Doing so allows the KCC to reconfigure the topology to respond to changing network conditions, such as new domain controllers, failed domain controllers, failed WAN links, new site link configurations, and so forth.