STATUS_DOMAIN_EXISTS (0XC00000E0) – Domain Already Exists Fix

What's Actually Happening Here

You're trying to join a domain—maybe a test lab, a restored server, or a leftover machine that was already joined to the same AD forest—and Windows throws 0XC00000E0. The error name says it all: STATUS_DOMAIN_EXISTS. The OS thinks the domain you're joining already exists in its own credential cache, or Active Directory has a stale computer object with the same name.

I see this most often after re-deploying a domain controller with the same name as a previous one, or when someone tries to join a machine that's still listed in AD under a different site. The fix isn't complicated—you just need to clean up whichever side is holding the duplicate.

Here's the flow: start with the 30-second check, then move to the 5-minute fix, then the 15-minute reset if nothing else works.

Fix 1 (30 seconds) – Check the Domain Name You're Typing

This sounds stupidly simple, but I've watched people waste an hour chasing ghosts because they typed corp.local instead of corp.com. The error fires when Windows contacts a domain controller and the target domain already matches the machine's cached domain membership. If you're joining a different domain tree in the same forest, you'll get this error if you accidentally use the parent domain name.

What to do:

1. Open System Properties (Win + R → sysdm.cpl).
2. Click Change under "To rename this computer or change its domain."
3. Make sure you're typing the exact NETBIOS or FQDN of the domain you're joining. If you're unsure, run nltest /dsgetdc:targetdomain from an already-joined machine and check the output.
4. Try joining with just the NETBIOS name (e.g., CORP) instead of the FQDN (corp.company.com). Sometimes the DNS suffix handling chokes.

If it still fails, move on.

Fix 2 (5 minutes) – Delete the Local Cached Domain Credentials

Windows stores a local copy of the domain SID and name in the registry after a successful join. If the machine was previously joined to the same domain and then removed improperly (or the computer account was deleted in AD without a proper unjoin), that cached entry persists. The next join attempt sees the stale data and refuses.

The fix:

1. Open Regedit as Administrator.
2. Go to: HKEY_LOCAL_MACHINE\SECURITY\SAM\Domains\Account
3. You'll see a key called F. That's the cached domain info. Stop. You don't want to delete the whole key—just the value that holds the stale SID. Look for a binary value named F (yes, it's a value named F).
4. Instead of messing with the SAM hive directly (which can brick your OS if you get it wrong), use the safer method:

netdom remove %computername% /domain:stale_domain_here /UserD:admin /PasswordD:*

Replace stale_domain_here with the domain name you think is cached. If you don't know, run nltest /domain_trusts first to list cached domains.

If netdom remove fails because the machine can't contact the old DC, you'll need to force-clear the cache manually:

reg delete "HKLM\SECURITY\SAM\Domains\Account" /v F /f

Then reboot. After reboot, the machine has no domain affiliation—you can join fresh.

Why this works: The F value contains the cached machine account password and domain SID. Deleting it forces Windows to treat the machine as a workgroup computer, letting the join process create a new secure channel.

Fix 3 (15+ minutes) – Clean Up the Stale Computer Object in AD

If the local machine is clean but the error still appears, the problem is on the domain side. Active Directory has a computer account with the same name, and the domain controller is rejecting the join because it sees that account as already existing and valid (or in a conflict state).

Steps:

1. On a domain controller or a machine with RSAT tools installed, open Active Directory Users and Computers (dsa.msc).
2. Navigate to the Computers container (or wherever the machine account lives).
3. Find the computer object with the same name as the machine you're trying to join. If you see a Conflict attribute in the properties, that's your smoking gun.
4. Delete the computer object entirely. Do NOT try to reset it—just delete it and let the new join create a fresh one.
5. Wait 5-10 minutes for AD replication to complete if you have multiple DCs. Alternatively, force replication with repadmin /syncall.
6. Back on the client machine, run ipconfig /flushdns and then try joining again.

The reason step 3 works: The domain controller authenticates join requests by checking for an existing computer object. If the object exists and has a different SID than the one the client presents (which it will, because you've never successfully joined this machine), the DC returns 0XC00000E0. Deleting the object removes the conflict.

If you can't find the computer object in the GUI, run this from an elevated command prompt on a DC:

dsquery computer -name "yourcomputername"

It'll return the full distinguished name. Delete with:

dsrm "CN=YOURCOMPUTERNAME,CN=Computers,DC=yourdomain,DC=com"

If None of That Works – Rebuild the Local Credential Manager

This is the nuclear option, but I've had to do it twice in ten years. Sometimes the cache lives in the Credential Manager store, not the SAM hive. Open Control Panel → Credential Manager → Windows Credentials. Look for entries with TERMSRV or MicrosoftAccount or domain-style names. Delete anything that looks like the target domain. Reboot.

If you're still stuck, the machine's local security account manager may have a corrupted domain cache. Run secedit /configure /cfg %windir%\inf\defltbase.inf /db defltbase.sdb /verbose to rebuild the security policy database, then reboot and try the join again.

One final gotcha: if this is a domain controller itself (not a member server), you can't resolve this by joining—you need to demote it first with dcpromo /forceremoval and then re-promote. The error in that case means AD DS sees another DC with the same name in the forest. Don't try to join a DC; that's not how it works.

Summary: 90% of the time it's either a typo in the domain name or a cached entry in the local registry. Fix 1 is free. Fix 2 is safe if you're careful. Fix 3 requires AD admin rights. Don't skip the reboot after clearing cache—the change doesn't apply until the LSASS process re-reads the hive at boot.