Active Directory 2008 : Configuring Replication (part 1) - Connection Objects,The Knowledge Consistency Checker, Intrasite Replication

1. Understanding Active Directory Replication

In previous lessons, you learned how to place domain controllers in network locations and how to represent those locations with site and subnet objects. You also learned about the replication of directory partitions (Schema, Configuration, and Domain), the partial attribute set (GC), and application partitions. The most important thing to remember as you learn about Active Directory replication is that it is designed so that, in the end, each replica on a domain controller is consistent with the replicas of that partition hosted on other domain controllers. It is not likely that all domain controllers will have exactly the same information in their replicas at any one moment in time because changes are constantly being made to the directory. However, Active Directory replication ensures that all changes to a partition are transferred to all replicas of the partition. Active Directory replication balances accuracy (or integrity) and consistency (called convergence) with performance (keeping replication traffic to a reasonable level). This balancing act is described as loose coupling.

Key features of Active Directory replication are:

• Multimaster replication Any domain controller can initiate and commit a change to Active Directory.

• Pull replication A domain controller requests, or “pulls,” changes from other domain controllers. As you learn more about replication, it may become easy to forget this, because a DC notifies its replication partners that it has changes to the directory, or a DC can poll its partners to see if they have changes to the directory. But the changes themselves are, in the end, requested or “pulled” by the target DC.

• Store-and-forward replication A domain controller can pull changes from one partner, and then make those changes available to another partner. For example, domain controller B can pull changes initiated by domain controller A. Then domain controller C can pull the changes from domain controller B.

• Partitioning of the data store Domain controllers in a domain host only the domain naming context for their domain, which helps keep replication to a minimum, particularly in multidomain forests. Other data, including application directory partitions and the partial attribute set (GC), are not replicated to every domain controller in the forest, by default.

• Automatic generation of an efficient and robust replication topology By default, Active Directory configures an effective, two-way replication topology so that the loss of any one domain controller does not impede replication. This topology is automatically updated as domain controllers are added, removed, or moved between sites.

• Attribute-level replication When an attribute of an object is modified, only that attribute, and minimal metadata that describes that attribute, is replicated. The entire object is not replicated except when the object is created.

• Distinct control of intrasite replication (within a single site) and intersite replication (between sites) Replication can be distinctly controlled in both of these situations.

• Collision detection and management It is possible, although rare, for an attribute to be modified on two different domain controllers during a single replication window. In such an event, the two changes must be reconciled. Active Directory has resolution algorithms that satisfy almost every such situation.

It is easier to understand Active Directory replication by examining each of its components. The following sections examine the components of Active Directory replication.

2. Connection Objects

A domain controller replicates changes from another domain controller because of AD DS connection objects, also simply called connection objects. Connection objects appear in the administrative tools in the Active Directory Sites And Services snap-in as objects contained in the NTDS Settings container of a domain controller’s server object. Figure 1 shows an example: A connection object in SERVER02 configures replication from SERVER01 to SERVER02. A connection object represents a replication path from one domain controller to another.

Connection objects are one-way, representing inbound-only replication. Replication in Active Directory is always a pull technology. In the domain illustrated in Figure 1, SERVER02 pulls changes from SERVER01. SERVER02 is considered, in this example, a downstream replication partner of SERVER01. SERVER01 is the upstream partner. Changes from SERVER01 flow to SERVER02.

Note

FORCE REPLICATION

You can force replication between two domain controllers by right-clicking the connection object and clicking Replicate Now. Remember that replication is inbound only, so to replicate both domain controllers, you must replicate the inbound connection object of both domain controllers.

Figure 1. A connection object in the Active Directory Sites And Services snap-in

3. The Knowledge Consistency Checker

The replication paths built between domain controllers by connection objects create the replication topology for the forest. Luckily, you do not have to create the replication topology manually. By default, Active Directory creates a topology that ensures effective replication. The topology is two-way so that if any one domain controller fails, replication continues uninterrupted. The topology also ensures that there are no more than three hops between any two domain controllers.

You’ll notice in Figure 1 that the connection object indicates it was automatically generated. On each domain controller, a component of Active Directory called the Knowledge Consistency Checker (KCC) helps generate and optimize the replication automatically between domain controllers within a site. The KCC evaluates the domain controllers in a site and creates connection objects to build the two-way, three-hop topology described earlier. If a domain controller is added to or removed from the site, or if a domain controller is not responsive, the KCC rearranges the topology dynamically, adding and deleting connection objects to rebuild an effective replication topology.

You can manually create connection objects to specify replication paths that should persist. Manually created connection objects are not deleted by the KCC.

To create a connection object:

1. In Active Directory Sites And Services, locate the server object for the downstream replication partner—the DC that will receive changes from a source DC. In the console tree, right-click the NTDS Settings container in the server object and click New Active Directory Domain Services Connection.

2. In the Find Active Directory Domain Controllers dialog box, select the upstream replication partner, and then click OK.

3. Give the new connection object a name, and then click OK.

4. Open the properties of the connection object; use the Description field to indicate the purpose of any manually created connection object.

Within a site, there are very few scenarios that would require creating a connection object. It is recommended that you select domain controllers as standby operations masters to be used in the event that the operations master role must be transferred or seized. A standby operations master should be a direct replication partner with the current operations master. Thus, if a domain controller named DC01 is the RID master, and DC02 is the system that will take the RID master role if DC01 is taken offline, then a connection object should be created in DC02 so that it replicates directly from DC01.

4. Intrasite Replication

After connection objects between the domain controllers in a site have been established—either automatically by the KCC or manually—replication can take place. Intrasite replication involves the replication of changes within a single site.

Notification

Consider the site shown in Figure 1. When SERVER01 makes a change to a partition, it queues the change for replication to its partners. SERVER01 waits 15 seconds, by default, to notify its first replication partner, SERVER02, of the change. Notification is the process by which an upstream partner informs its downstream partners that a change is available. SERVER01 waits three seconds, by default, between notifications to additional partners. These delays, called the initial notification delay and the subsequent notification delay, are designed to stagger network traffic caused by intrasite replication.

Upon receiving the notification, the downstream partner, SERVER02, requests the changes from SERVER01, and the directory replication agent (DRA) performs the transfer of the attribute from SERVER01 to SERVER02. In this example, SERVER01 made the initial change to Active Directory. It is the originating domain controller, and the change it made is the originating change. When SERVER02 receives the change from SERVER01, it makes the change to its directory. The change is not called a replicated change, but it is a change nonetheless. SERVER02 queues the change for replication to its own downstream partners.

Assume SERVER03 is a downstream replication partner of SERVER02. After 15 seconds, SERVER02 notifies SERVER03 that it has a change. SERVER03 makes the replicated change to its directory and then notifies its downstream partners. The change has made two hops, from SERVER01 to SERVER02 and from SERVER02 to SERVER03. The replication topology ensures that there are no more than three hops before all domain controllers in the site have received the change. At approximately 15 seconds per hop, that means the change fully replicates in the site within one minute.

Replication mechanisms ensure that changes are dampened, so that a change is not replicated to a domain controller that already received the change from another replication partner. You can learn more about the internals of AD DS replication in the Windows Server 2008 Active Directory Resource Kit.

Polling

It is possible that SERVER01 might not make any changes to the partitions it hosts for quite a long time, particularly during off hours. In this case, SERVER02, its downstream replication partner, will not receive notifications from SERVER01.

However, it is also possible that SERVER01 might be offline, which would also prevent it from sending notifications to SERVER02 and would break the two-way, three-hop replication topology that was generated by the KCC. The replication topology must be self-healing, so it’s important for SERVER02 to determine whether its upstream partner is offline, or whether it is online and simply does not have any changes.

This is achieved through a process called polling. The downstream replication partner contacting the upstream replication partner with a query as to whether any changes are queued for replication. By default, the polling interval for intrasite replication is once per hour. It is possible, although not recommended, to configure the polling frequency from the properties of a connection object by clicking Change Schedule.

If an upstream partner fails to respond to repeated polling queries, the downstream partner assumes that its upstream partner is offline, so it triggers the KCC to check the replication topology. If the KCC determines that the upstream server is indeed offline, the site’s replication topology is rebuilt to accommodate the change, to ensure that a two-way, three-hop topology is maintained.