There is an unfortunate situation, where your Active Directory’s database gets corrupted and you are left with no clues of what has caused this inconvenience, or how to resolve it. Sadly, we had to recently face that issue as this Event ID gets accompanied by several others, including Event ID 1084, of task category Replication, which means that DCs can no more replicate objects and an immediate action is required in order to remediate the issue.

Below is the plan and steps we followed in order to resolve the issue.

We primarily verified that there were no issues with interconnections or any reason that would block connectivity amongst DCs. We used AD Replication Status tool (ADREPLSTATUS) for this, along with some help from the networks and security team.

Next step was to reboot the VM and select Directory Service Restore mode.

Screen might be slightly different according to your Server Operating System version

When in CMD, we had to type the below command:

ESENTUTL /g C:\Windows\NTDS\NTDS.dit /!10240 /8 /v /x /o

There was a good chance that the results of the command would indeed show us that the database was indeed corrupted and it will need to be recovered, so, our next action was the following command:

ESENTUTL /p C:\Windows\NTDS\NTDS.dit /!10240 /8 /v /x /o

Afterwards, we proceeded deleting all log files in C:\Windows\NTDS and typed the next command:

ESENTUTL /p “NTDS.dit” /!10240 /8 /v /x /o

It took a couple of minutes to execute the integrity check.

Upon successful Integrity check, we stopped the AD DS Service and then executed the last command:

NTDSUTIL Prompt type: Semantic Database Analysis and Enter

Go and Enter

This command triggered the Semantic Database Analysis, that basically verified the integrity of AD DS database files according to AD semantics and would identify any possible low-level corruption issue that occurred in the NTDS.DIT at that time.

After the successful completion of the Semantic Database Analysis, we rebooted the server in Normal mode and thankfully, functionality was restored. A final check with ADREPLSTATUS tool showed no issues, allowing us to mark the incident as resolved.

Last modified: December 5, 2020

Author

Comments

Write a Reply or Comment