How to Configure Windows Server 2016 Active Directory Replication

Active Directory replication is the process by which changes made on one Domain Controller are propagated to all other Domain Controllers in the domain and forest. Reliable replication is critical — without it, authentication failures, inconsistent policy application, and stale directory data can occur. Windows Server 2016 uses a multi-master replication model, meaning any writable DC can accept changes, which are then replicated outward to peers. This article covers how to configure, monitor, and troubleshoot AD replication.

How Replication Works

Active Directory divides the directory into naming contexts (also called partitions): the Domain partition, the Configuration partition, the Schema partition, and Application partitions (such as DNS zones). Each DC holds a full replica of the Domain, Configuration, and Schema partitions. The Knowledge Consistency Checker (KCC) runs on each DC every 15 minutes to automatically build and maintain the replication topology — a ring of connections called connection objects. Within a site, DCs replicate changes quickly (within seconds to a few minutes). Between sites, replication is governed by site links and their cost and schedule settings.

Viewing Replication Topology

Open Active Directory Sites and Services (dssite.msc) and expand a site’s server node, then expand NTDS Settings to see the automatically generated connection objects. Each connection object represents a replication path from one DC to another. You can also view the topology using repadmin:

repadmin /showconn
repadmin /showobjmeta DC01 "CN=Schema,CN=Configuration,DC=corp,DC=local"

Forcing Replication Between Domain Controllers

In normal operations you do not need to manually trigger replication. However, after making an urgent change such as disabling a compromised account, you may want to force immediate replication to all DCs. In Active Directory Sites and Services, right-click a connection object and select Replicate Now. To force replication from the command line:

repadmin /syncall /AdeP

This command replicates all naming contexts from all source DCs. The flags mean: A = all naming contexts, d = identify servers by distinguished name, e = include inter-site replication, P = push changes outward. To sync a specific naming context between specific DCs:

repadmin /replicate DC02 DC01 "DC=corp,DC=local"

Checking Replication Status

The repadmin tool is the primary utility for checking replication health. The replsummary command provides a high-level overview of replication success and failure across all DCs:

repadmin /replsummary

For detailed per-DC replication status including the last successful replication time and any errors:

repadmin /showrepl * /csv > C:replication_report.csv

To check for replication failures specifically:

repadmin /showrepl * /errorsonly

Running DCDiag Replication Tests

DCDiag is another essential tool for diagnosing replication issues. Run the replication-specific test against all DCs:

dcdiag /test:replications /v /e

The /e flag runs against all servers in the enterprise. Review the output for FAILED entries. Common replication errors include Access Denied (Kerberos or RPC issues), RPC Server Unavailable (firewall or network issues), and -2146893022 (target principal name incorrect, usually a time synchronization or SPN problem).

Configuring Replication Intervals

Intra-site replication occurs automatically via urgent replication notifications. Changes trigger notifications to replication partners within seconds. Inter-site replication is governed by site link schedules. To modify the intra-site notification delay (default 15 seconds for the initial notification, 3 seconds between partners):

# These are registry settings on the source DC
reg add "HKLMSYSTEMCurrentControlSetServicesNTDSParameters" /v "Replicator notify pause after modify (secs)" /t REG_DWORD /d 15 /f
reg add "HKLMSYSTEMCurrentControlSetServicesNTDSParameters" /v "Replicator notify pause between DSAs (secs)" /t REG_DWORD /d 3 /f

Managing Connection Objects

In most environments, the KCC manages connection objects automatically and manual intervention is not needed. However, you can create manual connection objects for specific replication paths — for instance, to ensure a particular DC always receives changes directly rather than through an intermediary. In Active Directory Sites and Services, right-click NTDS Settings under a server and select New Active Directory Domain Services Connection. Select the source DC. A manually created connection object will not be removed by the KCC.

Urgent Replication

Certain high-priority changes bypass the normal notification delay and replicate immediately (urgent replication). These include account lockout events, changes to the domain lockout policy, changes to the Local Security Authority secret on Domain Controllers, and changes to RID pool allocation. Understanding urgent replication helps administrators recognize why some changes propagate faster than others.

Tombstone Lifetime and Lingering Objects

When an object is deleted in Active Directory, it is converted to a tombstone and retained for the tombstone lifetime period (180 days by default in Windows Server 2016 domains). If a DC is offline for longer than the tombstone lifetime and then brought back online, it may introduce lingering objects — objects that have been deleted on other DCs but still exist on the restarted DC. Use repadmin to detect and remove lingering objects:

repadmin /removelingeringobjects DC01  "DC=corp,DC=local"

Time Synchronization and Replication

Active Directory Kerberos authentication requires all DCs to have clocks within 5 minutes of each other (by default). Time skew is a common cause of replication failures. The PDC Emulator is the authoritative time source for the domain. Ensure it is synchronized with an external NTP source:

w32tm /config /manualpeerlist:"pool.ntp.org" /syncfromflags:manual /reliable:yes /update
net stop w32tm && net start w32tm
w32tm /query /status

Best Practices

Monitor replication health daily using repadmin /replsummary or a monitoring platform with AD replication checks. Ensure at least two DCs exist in every site. Never take a DC offline for longer than half the tombstone lifetime. Keep all DCs patched and at the same OS functional level. Investigate and resolve any replication error promptly — errors left unresolved can cascade and lead to directory inconsistencies that are difficult to remediate.

Active Directory replication is foundational. Healthy replication means users can authenticate, Group Policies apply correctly, and DNS remains consistent. Building a routine of monitoring and responding to replication health is one of the most important habits of a Windows Server administrator.