Fix ERROR_DS_DRA_ABANDON_SYNC (0x0000210E) AD Replication

This AD replication error means the sync was abandoned because the destination DC had no new updates to pull. It's usually harmless, but can point to a stalled replication partner.

Quick answer: If you see ERROR_DS_DRA_ABANDON_SYNC (0x0000210E), the destination domain controller stopped the replication cycle early because the source DC reported no changes to send — usually not a failure, just an empty sync.

I've seen this error pop up in repadmin /showrepl output and in Directory Service event logs on Domain Controllers running everything from Windows Server 2008 R2 up to 2022. The wording sounds scary — "abandoned" makes it sound like someone pulled the plug mid-sync. What actually happened is more mundane. When a DC initiates replication with a partner, it asks "do you have anything new since my last USN?" If the answer is "nope," the initiator doesn't sit there waiting. It logs 0x0000210E and moves on. That's the whole story in most cases.

The catch is that this error can also appear when replication is genuinely stuck — for example, when a DC's inbound partner has a broken topology, or when lingering objects or a tombstone lifetime issue is blocking updates. The trigger I run into most often? A single-DC test lab where someone adds a second DC, then runs repadmin /replsummary and panics because every pairing shows 0x0000210E. Nothing's wrong. There's just nothing to replicate. The same thing happens on production DCs during quiet hours when no one's changed a password, group membership, or GPO in a while.

Step-by-step: confirm whether you actually have a problem

Open an elevated Command Prompt on one of the DCs. You'll need Domain Admin or Enterprise Admin rights — this won't work from a regular user account. If UAC is enabled (it is by default), right-click Command Prompt and pick Run as administrator. You should see the window title say "Administrator: Command Prompt."
Run a replication health summary. Type this and hit Enter:
```
repadmin /replsummary
```
You'll get two tables: one for inbound, one for outbound. Look at the "Fails/Total" column. If a pairing shows 0 fails, and the only thing you saw was 0x0000210E earlier, you're fine. If fails are showing up alongside other error codes (8453, 1722, 8524), keep reading.
Check the forced sync test. Force replication from one DC to its partners:
```
repadmin /syncall /AdeP
```
Expected outcome: a line for each naming context, something like Syncing partitions from DC01 to DC02... followed by SyncAll terminated with no errors. If you get 0x0000210E here on a quiet directory, that's still normal — it means nothing needed to move.
Run DCDIAG's replication test. This catches the real problems the summary can miss:
```
dcdiag /test:replications /v
```
You want to see "passed test Replications" in the output. If it fails, note which DC and which partition — that tells you where the actual stall lives.
Look at the Directory Service event log. Open Event Viewer, go to Windows Logs > Directory Service. Filter for Event ID 1863 or 2042. Event 1863 means a DC hasn't replicated in longer than Tombstone Lifetime — that's the serious one and 0x0000210E is often the symptom you see just before it. Event 2042 is the "replication has been blocked" warning. If you see either, jump to the alternative fixes below.
Make a change and re-check. This is the cleanest way to test. On the source DC, create a dummy user account in ADUC. Then run:
```
repadmin /showrepl DC02
```
Replace DC02 with your destination DC's name. You should see the last replication attempt succeed with a new USN. If the dummy account shows up on the target within 15 seconds (intra-site) or 15 minutes (inter-site), your replication is healthy. The abandoned-sync message was just noise.

If replication really is stalled

When 0x0000210E keeps appearing and you've confirmed changes aren't moving, the cause is almost always one of these three things. Work through them in order.

Broken or one-way replication links

Run this to see the current topology:

repadmin /bridgeheads /verbose
repadmin /kcc

The KCC (Knowledge Consistency Checker) rebuilds the topology every 15 minutes by default. If a link is missing or pointing the wrong way, force a rebuild and check again. On Windows Server 2016 and later, repadmin /kcc is fast and safe to run any time.

Lingering objects

These are AD objects that were deleted on one DC but are still alive on another — usually because replication was broken longer than the tombstone lifetime (180 days by default on 2003+, 60 days on 2000). The only clean fix is to enable strict replication consistency on the affected DC via the registry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Value name: Strict Replication Consistency
Type: REG_DWORD
Data: 1

Set that, reboot the DC, and any inbound replication from a partner with lingering objects will fail loudly — which is what you want, because now you can run repadmin /removelingeringobjects against the specific partner. Don't skip the reboot. The setting is read at service start.

DNS misconfiguration between DCs

Ninety percent of "mystery" AD replication problems trace back to DNS. Each DC should point at another DC (or itself) for its primary DNS, never at a public resolver like 8.8.8.8. Check with:

nslookup -type=SRV _ldap._tcp.dc._msdcs.yourdomain.com

You should see every DC listed. If one's missing, fix its DNS record under the _msdcs zone or restart the Netlogon service on that DC to re-register.

Prevention

Stop treating 0x0000210E like an alarm. Set up a weekly scheduled task that runs repadmin /replsummary and emails the output. You'll spot real failures (8453, 1722, 8524) the same day they start, instead of three weeks later when users are complaining that their password change didn't sync to the branch office. Also — and this one bites people — never leave a DC powered off for more than 60 days without demoting it first. That's the fastest way to create lingering objects and turn a harmless abandoned-sync into a real replication outage.