0X00000A85: Can't unjoin domain controller from domain

Cause #1: You're trying to unjoin a domain controller without demoting it first

This is the most common cause and the one most people hit. What's actually happening here is that Windows sees the machine as a domain controller (DC) and refuses to let you leave the domain while it's still holding AD roles. The error code 0X00000A85 maps to NERR_SetupDomainController, which literally means “This machine is a domain controller and cannot be unjoined from a domain.”

You can't just go into System Properties and click “Change” next to domain membership — that button is grayed out or throws this error when you try. The reason step 3 works is that you must first demote the DC using Server Manager or PowerShell, then unjoin.

Fix:

1. Open Server Manager. Click Manage in the top-right corner, then Remove Roles and Features.
2. Go through the wizard until you reach Server Roles. Uncheck Active Directory Domain Services.
3. The wizard will ask if you want to demote the domain controller. Accept and proceed. This runs a real DC demotion — it doesn't just remove the role.
4. During demotion, you'll be asked if this is the last DC in the domain. If it is, check Delete the domain. If not, the machine will just leave the domain and the forest stays intact.
5. Reboot. After reboot, the machine is a regular member server or workstation. Now you can unjoin via System Properties or Remove-Computer in PowerShell.

If you're in a hurry and comfortable with PowerShell, run:

Uninstall-ADDSDomainController -DemoteOperationMasterRole:$true -ForceRemoval

That -ForceRemoval flag is dangerous — it skips replication checks. Only use if the DC is dead and you can't bring it back online gracefully.

Cause #2: The DC still holds FSMO roles or is a Global Catalog server

Sometimes the demotion wizard fails because this DC is the only one holding certain Flexible Single Master Operations (FSMO) roles, or it's the only Global Catalog server. The demotion process tries to transfer those roles to another DC, but if there's no other DC reachable, it bails out with 0X00000A85.

The real trigger here is when you're trying to demote the last remaining DC in an environment, or you've already removed other DCs without transferring roles first.

Fix:

1. Open Active Directory Users and Computers. Right-click the domain name, go to Operations Masters. Check RID, PDC, and Infrastructure tabs. If this DC holds any of those roles, transfer them to another DC using Change.
2. Open Active Directory Sites and Services. Expand Sites > your site > Servers > your DC > NTDS Settings. Right-click and check Global Catalog — if it's checked, uncheck it and force replication.
3. After transferring roles, try the demotion again via Server Manager.
4. If you can't transfer roles because the other DC is dead or unreachable, use the -ForceRemoval flag in PowerShell. Then you'll need to manually clean up AD metadata (see Cause #3).

Cause #3: Lingering AD metadata from a dead DC blocks demotion

If the DC you're trying to unjoin has been offline for a while (or was forcibly removed), AD may still have stale metadata pointing to it. The demotion wizard sees this and refuses to proceed because it thinks the DC is still active. This is a classic case of AD cleanup being out of sync with the actual machine state.

I've seen this happen most often after a power failure where a DC never came back cleanly, and someone forcibly removed it from AD without cleaning up the metadata.

Fix:

1. On a working DC, open ADSI Edit. Connect to the Default Naming Context.
2. Navigate to CN=Computers,DC=yourdomain,DC=local. Find the dead DC's computer object and delete it.
3. Then navigate to CN=Servers,CN=your site,CN=Sites,CN=Configuration,DC=yourdomain,DC=local. Find the server object and delete it.
4. Open a command prompt as Administrator on a working DC and run:

ntdsutil
metadata cleanup
connections
connect to server <working-dc-name>
quit
select operation target
list domains
select domain <number>
list sites
select site <number>
list servers in site
select server <number>
quit
remove selected server
quit
quit

This nukes the old DC metadata. After that, return to the problematic machine and run the demotion with -ForceRemoval if the normal route still fails.

Quick-reference summary table

One more thing: If you're absolutely certain this machine should never have been a DC (maybe it was promoted by accident), you can bypass the check entirely by booting into Directory Services Restore Mode (DSRM) and manually removing the AD database files. That's a nuclear option and I don't recommend it unless you enjoy rebuilding the machine from scratch. But it does work — I've done it once when a lab DC went rogue and refused all demotion attempts.