Fix ERROR_DS_DRA_SOURCE_REINSTALLED 0x0000210B

What Causes Error 0x0000210B and How to Fix It First

You'll see ERROR_DS_DRA_SOURCE_REINSTALLED (0x0000210B) when a domain controller you're trying to replicate from was reinstalled from backup or rebuilt without proper demotion. The replication engine sees the source DC's invocation ID changed—it's essentially a different machine now, but with the same NTDS settings object. This breaks the replication trust.

The most common trigger is someone restoring a DC from backup (or cloning a VM snapshot) instead of doing a clean dcpromo /demote. Another way: you replaced a failed DC by building a new one with the same name—but didn't clean up the old metadata first.

The fix that works 90% of the time is to remove the stale source DC's metadata from Active Directory and force a replication check. Here's exactly how.

Step 1: Identify the Bad Source DC

Open Command Prompt as Administrator on any working DC. Run:

repadmin /showrepl

Look for lines with 0x210B or ERROR_DS_DRA_SOURCE_REINSTALLED. You'll see something like:

Source: DC-SOURCE.contoso.com
****** 0x210B ERROR_DS_DRA_SOURCE_REINSTALLED

Write down the full DNS name of that source DC. That's the one you need to clean up.

Step 2: Remove the Source DC's Metadata with NTDSUtil

On a working DC (preferably one that holds the infrastructure master role), run:

ntdsutil
metadata cleanup
connections
connect to server localhost
quit
select operation target
list domains
select domain 0
list sites
select site 0
list servers in site
select server 0
quit
remove selected server
quit
quit

What to expect: After you type remove selected server, you'll see a confirmation prompt: "This server will be removed from the Active Directory database. Are you sure you want to remove it?" Type Yes. If it succeeds, you'll see "Removed server object successfully." If you get an error like "The specified server is not a domain controller", you likely selected the wrong server. Go back and double-check the server name from step 1.

If the remove fails because the server metadata is already corrupted (rare but happens), force it by using ADSI Edit: navigate to CN=Servers,CN=<SiteName>,CN=Sites,CN=Configuration,DC=contoso,DC=com, find the server object, and delete it. But honestly, that's a last resort—ntdsutil usually works.

Step 3: Force Replication to Clear the Error

After the metadata is gone, run this on all remaining DCs:

repadmin /syncall /AdeP

Watch for success messages. If you still see 0x210B for a different source DC, rinse and repeat. The error should clear within the next replication cycle (which happens every 15 seconds by default if you use /syncall).

The Second Most Common Cause: Restored DC with Same Invocation ID

Sometimes the source DC wasn't actually rebuilt—it was restored from backup or a snapshot. Windows Server 2016 and later are better at detecting this, but it still trips up older DCs (2012 R2 and earlier). The DC's invocation ID stays the same (if restored from backup), but the USN numbers are now out of sync with its replication partners.

This manifests as error 0x0000210B because the destination DC sees the same source DC GUID but its highest committed USN is lower than expected. The replication engine interprets this as "source was reinstalled from backup" and refuses to replicate.

Fix: Force a Non-Authoritative Synchronization

On the destination DC (the one reporting the error), open an elevated command prompt and run:

net stop ntds
net start ntds

Then immediately run:

repadmin /syncall /A /e /P /q

This forces a full pull from all source DCs. If you still get the error, you need to reset the invocation ID on the destination DC (yes, the one that's getting the error). That's a bit drastic—it forces a full sync—but it works. Do it like this:

ntdsutil
set dsa object %s
reset invocation id
quit

Note: Resetting the invocation ID triggers a full replication of the entire directory from the source. On a large domain (100K+ objects), this can take hours. Only do this if you're sure the source DC is healthy and you have good bandwidth between sites.

The Third Most Common Cause: DNS Stale Records Pointing to a Dead DC

Error 0x0000210B can also show up when DNS still has old A or CNAME records for a source DC that no longer exists. The destination DC resolves the name, tries to connect, and gets a broken replication state because the target machine isn't a DC anymore (or is a different machine entirely). This is especially common after you've demoted a DC but didn't clean up its DNS records.

Fix: Scavenge and Remove Stale DNS Records

Open DNS Manager on a DC that runs the DNS server role. Right-click the zone (e.g., contoso.com), go to Properties, then the General tab. Click Scavenging and set it to No-refresh interval and Refresh interval to something low (like 7 days each). Then right-click the zone again and click Scavenge now.

After scavenging, check the _msdcs.contoso.com zone under Forward Lookup Zones. Delete any host (A) records for DCs that no longer exist. Pay special attention to the _tcp and _udp subfolders—stale SRV records there will confuse replication.

Once done, flush DNS cache on all DCs:

ipconfig /flushdns
net stop dnscache
net start dnscache

Then run repadmin /syncall /AdeP again. If the error goes away, DNS was your culprit.

Quick-Reference Summary Table

Start with the metadata cleanup. That's the real fix in almost every case. The DNS issue is a dark horse—if metadata cleanup doesn't work, check DNS before you reset invocation IDs. You'll save yourself a lot of replication traffic.