Active Directory is very effective at replicating between domain controllers. Replication paths are built between DCs by connection objects. These paths create the replication topology of the entire forest. Thankfully, no one has to make these paths manually. Active Directory will attempt to find the most effective topology for replication. It operates two ways so that if one Domain Controller will fail, replication will still continue. It is standard practice to have no more than three hops between any domain controller.

When you look in Active Directory Sites and Services, connection objects will automatically appear when there is replication between domain controllers. The connections may be found by navigating to Sites > The site name > Servers > the server name > NTDS Settings. When NTDS settings is highlighted, the connection object in the right side window pane will often will say that it is automatically generated. On each domain controller, a component of Active Directory called the Knowledge Consistency Checker (KCC) optimizes and generates replication within a site. The KCC will detect a DC that is not functional and redesign the topology automatically by adding/deleting objects.

Connection objects may be manually created and will not be deleted by the Knowledge Consistency Checker. Connection objects are created between and upstream and downstream partner. The downstream partner will receive updates from the upstream partner. To create a manual connection object in Active Directory Sites and Services, right click the NTDS settings container of the downstream server and choose “New Active Directory Domain Services Connection.” A box labeled “Find Active Directory Domain Controllers” will appear. Select the upstream replication partner and then click OK. Going to the properties of the connection will allow an entry into the description field.

There are very few times that manual connections should be made. One such example is between operation masters. The standby operation master should have a manual connection to the current operation master. If the current operation master should fail then the standby operation master will be able to transfer or seize the operation. If DC1 is the Schema Master and DC2 is the standby, DC2 should replicate directly from DC1.

If changes are made it is the responsibility of the upstream partner to notify its downstream partner. DC1 will make a change in its partition it will notify DC2 of the change. It will wait 15 seconds before it notifies DC2 of the change. DC1 will wait three seconds and notify its next downstream partner of the change. DC2 will receive its change, and in 15 seconds, notifies its first downstream partner, DC3, of the change. Three second seconds later, DC2 will notify its next downstream partner. After receiving the change, DC3 will wait 15 seconds after receiving the change and begin notifying its downstream partners (DC4). It will wait three seconds between notifying its downstream partners. DC4 will not have downstream partners since the change has made three hops, DC1 to DC2, DC2 to DC3, and DC3 to DC4. The Knowledge Consistency Checker strives that no two domain controllers should be more than three hops apart. This process of waiting 15 seconds between hops means that all updates should take less than a minute to update.

There is always the possibility, an upstream partner will not make an changes or possibly fail. If there are no notifications sent from the upstream partner to the downstream partner, the downstream partner will poll the upstream partner. This means that the downstream partner will query its upstream partner. Should the query fail, the downstream partner will launch the KCC to check the replication topology. The site’s replication topology will be rebuilt to accommodate the change.