What's 0xC0000404 Really Telling You?
When you try to create a user, group, or computer in Active Directory and get STATUS_DS_NAME_NOT_UNIQUE (0xC0000404), the directory is saying: "There's already an object with this exact name, and I'm not going to let you create another." That's it. It's not a cryptic permissions issue or a DNS problem. It's a duplicate.
I've seen this most often in two scenarios. First, when someone manually creates an account that matches a deleted one that hasn't fully cleared from the recycle bin. Second, and more annoyingly, when replication is lagging and two domain controllers create the same-named object at nearly the same time. One wins, the other gets this error.
The real kicker: the error message doesn't tell you which object already has the name. So the fix is about finding that original object and either renaming it or removing it, depending on what you actually need.
Quick Fix (30 seconds) — Check the Obvious
Before you go down the rabbit hole, do a quick search in Active Directory Users and Computers (ADUC) for the exact name you're trying to use.
- Open ADUC (dsa.msc).
- Right-click the domain root and select Find.
- Type the full name in the Name field, set the scope to Entire Directory, and hit Find Now.
If you see an object with that name, you've found your culprit. If it's a stale account that's no longer needed, right-click and delete it. If it's in the Recycle Bin, you can restore it and rename it, or just purge it. Deleting from the recycle bin requires enabling the Active Directory Recycle Bin feature and using PowerShell: Remove-ADObject -Identity ". But that's a side quest—if you don't need the old object, skip it and just create your new one with a slightly different name if you're in a hurry.
Honestly, this simple search catches about half the cases I run into. If nothing shows up there, move to the next step.
Moderate Fix (5 minutes) — Use ADSI Edit to Find Hidden Duplicates
Sometimes the duplicate isn't visible in ADUC because it's a disconnected object—like a user that's been disabled and moved to a different OU, or a computer that was deleted but not properly cleaned. Those still show up in ADSI Edit, which gives you the raw view of the directory.
Run: adsiedit.msc
Connect to: Default naming context
Navigate: DC=yourdomain,DC=com
Once you're connected, press Ctrl+F to open a search. Set the scope to Subtree, and search for the exact name you're trying to create. Look for any object with that cn or sAMAccountName. If you find it, examine its distinguishedName—that tells you exactly where it lives in AD.
Here's a trick that's saved my butt more than once: the duplicate might be a conflict object, which AD creates when two DCs create the same name and replication merges them. These objects have names starting with CNF: and are hidden from normal views. You'll only see them in ADSI Edit or with a targeted LDAP query.
Search filter: (|(cn=YourName)(sAMAccountName=YourName))
Include: CNF:
When you find a CNF: object, it's garbage—it holds no real data. Just right-click and delete it. The real object is still there, and once the conflict is gone, you can your create your new account normally.
Sometimes the duplicate isn't a user at all. I had a client last month where 0xC0000404 popped up when creating a computer account. Turned out someone had manually created a group with the same sAMAccountName but different display name. The error message won't show you that. Only a raw search will.
Advanced Fix (15+ minutes) — Check and Force Replication
If you still can't find any duplicate, the problem is likely stuck in replication. The error might be coming from a DC that hasn't received a recent deletion or rename from another DC. In a multi-DC environment, this happens more than you'd think.
First, check replication health across all domain controllers:
repadmin /replsummary
repadmin /showrepl
Look for any DC that's failing to replicate with its partners. If you see errors, fix the underlying replication issue first—it might be DNS, network, or a lingering tombstone.
If replication looks healthy but you still get the error, force a replication cycle from the DC that should have the authoritative copy:
repadmin /syncall /AdeP
After that, wait a minute and retry your original operation. If it still fails, you might have a lingering object that only exists on one DC. To detect those, run:
repadmin /removelingeringobjects DCName DC=yourdomain,DC=com /advisory_mode
That command will show you what lingering objects exist without removing them. If you find the duplicate name in that list, run it again without /advisory_mode to purge it. But be careful—only remove lingering objects if you're sure they're not needed. They're typically deleted objects that never got cleaned up, so they're safe to remove.
One more thing: if you're running an older AD functional level (2008 or lower), check if the recycle bin is even enabled. If not, deleted objects are tombstoned for 180 days by default. During that time, the name is still reserved. You can't create a new object with the same name until the tombstone expires or you manually purge it. To force-purge a tombstoned object, you'd need to use ntdsutil and do a metadata cleanup—that's a bit heavy, but I've had to do it twice in my career.
When to Give Up and Rename
If you've spent 15 minutes and still can't find the duplicate, sometimes the pragmatic move is to just rename your new object slightly. Add a number or a different middle initial. It's not elegant, but if the name isn't mandated by some external system (like an HR feed), you're better off moving on. I've seen admins burn an entire afternoon chasing a phantom duplicate that turned out to be a replication bug that a DC reboot resolved.
Remember, the error is precise: the name exists. Trust it. Your job is to find where, and the three steps above cover 95% of the cases. Start with the search, go to ADSI Edit, then look at replication. Skip the network captures and event log spelunking—that's overkill for this error.
If none of that resolves it and you're still stuck, you likely have a deeper AD health issue. Run dcdiag /v and look for any DNS or replication failures. Fix those first, then retry. In my experience, once replication is clean, 0xC0000404 disappears on its own.