Fix 0XC00002AD: DC Won't Boot After AD Restore

Quick answer: In almost all cases, the cleanest fix is to restore the DC from a valid system state backup (pre-rollback) and perform a non-authoritative restore in DSRM mode. If no backup exists, force-demote the box, remove AD metadata, and re-promote.

That error code — 0XC00002AD (STATUS_DS_CANT_ON_RDN) — pops up when a domain controller boots after a restore where the directory database has been rolled back to a state that breaks the replication topology. The classic trigger: someone restored a snapshot or system state backup that's older than the other DCs' USNs, causing a USN rollback. The DC gets stuck at the login screen with that error, and no amount of rebooting helps.

You'll see this in the event log as NTDS (800) - Event ID 2095 or similar. The DC won't start the Directory Service, and you're locked out.

Step-by-Step Repair

1. Boot into DSRM (Directory Services Restore Mode). Reboot the DC, hit F8, select Directory Services Restore Mode. You need the DSRM password from when it was promoted. If you don't have it, you're hosed — you'll need to reset it via the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa value DsrmPassword (but that requires a second boot into a special recovery environment, which is a pain).
2. Try a non-authoritative restore. If you have a system state backup from before the rollback (likely from the same night), log into DSRM, open CMD, and run:

wbadmin start sysrecovery -version:<date-time> -systemState -backupTarget:<drive>

Then after restore, reboot normally. The DC should start and replicate from a healthy partner (non-authoritative means it takes current data from others). This fixes the USN rollback because it resets the invocation ID and forces a full sync.

If No Backup Exists — Force Demote and Rebuild

No backup? Then you're rebuilding. Here's the brutal truth: you can't just remove the DC from the domain while it's down. Do this from another DC or the primary:

1. On a working DC, open ADSI Edit and delete the computer object of the broken DC under CN=Computers.
2. Also delete the NTDS Settings object under CN=Servers\CN=<brokenDC> in the Sites container.
3. On the broken DC (if it ever boots), run dcpromo /forceremoval from command line. If it won't boot at all, you'll need to reinstall Windows from scratch.
4. After reinstall (or force removal), run ntdsutil to clean up metadata:

ntdsutil
metadata cleanup
remove selected server <brokenDC>   
quit

Then promote the machine back as a fresh DC.

Alternative: Time Server Check (Rare)

This isn't normally the fix, but I've seen one case where the DC's clock was off by 5 minutes after a hardware battery failure, causing Kerberos and replication failures that mimicked this error. Check with w32tm /query /status in DSRM. If off, set it to the PDC emulator. But don't waste time here — 95% of the time it's a rollback.

Prevention Tip

Never restore a DC from a snapshot or backup older than the tombstone lifetime (usually 60-180 days). Even better: install the Active Directory Recycle Bin and stop doing system state restores altogether — you can undo accidental deletions without touching DC state. And always take a fresh system state backup before any patch or change that touches AD.

Also, enable the USN rollback protection feature if you're on 2008 R2 or later — it's a registry key:

HKLM\System\CurrentControlSet\Services\NTDS\Parameters
"DisableUSNChangeTracking"=dword:00000001

That actually prevents the DC from accepting a rolled-back state, but it'll likely cause the DC to refuse to boot instead of throwing this error — which is better for diagnosis.

Bottom line: this error is a death sentence for a DC unless you have a good backup. Plan for that reality.