You're running repadmin /showrepl or checking Directory Services logs and you see ERROR_DS_DRA_DN_EXISTS (0x000020F9). The full message says "The DN specified for this replication operation already exists." This typically pops up after you've force-deleted an object (like a user or OU) that had a lingering object counterpart on another domain controller. Or it happens when you restore an object from tombstone reanimation, but the reanimated object's DN clashes with a defunct copy still floating around on a DC that hasn't replicated in ages.
What's actually happening here is that replication is trying to create or update an object whose distinguished name (DN) already exists in the destination DC's database. In normal operation, AD uses a unique identifier (objectGUID) to track objects, and DNs can be renamed. But when a tombstone is reanimated or a lingering object survives, two different objects can claim the same DN. The destination DC refuses to overwrite the existing object because it sees a different objectGUID behind that DN, so it throws 0x20F9.
The root cause is almost always a domain controller that missed the original deletion or rename, leaving a stale copy of the object. When the change finally replicates to that DC, the DN collision blocks it.
Fix Steps
- Identify the conflicting object. Check the event log on the destination DC (the one throwing the error). Look for Event ID 1988 or 1989 in Directory Service — they'll name the object DN. If you only have the error in repadmin output, run
repadmin /showobjmetaon both source and destination to compare which DC holds the conflicting instance. - Confirm the object is lingering. Use
repadmin /removelingeringobjectson the destination DC. First, run it in preview mode:repadmin /removelingeringobjects. That lists what it would delete without touching anything. If the DN from the error appears in the list, you've found your culprit./advisory_mode - Remove lingering objects on the destination DC. Run the actual removal:
repadmin /removelingeringobjects. This forces the destination DC to delete the stale copy. You'll need the GUID of a healthy source DC — repadmin will prompt you or you can specify it with/sync /source:<DC-GUID>. - Force a replication sync. After cleanup, force replication from the source to the destination:
repadmin /syncall /AdeP. This should now apply the delete or rename that initially failed. - If the object was supposed to be restored (tombstone reanimation), redo it cleanly. Reanimate the object first on a clean DC, let it replicate everywhere, then delete it properly. Don't skip the normal delete ritual.
Why this works
The reason step 3 works is that lingering objects exist outside the normal replication tombstone lifetime. A DC that was offline for longer than the tombstone lifetime (default 180 days on Server 2008+ or 60 days on older) keeps a deletes-not-received object forever. Removing it directly from the destination DC clears the collision without requiring a full tombstone reanimation.
If it still fails
If you still get 0x20F9 after removing lingering objects, the issue might be a phantom object — one that wasn't marked in the lingering object list but still has the DN. Try this:
repadmin /showattr <destDC> "<DN of conflicting object>" /gc
Check if the object has an objectGUID and isDeleted attribute. If isDeleted is TRUE, it's a tombstone that hasn't been purged. Run repadmin /syncall after manually deleting that tombstone with ADSI Edit (navigate to the Deleted Objects container, find the object, right-click and delete).
Another possibility: the destination DC has USN rollback, meaning it's been restored from a backup and missed changes. Run dcdiag /test:checksecurityerror and check for Event ID 2095. If you see USN rollback, the DC needs to be forcibly demoted and then promoted again — there's no clean fix for that short of rebuilding the DC.
Also verify your garbage collection interval. If you're on an old 2003 DC with a 60-day tombstone lifetime and you have DCs offline longer than that, you're going to keep hitting this. Upgrade to 2008+ or extend the tombstone lifetime before it's too late — you can't extend it after objects start lingering.
Finally, if none of that helps and you're certain the object is needed (it shouldn't be deleted), do a full metadata cleanup: ntdsutil metadata cleanup to remove the destination DC from the topology, let replication heal, then re-promote it. That's the nuclear option, but it's guaranteed to clear any stale attribute collision.