Fix STATUS_DS_DOMAIN_RENAME_IN_PROGRESS (0XC0000801)

You're staring at a black screen or an error popup that says STATUS_DS_DOMAIN_RENAME_IN_PROGRESS (0XC0000801) when trying to log into a domain controller or join a domain machine. Yeah, that's frustrating. The OS thinks a domain rename is still happening, even if it crashed halfway through. Let's fix it now.

Short fix: Force-complete or abort the rename

The quickest way is to edit the registry on the domain controller that's stuck. Open Regedit, go to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Look for a value named DSA RPC Rename State. If it's set to anything other than 0, that's your problem. Double-click it and set it to 0. Reboot the DC.

That's it. After reboot, the error should vanish and you can log in normally.

If registry edit doesn't work (maybe the key doesn't exist or you can't get in at all), boot into Directory Services Restore Mode (DSRM). At the login screen, click "Switch User" then "Other User" and use .\Administrator with the DSRM password you set during promotion. Then run ntdsutil:

ntdsutil
ntdsutil: domain management
domain management: connection
connection: connect to server localhost
connection: quit
domain management: abort rename attempt
domain management: quit
ntdsutil: quit

Reboot again. The rename abort cleans up the state flags. This works on Windows Server 2016 through 2022.

Why this happens

Domain rename in Active Directory is a multi-step process. When you run rendom /execute or rendom /prepare, it writes a state value that tells every DC and member machine: "A rename is in progress, don't trust the domain yet." If the process crashes—due to power loss, a network timeout, or a botched GPO update—that state value stays at 1 or 2 instead of resetting to 0. Every subsequent authentication attempt sees this flag and refuses to continue. The error code 0xC0000801 literally maps to "Domain Rename In Progress." The fix is to manually reset that flag.

The registry value DSA RPC Rename State is the in-memory cache of the state from the directory partition. Setting it to 0 tells the Directory System Agent (DSA) that no rename is pending. But the underlying state in the AD database might still be set—that's why the ntdsutil abort rename attempt command is more thorough. It removes the rename objects from the directory partition entirely.

Less common variations

Sometimes the error appears not on a DC but on a member server or workstation trying to authenticate. That's because the machine's local security authority (LSA) cached the rename state from a DC. In that case, you don't touch the DC's registry—you fix the client:

1. Disconnect the client from the network.
2. Reboot the client.
3. Log in with cached credentials (local admin works).
4. Run in an admin command prompt: gpupdate /force and then klist purge.
5. Reconnect to the network and try logging in again.

If that fails, delete the machine's computer account from AD, disjoin the domain, rejoin.

Another rare cause: the rename state was set via Group Policy, not through the rendom tool. Check if a GPO is pushing a registry value under HKLM\Software\Policies\Microsoft\System\DNS or HKLM\System\CurrentControlSet\Services\Tcpip\Parameters with a Domain key that points to the old domain name. Remove those GPO settings, then force gpupdate.

Prevention

Domain rename is risky. Microsoft's official guidance is to avoid it—stand up a new domain instead. If you absolutely need it, follow these rules:

• Run rendom /prepare on every DC, one at a time, waiting for replication to complete between each. Check with repadmin /syncall.
• Never reboot a DC during the rename process unless the tool tells you to.
• Always run rendom /execute from a DC that's the RID master and PDC emulator. Don't run it from a GC that's not also those roles.
• Before starting, take a backup of the system state of all DCs. Use Windows Server Backup or a third-party tool.
• If you see the error, immediately check event ID 1126 in the Directory Service log. It tells you exactly which DC still has the rename flag.

One last thing: if you've already aborted the rename and the error persists, check DNS. Stale DNS records for the old domain name can cause authentication to fail with the same code because the client tries to resolve the old domain and hits a DC that still thinks a rename is happening. Flush DNS and delete old A records for the old domain name.