Fix ERROR_DS_DRA_OBJ_IS_REP_SOURCE (0X00002102) in AD

Yeah, this one's a pain. You're trying to clean up an old domain controller or remove a naming context, and Windows throws this cryptic error: 0X00002102 — "The naming context cannot be removed because it is replicated to another server." The immediate reaction is to jump into ADSI Edit and force delete. Don't. That's how you orphan metadata. Let me show you the real fix.

The Quick Fix: repadmin to the Rescue

The culprit here is almost always a lingering replication link. Some domain controller — often a dead one — still shows as a replication partner for this naming context. Active Directory won't let you remove the context until you clear that link.

Open PowerShell or Command Prompt as Administrator and run:

repadmin /removelingeringobjects <YourDC> <NamingContextDN> /advisory_mode

Replace <YourDC> with the FQDN of the DC you're trying to clean up (e.g., dc01.contoso.com) and <NamingContextDN> with the distinguished name of the naming context (e.g., DC=contoso,DC=com). The /advisory_mode flag first — it shows what it would remove without actually doing it. Check the output for any errors.

If that looks clean, run it again without /advisory_mode:

repadmin /removelingeringobjects <YourDC> <NamingContextDN>

Now try your removal again. In most cases, that's it.

Why This Works

The error 0X00002102 fires because AD's consistency checker sees that another DC still has this naming context in its replication topology. Even if that other DC is offline, tombstoned, or physically destroyed, AD tracks it as a replication source. The /removelingeringobjects command tells the source DC to remove all references to that object from its replication metadata. Once those links are gone, AD allows the naming context removal.

Skipping this and force-deleting via ADSI Edit leaves orphaned replication entries in other DCs' databases. Over time, that causes lingering object warnings or full replication failures.

When That Doesn't Cut It — Less Common Variations

Sometimes /removelingeringobjects returns "access denied" or "object not found." That usually means the replication link is stale at the source DC level. Here's the next step:

Check the Replication Partners

repadmin /showrepl <YourDC> /all

Look for entries under the specific naming context. Any partner that shows last success: never or last failure: ... is suspect. If you see a DC that's long gone, use this:

repadmin /options <OfflineDC> +DISABLE_INBOUND_REPL
repadmin /options <OfflineDC> +DISABLE_OUTBOUND_REPL

Then try the removal again. If that still fails, you can use ntdsutil to metadata cleanup the old DC object entirely. But that's a nuclear option — only do it if repadmin commands fail.

Another Edge Case: Read-Only Domain Controllers (RODCs)

If this error pops up on an RODC, the fix is different. RODCs cache a read-only copy of the naming context, and you need to remove the RODC from AD first. Run:

Remove-ADDomainController -Identity <RODCName> -ForceRemoval

Then clean up the computer object. Only after that can you remove the naming context from the writable DC.

Prevention for Next Time

This error almost always comes from improper decommissioning of old DCs. When you demote a DC, always run the Active Directory Domain Services Installation Wizard (dcpromo on older systems, Remove-ADDomainController on newer ones) — never just wipe the server. That leaves replication links behind.

Also, keep a list of all DCs in your environment. Before removing a naming context, verify it's not a replication source for any other DC:

repadmin /bridgehead

That command shows all bridgehead servers and their replication relationships. If your target naming context appears, you've got work to do first.

One last thing: if you're using AD sites and services to remove a DC manually, make sure you delete the NTDS Settings object of the old DC under the server object. That's the physical replication link — it's what triggers the error. Delete that object first, then remove the naming context.

Short version: repadmin before ADSI Edit, every time. Force-deleting without cleaning replication links is how you get orphaned DC metadata and headaches down the road.