NTDS Error 0X000021AF – Missing DC Settings Object

1. Botched DCPROMO or Demotion

This is the #1 reason you're seeing 0X000021AF. What's actually happening here is that Active Directory wrote the NTDS Settings object into the database during promotion, but then something went wrong — maybe you force-rebooted mid-promotion, or demoted the server but left AD files behind. The Directory Service boots up, looks for its own NTDS Settings object in the Configuration partition under CN=Servers,CN=Default-First-Site-Name,CN=Sites, and finds nothing. Dead stop.

Real-world trigger: You ran DCPROMO on a Server 2019 box, it hung at "Configuring the service", you hit reset, and now it won't boot past the black screen with the error.

The Fix

Don't bother with GUI tools — they're useless here because the service won't start. Boot into Directory Services Restore Mode (DSRM). For Server 2016 and above, that means pressing F8 during boot (it's still there, just fast) or using bcdedit /set safeboot dsrepair from recovery console.

1. Boot to DSRM with the DSRM password you set during promotion (or use the recovery password if you forgot it).
2. Open an elevated command prompt.
3. Run ntdsutil → metadata cleanup → select operation target.
4. List sites, then servers, find this DC, and select it.
5. Exit and run remove selected server. This kills the orphaned metadata in the database.
6. Now exit all the way out of ntdsutil.
7. Run reg add HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters /v Replica Machine Object /t REG_SZ /d CN=NTDS Settings,CN=YOURDCNAME,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=yourdomain,DC=com /f — but replace YOURDCNAME and yourdomain parts with your real values. This tells AD where to look (and it'll recreate the object).
8. Reboot to normal mode. It should boot clean.

Why step 7 works: The registry value points to a non-existent object, but on first boot the Directory Service creates it because it sees the replica machine object is missing in the database. It's a self-healing mechanism that only fires when the service starts and finds the path empty.

2. Corrupted NTDS Database from Bad Restore

Second most common: you restored Active Directory from a system state backup that was taken on a different DC, or the backup was incomplete. The database is missing the Settings object for this DC because the backup contained a different server's identity.

Real-world trigger: You’re cloning a VM template and restoring AD from backup to spin up a new DC, but the backup was from an old DC named DC01, and you renamed this one to DC02. The NTDS Settings object still points to DC01.

The Fix

Same start — boot to DSRM. But here, you need to check the database integrity first before touching anything.

1. In DSRM, open cmd as admin.
2. Run ntdsutil → files → integrity. If it reports errors, run semantic database analysis then go fixup.
3. Now check the Settings object exists: dsquery * CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=yourdomain,DC=com -filter "(objectClass=server)" -attr cn. If your DC name isn't in the list, you're in the same boat as cause #1.
4. If the DC name is there but the Settings object is missing, use ADSI Edit (install via dism /online /add-capability /CapabilityName:Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0 from an elevated prompt). Connect to the Configuration partition, navigate to CN=Sites → CN=Default-First-Site-Name → CN=Servers → CN=YOURDCNAME. Right-click YOUDCNAME → New → Object → choose nTDSDSA. Default attributes are fine.
5. Reboot to normal mode.

Why the object is missing: The database thinks it's a different server. The DSA object is literally the NTDS Settings child object under the server object. Without it, the Directory Service can't start because it has no identity in the replication topology.

3. Sysvol or NETLOGON Share Corruption

Less common, but I've seen it on Server 2012 R2 after a power loss. The NTDS Settings object is fine, but the Sysvol folder structure is wrecked. The service fails trying to read Group Policy objects from Sysvol during boot, and the error code gets misreported as 0X000021AF because the log is ambiguous.

Real-world trigger: A dirty shutdown on a Server 2012 R2 DC, then on reboot the error shows up. Event Log shows 0X000021AF but also warning 1002 about DFSR replication.

The Fix

1. Boot to DSRM.
2. Check Sysvol: dir C:\Windows\SYSVOL\sysvol\yourdomain.com. If it's empty or missing folders, you need to restore Sysvol from backup or force a replication.
3. Run net share to see if SYSVOL and NETLOGON shares are still there. If missing, run dfsradmin membership list to see if the content set is missing.
4. Use dfsradmin membership set /rgname:domain system volume /rfname:sysvol share /memname:YOURDCNAME /isdeleted:false /isfolder:false to re-create the membership, then dfsradmin membership reback.
5. Restart the DFSR service and reboot to normal mode.

Why this fixes it: When Sysvol is broken, the Directory Service waits for Sysvol to initialize before continuing. If Sysvol never comes up, the service times out and throws a generic error that looks like a missing Settings object.

One last thing: If none of these work, check if the server's NTDS\ntds.dit file is on a compressed volume — Active Directory hates compression. Right-click C:\Windows\NTDS → Properties → Advanced → uncheck Compress contents. Reboot to DSRM and run esentutl /r edb to replay the log files, then try normal boot again.