Active directory database corruption

Question

I’m trying to fix an issue where Active Directory logs Event ID 467, indicating database page corruption in ntds.dit. When I attempt to boot normally, authentication fails for domain services. Please tell me how to resolve this.

I’ve read that I need to boot into Directory Services Restore Mode (DSRM) and run an offline integrity check using esentutl, but I’m not sure of the exact steps.

Could someone kindly guide me through performing the database repair safely without risking data loss ?

Answer 1

Hi Lysa Analyst,

You’re right that the safest way forward is to boot into Directory Services Restore Mode (DSRM) and run an offline integrity check with esentutl, but let me walk you through the steps clearly.

First, restart the domain controller and press F8 to boot into DSRM. Log in with the DSRM administrator credentials. Once in, open a command prompt and navigate to the folder containing ntds.dit (usually %SystemRoot%\NTDS). Run esentutl /g ntds.dit to perform an integrity check. If errors are found, you can attempt a repair with esentutl /p ntds.dit, but only after ensuring you have a full system state backup, repairs can truncate data if corruption is severe.

After repair, run esentutl /d ntds.dit to defragment the database offline, followed by esentutl /cc <path to checkpoint file> to reset the checkpoint. Once complete, restart the server normally and verify that domain services authenticate correctly. If corruption persists, restoring from a recent system state backup may be the safer option.

As a best practice, always back up before attempting repair, and consider running repadmin /syncall after recovery to ensure replication consistency across domain controllers.

I hope the response provided some helpful insight. If you find this answer useful, please hit “accept answer” so I know it addressed your concern.

Jason.

Answer 2

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:

1. 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.
2. 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.dit and the log files is available at startup.
   • Verify the NTDS folder is not compressed.
3. 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%.
4. 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.
5. Run semantic database analysis
   • Run:

          ntdsutil "sem d a" go
     

   • If errors are reported, run:

          ntdsutil "sem d a" "go f"
     

6. 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 TEMP and TMP does 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.dit over the old database file in the original database path
     • Edb.chk does not need to be deleted
   • Restart AD DS or reboot out of DSRM.
7. If normal startup still fails, try database recovery
   • Run:

          ntdsutil
          files
          recover
     

   • Quit and restart.
   • If needed, Esentutl recovery can be used:

          esentutl /r path\ntds.dit
     

     where path is the current location of ntds.dit.
   • Then delete the .log files from the WINDOWS\Ntds folder and restart.
8. Use lossy repair only as a last resort
   • Microsoft recommends contacting support before doing this: Contact Microsoft Support
   • Lossy repair examples include:

          ntdsutil files repair
     

     or on Windows Server 2003:

          esentutl /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.
9. 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 /p or ntdsutil files repair as 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