Use the least-destructive recovery path first. Do not start with a lossy repair. Microsoft states that lossy repair with Ntdsutil or Esentutl deletes data and leaves the domain controller in an unsupported state until it is rebuilt.
Recommended sequence:
- Boot into Directory Services Restore Mode (DSRM)
- Restart the domain controller.
- Press F8 during startup.
- Select Directory Services Restore Mode.
- Sign in with the DSRM local administrator password.
- Open Command Prompt and inspect database paths
- Run:
ntdsutil files info - Confirm the reported database path, log path, and working directory exist and are correct.
- Verify the drive hosting
ntds.ditand the log files is available at startup. - Verify the NTDS folder is not compressed.
- Run:
- Verify permissions before repair
- Confirm the required folders have correct permissions, especially:
- the root of the drive containing the NTDS folder
-
%WINDIR% - the NTDS database and log file folders
- The System account must have Full Control on the drive root and
%WINDIR%.
- Confirm the required folders have correct permissions, especially:
- Run an integrity check first
- Run:
ntdsutil files integrity - If the integrity check reports no errors, restart normally and test domain services.
- If it reports errors, continue.
- Run:
- Run semantic database analysis
- Run:
ntdsutil "sem d a" go - If errors are reported, run:
ntdsutil "sem d a" "go f"
- Run:
- Perform offline defragmentation
- Back up Active Directory first. A System State backup is supported.
- In DSRM or with AD DS stopped, open Command Prompt.
- If the volume used by
TEMPandTMPdoes not have enough free space, set them to another drive first:md d:\temp set tmp=d:\temp set temp=d:\temp - Then run:
ntdsutil activate instance ntds files info compact to <drive>:\<directory> - Example if the path contains spaces:
compact to "c:\new folder" - After a successful defragmentation:
- quit
ntdsutil - delete old log files in the log directory:
del drive:\pathToLogFiles\*.log - copy the new
Ntds.ditover the old database file in the original database path -
Edb.chkdoes not need to be deleted
- quit
- Restart AD DS or reboot out of DSRM.
- If normal startup still fails, try database recovery
- Run:
ntdsutil files recover - Quit and restart.
- If needed, Esentutl recovery can be used:
whereesentutl /r path\ntds.ditpathis the current location ofntds.dit. - Then delete the
.logfiles from theWINDOWS\Ntdsfolder and restart.
- Run:
- Use lossy repair only as a last resort
- Microsoft recommends contacting support before doing this: Contact Microsoft Support
- Lossy repair examples include:
or on Windows Server 2003:ntdsutil files repairesentutl /p - Risk: this deletes data from the database. If the domain controller starts afterward, it is still in an unsupported configuration and must be rebuilt as soon as possible.
- If no clean recovery is possible
- If other healthy domain controllers exist, remove Active Directory from the damaged server and reinstall it.
- If no system state backup exists and no healthy domain controllers exist, Microsoft recommends rebuilding the domain rather than relying on lossy repair.
Key safety points:
- Start with integrity check, semantic analysis, and offline defragmentation.
- Use recover before any lossy repair.
- Treat
esentutl /porntdsutil files repairas emergency-only actions because they can cause permanent data loss. - Never copy database or log files from one domain controller to another.
References:
- Error when you start your Windows-based domain controller: Directory Services cannot start
- Perform offline defragmentation of Active Directory database
- How to use Ntdsutil to manage Active Directory files from the command line in Windows Server 2003
- Troubleshoot Jet database errors and recovery steps