0X0000210A

Fix ERROR_DS_DRA_NAME_COLLISION (0x210A) in 3 Steps

Active Directory replication fails with name collision. Start with tombstone reanimation, then clean up lingering objects, and finally force replication. Most fixes take under 10 minutes.

Quick Fix (30 seconds): Check for a Recently Deleted Object

This error shows up when a deleted object is recreated with the same name on another domain controller, but the tombstone hasn't replicated yet. The fix is almost embarrassingly simple.

  1. Open Active Directory Users and Computers on the domain controller that's failing.
  2. Enable Advanced Features under the View menu.
  3. Navigate to the Deleted Objects container in the domain partition.
  4. Look for an object with the same name as the one causing the collision.
  5. Right-click it and choose Reanimate (or use ntdsutil if the option isn't available).

That often resolves it because the tombstones get reconciled. I've seen this trigger after a restore from backup or when someone accidentally deleted a user and immediately recreated them. If the reanimation option is grayed out, move to the next step.

Moderate Fix (5 minutes): Purge Lingering Objects with repadmin

If reanimating doesn't work, you're dealing with a lingering object — a stale copy of a deleted object that never got cleaned up. This happens when a DC is offline for a long time, past the tombstone lifetime (default 180 days).

First, identify which DCs have the collision. Open an elevated command prompt and run:

repadmin /showrepl

Look for the Last Status column. The DCs with 0x210A need attention.

Now, check for lingering objects on the source DC. Replace SourceDC with the actual name:

repadmin /removelingeringobjects SourceDC <NamingContextDN> /advisory_mode

For example:

repadmin /removelingeringobjects DC01 "DC=contoso,DC=com" /advisory_mode

This runs in advisory mode first, showing you what would be removed. If the list looks right — meaning it's just the conflict object and not something you need — run it again without /advisory_mode:

repadmin /removelingeringobjects DC01 "DC=contoso,DC=com"

I usually do this on all DCs that report the error, even if only one seems to have the problem. Lingering objects like to hide.

Advanced Fix (15+ minutes): Force Replication and Check Schema

If the collision persists, replication might be stuck due to a mismatch in the replication topology or a schema issue. Here's the longer path.

1. Force Replication

Clear any queued replication and try again:

repadmin /syncall /AdeP

This pushes changes to all partners. Watch for new errors.

2. Verify the Schema Master

Name collisions can also happen if schema updates haven't fully replicated. On the schema master, run:

repadmin /replicate DC01 SchemaDC <SchemaNamingContext>

Replace SchemaDC with your schema master's hostname. You can find it with netdom query fsmo.

3. Delete the Conflicting Object Manually

Sometimes the simplest fix is to just delete the object causing the collision and let it replicate. But be careful — if it's a user, you might need to preserve attributes. Export it first with csvde:

csvde -f export.csv -r "(&(objectClass=user)(|(cn=ConflictingName)(samAccountName=conflicting)))"

Then delete it from the DC where it's lingering, and recreate it after replication catches up.

4. Disable and Re-enable the NTDS Settings

If nothing else works, disable and re-enable the NTDS Settings object on the problematic DC. This forces a fresh replication agreement. In Active Directory Sites and Services, find the DC, expand its NTDS Settings, right-click the connection object, and delete it. Then right-click NTDS Settings and choose Check Replication Topology. Windows will rebuild the connection.

Note: This is disruptive. Do it during a maintenance window if you're in production.

What to Do If None of These Work

If you're still stuck, check the event logs for the underlying cause. Look for Event ID 1988 or 1989, which often accompany 0x210A and give more detail. Also verify that your DCs are running the same OS version — mixed Windows Server 2012 and 2016 DCs can have subtle replication quirks.

One last tip: run dcdiag /test:replications to get a full health report. It'll point you to the exact DC and partition that's failing. I've seen this error pop up right after someone promotes a new DC without letting it fully replicate — so patience during promotion is your friend.

You've got this. Replication errors are annoying, but they're almost always fixable with the steps above.

Related Errors in Windows Errors
0X0000057D 0X0000057D: Invalid window handle – real fix 0X00000FDC PEERDIST_ERROR_ALREADY_COMPLETED (0X00000FDC) Fix 0X00002021 Fix ERROR_DS_PROTOCOL_ERROR (0X00002021) in Active Directory Google Search redirect loop fix for Windows

Was this solution helpful?

EP
Erropedia Team
Tech Support Editors
The Erropedia editorial team researches and documents real-world tech errors from across Windows, Linux, macOS, networking, databases, cloud platforms, and more. Every solution is reviewed for accuracy and updated as software and systems evolve.