Understanding Active Directory Replication

Active Directory replication is the mechanism by which changes made on one domain controller (DC) are propagated to all other domain controllers in the domain and forest. Every object and attribute in AD has an associated Update Sequence Number (USN) and originating write metadata. When you create a user, modify a password, or change a group membership, the originating DC increments the USN for that object and marks it for outbound replication. Partner DCs pull those changes based on replication schedules and topology managed by the KCC (Knowledge Consistency Checker).

When replication breaks down, the consequences are serious: stale passwords, logon failures, inconsistent group memberships, missed Group Policy updates, and eventually lingering objects or USN rollbacks that require manual intervention. This article walks through the full toolkit for diagnosing and resolving AD replication issues on Windows Server 2022.

Checking Replication Status with repadmin /showrepl

The repadmin tool is the primary command-line utility for AD replication diagnostics. Run it with elevated privileges on any domain controller. To show the inbound replication partners and the status of the most recent replication attempt for each naming context:

repadmin /showrepl

The output lists each naming context (Default Naming Context, Configuration, Schema, DNS zones) and, for each, the source DC and when the last replication occurred. Look for entries marked with “FAILED” or errors such as “The RPC server is unavailable” or “There is no such object on the server.” The error codes map to specific failure causes. Error 1722 (RPC Unavailable) indicates a network or firewall issue. Error 8606 (Insufficient attributes) often indicates an object has been deleted on a DC that cannot replicate the deletion. Error 8614 (AD replication cannot proceed because it has been stopped for too long) is the tombstone lifetime exceeded error.

To show replication status for all DCs in the domain from the current DC’s perspective:

repadmin /showrepl * /errorsonly

This limits output to only failed replication links, making it easy to identify which connections are broken without wading through successful ones.

Generating a Replication Summary

For a high-level view of replication health across all DCs in the forest, use:

repadmin /replsummary

This produces a table with one row per DC, showing the largest replication delta (how long since last successful replication), failure counts, and error codes. Any DC with a delta exceeding the replication interval for your site links, or a failure count above zero, requires investigation. In a healthy environment, replication deltas should be under 60 minutes for intra-site and under your configured inter-site schedule for inter-site links.

For detailed per-link analysis exportable to a spreadsheet:

repadmin /showrepl * /csv > C:replication-report.csv

Open the CSV in Excel and sort by “Number of Failures” to quickly identify the worst-performing replication links.

Running DCDiag Replication Tests

DCDiag runs a suite of diagnostic tests against domain controllers. The Replications test specifically checks AD replication:

dcdiag /test:Replications /v

The /v switch provides verbose output. DCDiag will report PASS or FAIL for each DC it tests. It catches issues such as replication failures, missing replication links, and DCs that have not replicated within the tombstone lifetime.

To run a full suite of tests against all DCs in the domain:

dcdiag /test:Replications /e /v > C:dcdiag-report.txt

The /e flag runs the test against all DCs in the enterprise. Additional useful DCDiag tests include:

dcdiag /test:Connectivity
dcdiag /test:DFSREvent
dcdiag /test:SysVolCheck
dcdiag /test:NetLogons

Key Event IDs for AD Replication Problems

The Directory Service event log on domain controllers records replication events. Key Event IDs to watch for:

Event ID 1311: The Knowledge Consistency Checker (KCC) could not form a complete spanning tree. This means the KCC cannot build a valid replication topology, typically because too many DCs are unreachable or disabled replication links exist. Check your site link configuration and ensure all DCs are online.

Event ID 1388: Another domain controller has attempted to replicate a deletion of an object that does not exist locally. This can indicate a lingering object situation and is often followed by Event ID 1988, which is the more serious notification that replication has been blocked due to lingering objects.

Event ID 2042: The last time replication succeeded from the source DC was more than the tombstone lifetime ago. Windows will refuse to replicate with this DC to avoid reintroducing deleted (tombstoned) objects. This is a critical event requiring either an authoritative restore or removal and rejoin of the offending DC.

Event ID 1925: Attempt to establish a replication link failed. Usually caused by DNS name resolution failure or RPC connectivity problems. Check that the source DC’s FQDN resolves correctly from the destination DC.

Event ID 4: DNS lookup failure. The DC could not resolve the FQDN or SRV records for a replication partner. Verify DNS registration by running:

nltest /dsgetdc:yourdomain.com /force
dcdiag /test:RegisterInDNS

Detecting and Resolving USN Rollback

A USN rollback occurs when a domain controller’s USN counter is rolled back to a previous state, typically because a VM snapshot was incorrectly restored or a system state backup was restored outside of proper AD restore procedures. After a USN rollback, the DC believes it has already sent updates that it actually has not, causing permanent replication divergence.

Windows Server 2022 detects USN rollbacks automatically and will quarantine the affected DC by stopping the NetLogon service and logging Event ID 2095 in the Directory Service log. You will also see event 1113.

To confirm a USN rollback, run:

repadmin /showutdvec DCname DC=yourdomain,DC=com

Compare the up-to-dateness vector of the suspect DC with its replication partners. If the suspect DC’s own USN is significantly lower than what partners remember sending, you have a rollback. The safest remediation is to demote the affected DC, remove its AD metadata with ntdsutil, and repromote it as a fresh DC. In a multi-DC environment where FSMO roles are not on the rolled-back DC, this is straightforward.

Removing Lingering Objects

Lingering objects exist on a DC when that DC missed the deletion of objects during a period when it was offline or not replicating. When it comes back online, it still has those objects, but other DCs have long since processed the tombstones and garbage-collected them. Lingering objects cause inconsistencies and can prevent certain replication from completing.

To identify lingering objects, compare one DC against a reference DC that is known good:

repadmin /removelingeringobjects ReplicaDC ReferenceDC-GUID "DC=yourdomain,DC=com" /ADVISORY_MODE

Replace ReferenceDC-GUID with the GUID of your reference DC. Running in advisory mode only logs what would be removed without actually removing anything. Check Event ID 1946 in the Directory Service log to see the list of lingering objects found. Once confirmed, remove them:

repadmin /removelingeringobjects ReplicaDC ReferenceDC-GUID "DC=yourdomain,DC=com"

Get the DC GUID using:

repadmin /showrepl ReferenceDC | Select-String "DSA object GUID"

Troubleshooting SYSVOL Replication with DFS-R

Modern Windows Server 2022 domains replicate SYSVOL using DFS-R (Distributed File System Replication). SYSVOL contains Group Policy templates and logon scripts, so replication failures here directly impact policy application. DCDiag’s DFSREvent test checks for replication errors in SYSVOL.

To check the DFS-R replication health:

dfsrdiag ReplicationState /member:DC01.yourdomain.com

To check backlog (pending files to replicate) between two DCs:

dfsrdiag Backlog /SendingMember:DC01 /ReceivingMember:DC02 /RGName:"Domain System Volume" /RFName:SYSVOL

If SYSVOL is stuck and DFS-R shows an error state, you may need to perform a non-authoritative SYSVOL restore. Stop DFS-R on the affected DC, set the DFS-R database flags in the registry to trigger a non-authoritative sync, then restart DFS-R:

Stop-Service DFSR
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetServicesDFSRParametersSysVolsMigrating SysvolsVolume 0Database Volumes{GUID}" -Name "Enable NtFrs" -Value 0
# Set the msDFSR-Enabled attribute to false then back to true via ADSI Edit or PowerShell
Start-Service DFSR

Microsoft’s documented procedure for SYSVOL non-authoritative restore involves using ADSI Edit to toggle the msDFSR-Enabled attribute on the DC object in the SYSVOL subscription. Review KB2218556 for the full step-by-step procedure.

Checking Network Connectivity and Time Skew

Many replication failures are caused by basic network issues. From one DC, verify RPC connectivity to another DC using:

portqry -n DC02.yourdomain.com -e 135 -p TCP

Active Directory replication uses RPC over TCP, which requires port 135 for the endpoint mapper plus dynamic high ports (49152–65535 by default on Windows Server 2022). Firewalls between DCs must permit this traffic. Use portqry or Test-NetConnection to verify:

Test-NetConnection -ComputerName DC02.yourdomain.com -Port 135

Time skew is another common culprit. Kerberos authentication (used by replication) requires all DCs to be within 5 minutes of each other. Check time synchronization:

w32tm /query /status
w32tm /stripchart /computer:DC01.yourdomain.com /dataonly /samples:5

If time is significantly skewed, force a sync:

w32tm /resync /force

Ensure the PDC Emulator FSMO role holder is configured to sync from a reliable external NTP source, and all other DCs sync from the PDC Emulator. This forms a consistent time hierarchy across all domain controllers.

Forcing Replication After Fixing Issues

After resolving the underlying cause of a replication failure, trigger immediate replication rather than waiting for the scheduled interval:

repadmin /syncall /AdeP

The flags mean: /A (all naming contexts), /d (identify DCs by distinguished name), /e (enterprise — replicate across site links), /P (push changes). To force replication between two specific DCs:

repadmin /replicate DC02 DC01 "DC=yourdomain,DC=com"

After forcing replication, run repadmin /replsummary again to confirm all failures are resolved and replication deltas are back to normal. Document the root cause and remediation steps, and consider implementing AD replication monitoring with alerts on Event ID 2042, 1311, and 1388 to catch future issues early.