Active Directory might seem simple but it’s a very complex and delicate system. Active Directory is the holder of all your policies, users, and schemas. Also, several applications depend on the system. To your dismay, on a fine day, you encounter the below issue while changing something in user details or a simple reset of password.

In such a case, the first thing to do is not to panic. Otherwise, you may end up changing stuff and applying fixes without carefully evaluating the situation and possibly making it worst.

The next thing is to get some clues about the reasons for such a situation. The first place to look for clues is the Event Viewer. For this, expand the** Applications and Services Logs** and then click on the Directory Services.

If you see the NTDS ISAM source with event ID 467, it means that the ntds.dit database is corrupt.

You may notice some other error events, which also refer to the same issue. These can be,

• NTDS Replication Event ID: 1084 Replication Error
• NTDS Replication Event ID: 2108 Replication Error
• NTDS General Internal Event ID: 1173 Processing Warning

Now you need to look for solutions before any more damage occurs. There are two solutions, depending on your architecture. If you have just one Active Directory, you can try a repair or restore from backup. If you have more than one Domain Controller, you can rebuild the faulty server. Let’s explore both solutions.

1. Repair Active Directory by Using ESENTUTL

Restart the faulty domain controller in Directory Restore Mode (DSRM). There are different ways to do this. Importunately, you need to remember your DSRM password, which was created when you promoted the server as a domain controller or when you have set up the forest in the beginning.

Note:_ If you don’t have the DSRM password and you only have one domain controller, then you would need to rebuild the forest from scratch, join the computer to the new domain and set up everything from the beginning._

• Option 1 – F8
• Reboot the machine and press F8 during start-up and wait for the prompt to select DSRM. Of course, you would either need physical or console access to perform this.
• Option 2 – MSConfig
• Open MSConfig.msc, go to the Boot tab, click Safeboot, and ActiveDirectoryRepair.
• Option 3 - Command-Line
• From a command-line window type, the bcdedit /set safeboot dsrepair

Once the server has rebooted in DSRM mode, click the Start button and open a command-line window by using the cmd.

It is important to take a backup of the database by saving a copy of the file elsewhere. For example, in c:\scripts.

You need to run an integrity check of the database first. This can be done by executing the following command:

esentutl /g c:\windows\ntds\ntds.dit

If the result shows ‘CORRUPTED’, then you need to run the repair switch and try to repair the database. This can be done by the example below:

esentutl /p c:\windows\ntds\ntds.dit

After the operation is complete, you will need to clear the log files, if exist, from C:\Windows\ntds folder.

After this is complete, remove the DSRM option and reboot the server. If all goes well, the issue should be resolved.

#active directory #exchange database #database