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.ditlives 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.
- 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.
- Back up the current database. Before touching anything, copy
C:\Windows\NTDS\NTDS.ditto another drive (not the system drive). If the defrag fails, you need this to attempt a restore from backup. - Run ntdsutil offline defrag. Open Command Prompt as Administrator. Run:
- Replace the old database. After compact finishes, stop the NTDS service (if it's running) and copy the compacted file over the original:
- 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 /showreplto confirm replication is working.
copy C:\Windows\NTDS\NTDS.dit D:\backup\NTDS.dit.bak
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.
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
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 /AdePto 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.