Fix ERROR_DS_DUPLICATE_ID_FOUND (0X0000219D) in Active Directory

Quick answer (for experienced admins)

Run repadmin /showobjmeta DC-name DN-of-duplicate to confirm the duplicate. Then use ntdsutil to remove the offending object or force authoritative restore of the correct one.

Why you're seeing this error

I know this error is infuriating—it usually pops up right after you restore a domain controller from a backup or try to join a new DC to an existing domain. The core problem: Active Directory expects every object (user, group, computer) to have a globally unique identifier (GUID) and security identifier (SID). When you restore a snapshot of a DC without properly synchronizing with replication partners, you can end up with two objects that share the same GUID or SID. The error code 0X0000219D translates to “The requested object has a nonunique identifier and cannot be retrieved.”

I've seen this most often when someone runs an authoritative restore on a single DC but forgets to tombstone reanimate the duplicate objects on the other DCs. It also happens if you’re trying to migrate objects between forests and the same GUID gets reused by mistake. The error will show up in the Directory Service event log (event ID 1988 or 1990) and can break logins, group membership lookups, and replication.

Step-by-step fix

1. Identify the duplicate object
   Open Event Viewer, navigate to Applications and Services Logs > Directory Service. Look for error events with ID 1988 or 1990. They’ll list the attribute that’s duplicated (usually objectGUID or objectSid) and the distinguished name (DN) of the two conflicting objects. Write down both DNs.
2. Confirm the replication metadata
   On a working domain controller, run:

   repadmin /showobjmeta . "CN=John Doe,OU=Users,DC=contoso,DC=com"

   Replace the DN with one of the duplicates. Look at the objectGUID and objectSid lines. Note which DC has the latest version and which has the stale duplicate.
3. Remove the bad duplicate
   You have two choices here. My go-to: use ADSI Edit to delete the wrong object. But only if you’re sure which one is the duplicate. Connect ADSI Edit to the DC holding the fake copy, find the object, right-click, Delete. This will immediately tombstone it. Wait for replication to propagate.
4. Force replication
   After deletion, force replication from the DC where you made the change:

   repadmin /syncall /AdeP

   Watch for error 8418, which means you still have a lingering object. If that happens, move to the alternative fixes below.
5. Verify the error is gone
   Check the Directory Service log again. Also run dcdiag /test:replications on every DC. No error 0X0000219D = fixed.

Alternative fixes if the main approach fails

Remove lingering objects with repadmin
Sometimes the duplicate is a “lingering object” that replication can’t handle because it’s been deleted on the reference DC but still exists on a copy. On the DC holding the linger, run:

repadmin /removelingeringobjects DC-name GUID-of-reference-DC /advisory_mode

Authoritative restore with ntdsutil
If the duplicate is a critical system object (like a domain controller computer account or a schema object), you can’t just delete it. Instead, perform an authoritative restore of the correct object from a known-good backup. Boot the DC into Directory Services Restore Mode (DSRM), launch ntdsutil, and use the authoritative restore command to mark the correct DN as authoritative. This will force it to replicate to all DCs and overwrite the duplicate.

Reset the offending object's GUID via PowerShell
For non-critical objects, you can sometimes force a new GUID using the Set-ADObject cmdlet. But this is hacky—I’ve only done it once in a lab. Example:

Get-ADObject -Identity "CN=John Doe,OU=Users,DC=contoso,DC=com" | Set-ADObject -Replace @{objectGUID=[guid]::NewGuid()}

Prevention tip

Stop doing snapshot-based restores on DCs unless you absolutely understand the consequences. Always use ntdsutil authoritative restore for full DC restores. For individual objects, use tombstone reanimation with repadmin instead of restoring a whole backup. And set up regular replication health checks with dcdiag—I run mine every Monday morning. Trust me, catching a lingering object early beats dealing with 0X0000219D at 3 AM.