Even the best most well maintained Exchange Database can have issues from time. Best practices such as ensuring adequate disk space, online archives, quota and above all importance – backups as absolutely necessary. The best way to prevent database issues is to backup and attempt to steer away from any possible problems.

If you ever do get database issues, follow the below route to restore. This is what we’ve found as the best/fastest route. Note that it is intended to restore the Database with no data loss but also steps you through the worst case scenario of doing a full repair.

1. The first step with a corrupt Mailbox Database is to make a copy of your Database log files. These are all files (except your EDB database file) in the database directory. The reason for the copy is that this is a last resort (shown in step 5 below) in order to restore your database and replay unaltered log files so no data is lost.

2. Check your Exchange database health state by using the below command. Note that Exchange 2013/2016 can report a database is mounted in ECP even if that isn’t the case.
Note: You should replace the text in quotations with your own path to the EDB database file. Typically this will be C:\Program Files\Microsoft\Exchange\V15\Mailbox\ with a version number matching your server.

eseutil /mh “C:\path\database.edb”

This will output some text on screen. You should look for the ‘state’ line that states either ‘Clean Shutdown’ or ‘Dirty Shutdown’.

3. To remove a dirty shutdown state, try running the below command:

eseutil /r E00 /l “C:\path” /s “C:\path” /d “C:\path”

Notes:

• /r sets eseutil to Recovery Mode. This also requires the Database log format, typically E00 for the first database followed by E01. You can check this by navigating in to your Log file directory and listing the files. They will start with the digit E00 or E01, etc.
• /l is the path to your log files. By default this is that same location your EDB file is stored.
• /s is the path to your checkpoint file, such as E00.chk. This is also normally the same path as your EDB file.
• /d is the path to your EDB file.

4. If this works it should return your Database to a ‘Clean Shutdown’ state. Run the command shown in step 2 to check this.

5. If this doesn’t work, the next best step is restore from backup.

• Firstly, make a sideways copy of your EDB file. This is required if the soft repair /r doesn’t work.
• Now restore your last successful backup of the EDB file to its correct path.

6. To replay log files correctly, navigate to your log files directory and move the E00.chk file to another folder. The checkpoint file will point to specific location in the logs to restore from. Deleting the file should start the replay process as log 1 and continue until complete.

7. Now run the below command to replay the log files. The log files should be your original copy of the log files copied back to their usual location.

eseutil /r E00 /l “C:\path” /s “C:\path” /d “C:\path”

8. Once complete run the command listed in step 2 of this process to check the State is now ‘Clean Shutdown’. If so mount the database and do some tests, everything should be ok.

9. If you get ‘Dirty Shutdown’ still the last option is running a full EDB repair. Note that doing this will not replay logs files so anything not already in the database will be lost. This is by far a last resort process. In some cases data loss may be minimal and staff using Outlook with Cached Mode enabled may not even notice. Staff without Outlook/Cached mode could loose bulk amounts of emails.

Run the below command to do a full repair. Note that the repair process could take anywhere from 15 minutes to multiple days depending on the size of the database.

eseutil /p “C:\path\database.edb”

10. Once complete, run the command in step 2 once more and check for “Clean Shutdown” in the status. If so mount the database and do some tests.
After this you should have a working Exchange Database once more.

11. Do a full system backup of your Exchange server and Databases immediately after this process.

Note: If you performed a full repair (/p) Microsoft strongly recommend creating a new blank Exchange database and moving all mailboxes in the repaired EDB to the new database. This avoids possible further corruptions and potential downtime/loss of data.