Fix ERROR_DS_DRA_OBJ_NC_MISMATCH 0X00002161

I know that sinking feeling when a domain controller stops replicating and throws ERROR_DS_DRA_OBJ_NC_MISMATCH (0X00002161). It usually means a domain controller has stale metadata about a naming context that no longer exists—or never should have existed on that DC. The good news? You can fix this without rebuilding the DC.

Quick Fix: Clean Up Metadata and Force Replication

This error almost always comes from leftover metadata from a removed naming context (like an orphaned application partition or a dead domain controller). The fix is two parts: remove the stale metadata, then trigger a fresh replication cycle.

Open an elevated command prompt on the source domain controller (the one the destination DC is trying to replicate from). Right-click Command Prompt and choose "Run as administrator."
Identify the problem naming context. Run this command on the source DC:
```
repadmin /showobjmeta * "DC=corp,DC=contoso,DC=com"
```
Replace DC=corp,DC=contoso,DC=com with your actual domain distinguished name. Look for any orphaned partitions—they'll show an NC name that doesn't match your domain. For example, if your domain is DC=office,DC=local, but you see DC=test,DC=lab, that's the problem.
After pressing Enter, you'll see a list of all objects and their metadata. Scan the "NC Name" column. If you see a naming context that shouldn't exist (like from a removed domain or a failed promotion), make a note of its full distinguished name.
Remove the orphaned naming context using ntdsutil. This is the meat of the fix:
```
ntdsutil
metadata cleanup
connections
connect to server <source_DC_name>
quit
select operation target
list domains
select domain <index_number_of_bad_NC>
quit
remove selected domain
quit
quit
```
When you run list domains, you'll see a numbered list. Pick the index number that matches the orphaned naming context you found earlier. The remove selected domain command deletes that metadata from Active Directory. You'll get a confirmation dialog—click Yes.

After this step, run repadmin /showobjmeta again on the source DC. The orphaned NC should be gone. If it's still there, you might need to replicate first (next step) and then try again.
Force replication. On the destination DC (the one with the error), run:
```
repadmin /syncall /AdeP
```
This tells the destination DC to pull all changes from its source. You should see success messages. Wait 30 seconds, then check the event log for NTDS Replication events—they should be 1126 (success) rather than 1125 or 1126 errors.
Verify replication health. Run this on both DCs:
```
dcdiag /test:replications
```
If the error is gone, you're done. If it persists, move to the variation section below.

Why This Works

The 0X00002161 error means the source DC tried to replicate an object whose naming context doesn't match what the destination DC expects. Think of it like a librarian trying to file a book under a category that doesn't exist on the shelf. The metadata cleanup removes the phantom category, and forced replication rebuilds the sync relationship. No reboot needed.

I've seen this happen most often after a domain controller was demoted improperly—someone ran dcpromo /forceremoval or deleted the DC object from AD without running metadata cleanup. The leftover NC metadata is like a ghost that confuses replication.

Less Common Variations of the Same Issue

Multiple Orphaned Application Partitions

Sometimes you'll find multiple stray naming contexts, usually from old DNS application partitions or an abandoned child domain. Run this command to see them all:

repadmin /showrepl * /csv | findstr /i "0x00002161"

That filters replication partners showing the exact error. For each line, check the partition column. Then repeat the ntdsutil cleanup for each bad partition.

Cross-Forest Trust Mismatch

If you've got a cross-forest trust, a misconfigured trust can also throw this error. Open Active Directory Domains and Trusts, right-click the trust, go to Properties, and verify the naming contexts match on both sides. If they don't, remove and recreate the trust. It's a pain, but faster than chasing phantom metadata.

Replication Halted by Firewall or Port Block

I've seen one case where the error was actually a symptom of a blocked port 389 (LDAP) between DCs. The destination DC couldn't read the full object, so it assumed a naming context mismatch. Check with Test-NetConnection -ComputerName <source_DC> -Port 389. If it fails, talk to your network team.

Prevention

Two things stop this error from coming back:

Always use metadata cleanup when removing a domain controller. Never just delete the server object from AD. Use ntdsutil metadata cleanup or the GUI in Active Directory Sites and Services (right-click the DC, choose Delete, follow the wizard).
Monitor replication daily. Set up a scheduled task that runs repadmin /replsummary and emails you the output. That catches mismatches before they break replication entirely. I use a simple PowerShell script that runs every morning at 6 AM.

That's it. You cleaned the metadata, forced a sync, and your DCs should be talking again. If not, double-check the naming contexts with repadmin /showrepl—there's probably one more orphaned partition hiding in there.