Reading Active Directory replication failures before they become outages

Replication problems are the clearest example I know of a fault that is trivial on day three and unrecoverable on day one hundred and eighty-one. The tooling tells you about it the entire time. The reason it becomes an outage is that nobody was reading the output.

The symptom, as it usually arrives

Nobody reports “replication is broken”. What gets reported is:

A password reset works at head office and fails at a branch.
A newly created account cannot sign in on one site.
A group membership change does not take effect for some users.
A Group Policy change applies inconsistently.
Someone demotes a domain controller and the removal never propagates.

All of these are one symptom — two domain controllers disagree about the contents of a naming context — and the disagreement has a duration. That duration is the thing to establish first.

The architecture the symptom lives in

Active Directory is multi-master with loose convergence. Every writable domain controller accepts changes and replicates them outward. Within a site, a change triggers a notification after a short delay, so convergence is quick. Between sites, replication follows the site link schedule and interval, so convergence is deliberately slower.

Three structures decide whether replication can happen at all:

The connection topology, generated by the Knowledge Consistency Checker from your sites, subnets and site links. If the KCC cannot build a topology, nothing else matters.
Name resolution, because replication partners are located by their DNS aliases in the _msdcs zone. Replication is an RPC conversation with a host the source has to find.
The tombstone lifetime, which is the hard deadline. A deletion is retained as a tombstone for that period. A domain controller that has not replicated a naming context within it can no longer safely replicate that context at all, because it may still hold objects everyone else has deleted and garbage-collected.

The tombstone lifetime defaults to 180 days in forests built on Windows Server 2003 SP1 or later, and 60 days in older ones. Check yours rather than assuming; it is a forest-wide attribute and people do change it.

Diagnosis, in the order that narrows fastest

1. Get the forest-wide picture first

Never start on the domain controller someone complained about. Start with the summary:

repadmin /replsummary

This gives you the largest replication delta and the failure count per source and destination. It answers “how bad, and since when” in one screen. If the largest delta is measured in days, you have a duration problem, not a transient one.

Then take the detailed forest-wide export:

repadmin /showrepl * /csv > C:\Temp\showrepl.csv

Open it in a spreadsheet and sort by last failure time and consecutive failure count. You are looking for the pattern: one destination failing against every source is a problem on that destination. Every destination failing against one source is a problem on that source. One naming context failing everywhere is usually permissions or a lingering object.

2. Read the error code, not the error text

Replication errors are specific, and the code tells you which layer to investigate.

Code	Meaning	Where to look
1722	The RPC server is unavailable	Network path, firewall, host down
1256	The remote system is not available	Connectivity, name resolved but host unreachable
8524	DSA operation unable to proceed because of DNS lookup failure	`_msdcs` records, client DNS configuration
8453	Replication access was denied	Permissions on the naming context, machine account
8451	The replication operation encountered a database error	Local database health on the destination
8606	Insufficient attributes were given to create an object	Lingering object with strict consistency enabled
8614	Time since last replication exceeded the tombstone lifetime	Past the deadline; do not force replication

That last row is the one that changes the plan entirely, so treat it as a stop condition rather than a step.

3. Confirm the supporting layers

For anything resolving to 1722, 1256 or 8524, check the plumbing before touching the directory:

dcdiag /test:DNS /DnsBasic /v
dcdiag /test:Replications /v
nltest /dsgetdc:contoso.com /force

Replication needs the RPC endpoint mapper on TCP 135 plus a dynamic port, which on current Windows Server builds is the ephemeral range 49152 to 65535, along with DNS on 53 and Kerberos on 88. A firewall that permits 135 and nothing above it produces exactly the intermittent 1722 pattern people spend weeks on.

4. Look at the event log for the structural failures

Three events matter more than the rest:

1311 — the KCC could not build a topology that connects all sites for a naming context. This is almost always a site, subnet or site link configuration error, not a fault on the domain controller reporting it.
1988 — the local domain controller has a replication partner holding an object it deleted and garbage-collected. This is a lingering object, and replication of that naming context stops until it is resolved.
2042 — it has been too long since this machine last replicated with the named source. This is the tombstone lifetime message. Replication with that partner is now blocked by design.

Event 2095 deserves its own mention. It indicates a USN rollback: a domain controller was restored or reverted in a way that made it re-issue update sequence numbers other controllers had already seen. Windows responds by making the directory service non-writable. That is the correct response and you should not work around it.

Interpreting what you found

The interpretation step is where the decision actually gets made, and there are only three outcomes worth distinguishing.

Transient and recoverable. Failures are recent, the delta is within the replication interval, and the error points at the network. Fix the path and let replication converge on its own. Verify convergence rather than forcing it.

Persistent but within the tombstone lifetime. A real fault — permissions, DNS, a failing partner — has existed for days or weeks but the deadline has not passed. Fix the cause, then trigger replication and confirm convergence. This is the ordinary case and the one you want to catch.

Past the tombstone lifetime, or a USN rollback. Do not force replication. Forcing it is how lingering objects and inconsistent deletions spread. The correct action is to demote the affected domain controller — forcibly, with metadata cleanup, if it will not demote cleanly — and rebuild it. A domain controller is a replica, and rebuilding one is a routine operation. Reintroducing divergent data into a healthy forest is not.

This is the point where people make the situation worse, and they make it worse by treating “get replication working again” as the objective. The objective is a consistent forest.

Resolution

For the ordinary case, resolve the cause and then verify rather than assume:

repadmin /syncall /AdeP
repadmin /showrepl
repadmin /queue

repadmin /queue is worth a moment: a persistently non-empty queue means the destination is accepting work faster than it can process it, which points at database or disk health rather than connectivity.

For lingering objects, identify them before removing anything. repadmin /removelingeringobjects supports an advisory mode that reports what it would delete, against a domain controller you have confirmed is authoritative and healthy. Run the advisory pass, review the list with the directory owner, and only then remove. Enabling strict replication consistency afterwards stops the same objects being reintroduced.

For a single attribute that disagrees between two controllers, metadata tells you which change is newer and where it originated:

repadmin /showobjmeta DC01.contoso.com "CN=Sample User,OU=Accounts,DC=contoso,DC=com"

Validating that it is actually fixed

A single successful replication is not evidence. I want three things before I close it:

repadmin /replsummary shows zero failures and a largest delta inside the expected interval, across every domain controller — not just the pair you were working on.
A test change converges. Create a disposable object in a test organisational unit on one controller, and confirm it appears on the others within the expected window. Delete it afterwards.
The failure count stays at zero across at least one full inter-site replication cycle and one KCC run, which means checking again the following day rather than the same hour.

Catching it earlier next time

Everything above is recoverable because replication was checked. The cheap version of this article is a scheduled task that runs repadmin /replsummary and alerts on a non-zero failure count or a delta beyond a threshold you choose. That single check converts the 180-day cliff into a ticket.

Keep that check read-only. A health check that repairs things on your behalf will eventually repair the wrong thing at three in the morning, and the whole value of this evidence is that it is evidence.

Verification and limits

Command syntax and error-code meanings were checked against current Microsoft documentation on 20 September 2026. The diagnostic sequence reflects how I work through these faults.

Nothing here was executed in a lab for this article, and two cautions matter more than the rest. repadmin /removelingeringobjects deletes directory objects — always run the advisory pass first and have the directory owner review it. Forcible demotion and metadata cleanup are destructive operations that need current backup evidence before you begin. If the forest is past a tombstone lifetime on multiple controllers, treat it as a recovery planning exercise rather than a repair.