Problems with Jet Engine error -1018 in NTDS.dit once restarting domain controller

Question

An ungraceful shutdown on our Domain Controller caused Jet Engine error -1018 (JET_errFileSystemCorruption) on NTDS.dit (By the way, it is an AWFUL SYSTEM, as it corrupted EVERYTHING!!!!!!), so somehow or another, the domain controller is stuck in DIRECTORY SERVICES RESTORE MODE (DSRM), but when I try to boot it up, the status is designated as DSRM. I tried to boot normally, but, although I attempted to restart it, it reverted back to DSRM as the status. Unfortunately, if I attempt to start the server normally, it automatically takes me back to DSRM!!!!!!!!!!!!!!!!!!!!!!!

I cannot tell you how frustrating it is to not be able to access ANY of our directory services...

What step-by-step procedure should be used to run esentutl integrity checks and restore directory health safely?

Please help!

Thank you!

Answer 1

Hello @Islada Vies

Based on your description, the Jet Engine error -1018 (JET_errFileSystemCorruption) indicates that Active Directory has detected corruption in the NTDS.dit database or the underlying storage subsystem. This is typically associated with disk, storage, controller, or filesystem corruption rather than Active Directory itself.

Before attempting any repair, I'd strongly recommend the following:

• Verify the health of the underlying storage by checking the System Event Log for disk, NTFS, storage controller, or hardware errors.
• Run chkdsk on the volume hosting NTDS.dit to ensure the file system is consistent before working on the database.
• Create a backup or copy of the existing NTDS.dit and log files before running any repair utilities.

Regarding Esentutl:

• Start with a read-only integrity check: esentutl /g C:\Windows\NTDS\ntds.dit
• If integrity checks fail, Microsoft generally recommends restoring the domain controller from a known-good System State backup rather than performing a hard repair.
• esentutl /p (hard repair) should be considered only as a last resort, as it can permanently remove corrupted data and leave the Active Directory database in an unsupported or inconsistent state. If a hard repair is performed, it should be followed by an offline defragmentation (esentutl /d) and additional consistency checks before returning the DC to production.

Since your domain controller is automatically booting into DSRM, I'd also recommend confirming whether:

• This is the only domain controller, or do you have additional healthy DCs?
• Do you have a recent System State backup?
• Is the corruption isolated to NTDS.dit, or are there accompanying disk or NTFS errors?

If another healthy domain controller exists, rebuilding this DC and allowing it to replicate is often the safest recovery path. If this is the only DC, the recovery options become more limited, and restoring from a valid System State backup is typically the preferred approach.

One additional question: Is this the only domain controller in the environment, or do you have other healthy DCs that are still online? That will significantly influence the safest recovery strategy.

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.