0X000020D9: Active Directory database corruption fix

You're staring at a yellow exclamation in Event Viewer, or worse, a domain controller that won't boot into Directory Services Restore Mode. The error says ERROR_DS_DATABASE_ERROR (0X000020D9) — a database error has occurred. This almost always shows up during AD replication, a failed ntdsutil operation, or a sudden power loss on a domain controller running Windows Server 2012 R2 or newer. I've seen it most often after a disk fills up entirely, or when someone force-restarts a DC mid-replication.

What's actually happening

The NTDS.dit file — the Extensible Storage Engine (ESE) database holding all your AD objects — has hit a consistency check failure. ESE is a transactional database (same engine as Exchange). When a write operation gets interrupted (power loss, disk full, drive failure), the transaction log might not replay cleanly. The database's internal checksum or page state flags a corrupt page. Your DC refuses to mount the database because it can't trust the data. This is intentional, not a bug. Better to fail safe than serve bad directory data to clients.

Two common triggers:

• Disk space exhaustion. The transaction logs need room to commit. If the drive where NTDS.dit lives goes below 100 MB free, ESE pauses writes. A subsequent write attempt can corrupt a page.
• Unclean shutdown of the domain controller (power outage, hypervisor snapshot restore without quiescing the DC). The log files don't match the database checkpoint.

The fix: ntdsutil offline defrag

The fastest, safest path — assuming you have a good backup — is to restore a clean copy of the database from a recent system state backup. If you don't have one, the offline defrag is your next option. This re-writes only the active pages into a new NTDS.dit, discarding corrupt pages and freeing unused space. It's not a repair in the traditional sense — it's a compaction that removes bad entries.

1. Boot into Directory Services Restore Mode. Restart the DC. Press F8 before the Windows logo. Select "Directory Services Restore Mode" (DSRM). You'll need the DSRM administrator password — if you forgot it, you're stuck. File a support ticket with Microsoft or restore from bare-metal backup.
2. Back up the current database. Before touching anything, copy C:\Windows\NTDS\NTDS.dit to another drive (not the system drive). If the defrag fails, you need this to attempt a restore from backup.

copy C:\Windows\NTDS\NTDS.dit D:\backup\NTDS.dit.bak

3. Run ntdsutil offline defrag. Open Command Prompt as Administrator. Run:

ntdsutil
activate instance ntds
files
compact to C:\temp
quit
quit

The compact to C:\temp command creates a new NTDS.dit in C:\temp. It might take 30 minutes to several hours depending on database size (500 MB to 10 GB is typical for a small org — big deployments can be 50+ GB). If it errors out saying "database corrupt, cannot compact," you've got physical corruption that even ESE's soft recovery can't fix. Skip to the restore from backup section.

4. Replace the old database. After compact finishes, stop the NTDS service (if it's running) and copy the compacted file over the original:

net stop ntds
copy C:\temp\NTDS.dit C:\Windows\NTDS\NTDS.dit

Delete old log files in C:\Windows\NTDS — the compacted database contains all committed transactions. Old logs will confuse the engine.

del C:\Windows\NTDS\*.log
del C:\Windows\NTDS\*.chk

5. Restart the DC normally. Boot back into normal mode. Open Event Viewer and check for event IDs 1000 (database mounted) or 1173 (replication success). Run repadmin /showrepl to confirm replication is working.

If the defrag fails: restore from backup

If compact errors out, you need a system state backup (from Windows Backup, DPM, or Veeam). Boot into DSRM again. Use wbadmin get versions to list backups. Then:

wbadmin start systemstaterecovery -version:MM/DD/YYYY-HH:MM

Pick the most recent backup before the corruption appeared. If you don't have a backup, your only option is to seize FSMO roles and demote this DC, then rebuild it from scratch. That's a long afternoon I don't wish on anyone.

What to check if it still fails

• Disk health. Run chkdsk C: /f — a failing disk under the database can cause intermittent 0X000020D9 errors even after defrag. I've seen SSDs with bad blocks produce this error repeatedly until replaced.
• Event ID 1040. If you see this in the Directory Service log, the database is trying to mount but the transaction log replay is failing. That usually means a corrupt log file. Delete all logs (after backup) and try again.
• Replication latency. A DC with this error that reboots cleanly might still have replication issues. Run repadmin /syncall /AdeP to force replication. If it fails with 8453 or 8524, the database is still inconsistent — restore time.

The hard truth: 0X000020D9 is your AD crying for help. Ignore it, and the next step is an unrecoverable forest. Do the offline defrag first, but have a backup ready. You won't always get a second chance.