Fix ERROR_DS_NC_STILL_HAS_DSAS (0x00002162) when demoting a domain controller

When this error hits

You're running dcpromo or the new AD DS removal wizard on a domain controller (let's say Server 2016 or 2019), and halfway through the demotion, you get slapped with:

ERROR_DS_NC_STILL_HAS_DSAS (0x00002162)

Translation: Active Directory Domain Services couldn't remove this DC because some naming context (domain or application partition) still thinks there are other domain controllers hanging off it. I ran into this last month on a client's 2008 R2 DC that had a long-dead child domain controller nobody remembered. The demotion just sat there, throwing the same error every time.

Root cause in plain English

Every domain controller has a NTDS Settings object under the server's container in Configuration. That object lists which naming contexts it hosts. When you demote, AD checks if any of those naming contexts still point to other DCs. If a reference is stale—say a DC that was forcefully removed or a child domain that still thinks it belongs—the demotion stops cold. It's a safety catch to prevent you from accidentally killing replication for an entire domain.

How to fix it — step by step

Step 1: Identify the orphaned DSA

Open a command prompt as Administrator. Run:

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

Look for any naming context that shows a server you're trying to remove, or a server that doesn't exist anymore. That's your culprit.

Step 2: Remove the orphaned server reference

Stay in ntdsutil. Once you've selected the orphaned server, run:

remove selected server

You'll get a confirmation prompt. Type Yes. This removes the NTDS Settings object for that server from the configuration partition. If it succeeds, you're golden. If it fails with a permission error, you might need to run as a domain admin or use ADSI Edit (next step).

Step 3: If ntdsutil won't remove it — ADSI Edit

Sometimes ntdsutil won't cooperate if the server object is really mangled. Open ADSI Edit and connect to the Configuration partition. Navigate to:

CN=Configuration,DC=<your-domain>,DC=<suffix>
CN=Sites
CN=<site-name>
CN=Servers
CN=<orphan-DC-name>
CN=NTDS Settings

Right-click the NTDS Settings object and delete it. Then delete the server object itself under the Servers container. Yes, even if the server is still running — if it's not going to be a DC anymore, you're just cleaning up metadata.

Step 4: Force the demotion again

Now go back and run the demotion wizard. It should pass the naming context check. If it still fails, you may have application partitions (like DomainDnsZones or ForestDnsZones) that reference the same server. Run repadmin /showrepl to see all naming contexts. Then use ntdsutil's domain management to remove those references too:

ntdsutil
domain management
connections
connect to server <your-working-dc>
quit
list naming contexts
delete nc <nc-dn>

Make sure you really want to delete that NC — it'll kill replication for that partition across all DCs.

What to check if it still fails

First, run repadmin /options on the DC you're demoting. If the DISABLE_NTDSCONN_XLATE option is set, turn it off. I've seen that block the demotion silently. Second, check DNS — if the DC's A record points to a different IP, the demotion might fail because it can't find itself. Third, if you're dealing with a child domain, make sure the parent domain's DCs can still reach this one. Firewall rules can lock you out. Finally, if all else fails, do a forced demotion with dcpromo /forceremoval (or Remove-ADDSDomainController -ForceRemoval in PowerShell), then manually clean up metadata from another DC using the steps above. Forced removal works, but you'll have lingering references that need manual cleanup later. Don't skip that cleanup — it'll bite you when you try to add a new DC later.