Fix ERROR_DS_OBJ_ALREADY_EXISTS (0X000020A9)

This one always feels like a gut punch

You're trying to create a user, group, or computer in Active Directory, and boom—error 0X000020A9. The full message reads, "A local object with this object already exists (dead or alive)." I remember the first time I saw this on a Windows Server 2016 domain controller. It wasn't a typo—somehow a tombstoned object from a decommissioned DC was blocking a new creation.

Here's the fix: clean up the stale object

Open ADSI Edit (it's part of RSAT). Connect to the domain partition where the object should live. Navigate to the parent OU or container. Look for the object name that's failing. It might be:

Visible but marked as deleted (you'll see CNF: or DEL: in the name)
Hidden entirely if it's a tombstone or lingering object

If you see a visible deleted object, right-click it and delete it. That's usually enough.

If you don't see it, the object is a lingering object. You need to force replication or use repadmin to remove it. From an elevated command prompt on the problem DC, run:

repadmin /removelingeringobjects   /advisory_mode

Replace DC_name with the domain controller showing the error, and object_DN with the distinguished name of the object you're trying to create. For example:

repadmin /removelingeringobjects DC01 "CN=JohnDoe,OU=Users,DC=contoso,DC=com" /advisory_mode

The /advisory_mode flag just logs what it would do. Run it first. If it looks right, repeat without that flag. Then try your original operation again.

Pro tip: If you can't find the object's DN, enable "View deleted objects" in ADSI Edit. It's under the View menu.

Why this happens

Active Directory uses a single-master replication model for object creation. When you create an object on one DC, that DC claims a unique GUID. If that GUID somehow gets replicated to another DC (maybe through a lingering object from a disconnected DC or a tombstone that hasn't been garbage-collected), the second DC thinks the object already exists. The error code 0X000020A9 (that's 8361 in decimal) means ERROR_DS_OBJ_ALREADY_EXISTS. It's telling you, "Hey, I've already got a dead or alive copy of this thing."

Common triggers:

Restoring a DC from backup without properly cleaning metadata
Manually adding objects across domains without replication awareness
A lingering object from a DC that was removed improperly

Less common variations

Sometimes the error pops during AD replication itself. You'll see it in dcdiag or repadmin /showrepl output, not when creating an object. In that case, the fix is different:

Run repadmin /syncall /AdeP to force a full sync.
If that fails, check for conflict objects (prefixed with CNF:). You should delete those manually via ADSI Edit.
If the object is a system-critical one (like a domain controller account), you might need to use ntdsutil metadata cleanup.

Another oddball case: the error appears after demoting a domain controller but not cleaning its metadata. The old DC's objects linger as tombstones. Run ntdsutil metadata cleanup to remove the old DC's references.

ntdsutil
metadata cleanup
connections
connect to server 
quit
select operation target
list domains
select domain 
list servers for domain in site
select server 
quit
remove selected server

How to prevent this from coming back

A few habits I've learned the hard way:

Always demote domain controllers using the GUI or dcpromo /force properly. Never just delete the VM.
Enable the garbage collection log for tombstone lifetimes. Set HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics\9 Garbage Collection to 3 for verbose logging.
Run repadmin /showrepl weekly. If you see any objects in a "conflict" or "deleted" state, investigate before they linger.
Keep your domain controllers on the same AD functional level. Mixing 2012 R2 and 2022 can cause tombstone lifetime mismatches.

I've seen this error on everything from Server 2012 to Server 2022. The fix hasn't changed in over a decade—because the root cause hasn't either. Clean your metadata, watch your replication, and you'll rarely see 0X000020A9 again.