Fix ERROR_INVALID_DOMAIN_STATE (0X00000549) in Active Directory
This error hits when a domain controller or member server tries a security operation on a domain that's in the wrong state. Usually during demotion or replication.
When this error shows up
You're trying to demote a domain controller running Windows Server 2016 or 2019. You run DCPROMO or use Server Manager to remove Active Directory Domain Services. Midway through, you get hit with ERROR_INVALID_DOMAIN_STATE (0X00000549) - The domain was in the wrong state to perform the security operation. Or maybe you're setting up a new domain controller in an existing domain and replication fails with the same code.
I've seen this most often in two situations:
- After a failed demotion where the server is still listed in Active Directory but the AD DS service is gone or corrupted.
- When you try to forcefully remove a domain controller that's offline and then clean it up, but another DC still thinks the old one is active and rejects your new operation.
What's really going on
The domain state check happens at the start of any security operation — demotion, promotion, replication, or trust changes. Active Directory keeps a state machine for each domain controller. If something thinks the domain is still in a transitional phase (like a previous demotion didn't finish cleanly), it blocks the new operation. The error code 0X00000549 literally means The domain was in the wrong state
. It's not a permissions issue or a network problem. It's a flag that someone — or something — left the domain in a messy condition.
The root cause is almost always a partial demotion or a domain controller that was shut down or deleted without proper metadata cleanup. The domain's internal version counters or partition state flags get stuck.
How to fix it — the real fix
Skip the obvious stuff like restarting the server or checking DNS. That won't help. You need to either force a clean demotion by resetting the domain state or clean up the metadata from another DC. Here's the exact sequence that works.
Step 1: Check if the server still has AD DS installed
Open PowerShell as administrator. Run:
Get-WindowsFeature -Name AD-Domain-ServicesIf it shows Install State: Installed, then the role is still there but broken. If it shows Removed, you're in the second scenario — metadata cleanup needed.
Step 2: Force a clean demotion (if the role is still installed)
Do not use Server Manager again. It'll hit the same error. Use the command-line version of DCPROMO with a force flag. On the problematic server, open an elevated command prompt and type:
dcpromo /forceremovalYou'll get a warning about losing replication data. Say yes. After it finishes, the server will reboot. At that point, the AD DS role is gone but the server is still an orphan in the domain.
Step 3: Clean the metadata from a healthy domain controller
Log into any working domain controller. Open Active Directory Users and Computers. Right-click the domain name at the top, then choose Operations Masters. Check each role tab (RID, PDC, Infrastructure) and make sure none point to the failed server. If they do, transfer them to a healthy DC.
Next, open Active Directory Sites and Services. Expand Sites, then your site, then Servers. Find the failed server's name. Right-click it and choose Delete. Say yes to the warning.
Step 4: Clean the NTDS Settings object using ADSI Edit
If step 3 fails with an access denied or still sees the server, use ADSI Edit. Open ADSI Edit from the Tools menu. Connect to Default naming context. Navigate to:
CN=Configuration,DC=yourdomain,DC=com -> CN=Sites -> CN=Default-First-Site-Name -> CN=ServersFind the failed server's CN. Delete its entire container. That removes all links to it.
Step 5: Use PowerShell if the GUI isn't enough
On a healthy DC, run PowerShell as admin. Use the Remove-ADDomainController cmdlet. Replace SERVERNAME with the actual name:
Remove-ADDomainController -Identity SERVERNAME -ForceYou'll see a confirmation. Type Y. This cmdlet clears the metadata from the domain partition, the configuration partition, and the DNS records. After it runs, you can re-promote the original server without the 0X00000549 error.
What if it still fails?
If you're still stuck, check two things:
- Time sync: If the server's clock is off by more than 5 minutes from the domain's PDC emulator, Kerberos fails and the domain state check can't complete. Sync it manually to the PDC using
w32tm /resync. - Replication latency: After cleanup, wait 15 minutes for the changes to replicate. Then run
repadmin /syncall /AdePon a healthy DC to force replication to all partners.
In rare cases, you might need to boot the broken server into Directory Services Restore Mode (DSRM) and delete the NTDS.DIT file manually. But I've only done that twice in ten years. The steps above cover 99% of 0X00000549 cases.
Was this solution helpful?