Repair Exchange 2013 Database using ESEUTIL

When an Exchange server database is corrupted or damaged, it enters into the ‘dirty shutdown’ state which causes the Exchange server to dismount. There is a corruption in the database that prevents it from mounting unless you fix it. Meanwhile, users whose mailboxes were located in the damaged database are no longer able to access their emails as a result of the mailboxes being disconnected from the database. It is likely that this situation will impact your business significantly and that you will need to find a solution as soon as possible.

EseUtil, which stands for Exchange extensible storage engine utility, is a command-line tool that is used to repair databases on an Exchange server that have become corrupted, damaged or inconsistent. The EseUtil software is also used by Exchange administrators to diagnose database problems and monitor the health of the databases they administer.

In terms of repairing corrupt Exchange databases, administrators can use EseUtil as part of their Exchange administration process to recover victims in an event like uncommitted logs, missing or deleted transaction logs, server crashes, abrupt shutdowns, malware attacks, etc. If you find yourself in a situation where your Exchange backups are corrupted, outdated or not available, EseUtil can help.

In this blog post, we are going to show you how you can exactly fix or repair the corrupt exchange 2013 database using EseUtil.

Repairing Corrupt Exchange Databases with EseUtil

To repair Exchange databases when a backup isn’t available or doesn’t work properly, you need to use the EseUtil tool from Microsoft. The steps are as follows:

1. Identify the corrupt database (EDB) file and log files in the first step

A file called Exchange database (EDB) is created automatically when the Exchange server is set up, and it is typically stored at the following location:

In the folder C:/Program Files/Microsoft/Exchange Server/V15/Mailbox/, you will find the following files:

In order to optimize performance, administrators can choose to store the database file in a different folder or on a different drive volume. This could be done for a variety of reasons, such as performance. To repair an EDB file that has been damaged, you will first need to find the damaged EDB file and then repair it. As with the transaction logs, you should also locate the checkpoint file (.chk) and the transaction log file (.log).

2. Check the database’s status

With the use of the EseUtil command, you can determine the current state of the database as follows:

Press ‘Windows + R’, type \EXCHSRVR\BIN, then press ‘Enter’ or ‘OK’.

Make sure you copy the URL of Eseutil.exe located in the address bar by clicking on it.

Use the command ‘cd’ to navigate to the location of Eseutil.exe in the Exchange management shell (EMS), then open Exchange management shell (EMS).

In the PowerShell window, execute the following command as follows:

Eseutil.exe /mh

Eseutil.exe /mh C:\mbx01\mbx01.edb

There will be a display of the database header information in the output of this command. When the ‘state’ of the database appears to be ‘dirty shutdown,’ this indicates that the database is inconsistent or corrupt, and therefore it will need to be recovered. In cases where the database status is ‘clean shutdown’ or ‘all system is shut down’, the database is in a healthy state, and can be mounted to the server with no problems.

3. Make a backup of your database files

It is important to make a back up of the Exchange server database file, transaction log file, and checkpoint file before using EseUtil tool after you have located the Exchange server database file and verified it. Alternatively, you can make a backup copy of your database files in another folder, volume, or on an external storage device.

4. The recovery process is to run Soft Recovery using EseUtil.

A soft recovery is achieved when EseUtil is executed with the /r parameter, which is called ‘soft recovery’. Upon executing EseUtil on a corrupt database, the EseUtil attempts to commit the transaction logs as soon as possible and restore the database to a healthy state without allowing any data loss. Although it works when there is minor corruption in a database, it is not a perfect solution.

If you want to perform a soft recovery, you need to run the following commands:

EseUtil /r <database file path>

EseUtil /r C:\mbx01\mbx01.edb

Due to the fact that the database is large and the server’s performance and storage are not exactly the same, it will take a while for the process to complete.

5. You will need to verify the status of the database

You can verify if soft recovery was successful and the database is now in a ‘clean shutdown’ state by executing the following command to check if soft recovery was successful:

EseUtil /mh C:\mbx01\mbx01.edb

Check the state. The Exchange database will need to be recovered through a ‘hard recovery’ if it still displays ‘dirty shutdown.’

6. Using EseUtil, perform the hard recovery

Whenever recovery from soft backup is not possible and it is not possible to restore from the backup, we should resort to hard recovery. In order to perform a hard recovery, the /p parameter needs to be specified.

Warning:

The EseUtil/p command has the purpose of removing the irrecoverable data and mailboxes from the database in the course of restoring it, i.e., removing anything that has been deemed corrupted or unreadable by the recovery command. It is important to note that Hard Recovery may cause significant data loss that can be discovered later in the process.

Upon executing the EseUtil /p command, a warning about data loss will appear on your screen, which you must accept in order to continue. The EseUtil/p command will change some of the data in the database, so it would be wise to back up the database before running it.

Exchange Server corruption factors

It is important to realize that there are many factors that can result in a healthy EDB database turning into an error-showing database and generating problems. There are a number of possible causes and factors that can lead to the corruption of the Exchange Database. It is just a matter of reading the instructions carefully if you want to avoid corruption:

• In addition to not exempting the spool folder from scans by antivirus programs, it is also important not to exclude the folders that contain all the journal files that are applied to the Exchange database on the replica when the database is being managed or replicated. If Antivirus seizes this file, then the replica database will be damaged if this file is being seized by Antivirus. It is important to remember that if this occurs then the replica must be resynchronized.
• Synchronization that bounces back and forth.
• There are 1450 errors related to inadequate System Resources on either the main server or the replica server.
• It is not possible to attach a Storage Group or Mailbox Store without ‘Auto-detecting’ the Exchange databases and desynchronizing the exchange databases in those situations.
• As part of the synchronization or replication process, Exchange Services are executed on the replica.
• Synchronization has not been completed and we are trying to failover to the replica server.
• There is a problem with the master database.
• The main database is defragmented offline without stopping the scenario in order to perform the defragmentation.
• It appears that the server attendant services have been configured incorrectly
• There can be a discrepancy in storage due to the deletion of LOG files
• As a result of an oversized transaction log, data may be stored in an EDB file that is slower to work with, resulting in performance issues.
• Computer Virus or Malware attack