Woah! This method can cause all sorts of issues with the database. Especially if you use esentutl /r. Esentutl has no idea this is an Active Directory database, all it knows is that it is a jet database. As such, it will look for
inconsistencies and truncate the database if necessary. Start with NTDSUtil. Specifically, ntdsutil\activate instance ntds\semantic database analysis\go fixup (you will need to stop ADDS if 2008+, or reboot into DSRM if 2003).
Only if this does not work would I consider using esentutl. Even then, I'd likely just demote the DC and repromote it as mentioned by Meinolf Weber.
For more information check this out:
http://technet.microsoft.com/en-us/library/cc940337.aspx
|
Recover
|
Invokes Esentutl.exe to perform a soft recovery of the database. Soft recovery scans the log files and ensures all committed transactions therein are also reflected in the data file. The Windows 2000 Backup program truncates the log files appropriately.
Logs are used to ensure committed transactions are not lost if your system fails or if you have unexpected power loss. In essence, transaction data is written first to a log file and then to the data file. When you restart after failure, you can rerun the log
to reproduce the transactions that were committed but hadn't made it to the data file.
|
|
Repair
|
Invokes Esentutl.exe to perform a low-level repair of the data file. Use the repair command only on the advice of qualified service personnel, as it can cause data loss. Furthermore, this can only repair what ESENT knows about. This means that its notion
of repair might eliminate some data that is key to the safe operation of the directory service.
|
Thanks!
