Exchange Database Hard Repair Process Using ESEUTIL /P Cmdlet

Microsoft Exchange Server utilizes the Write-Ahead Logging (WAL) technique to maintain the database integrity, reduce the disk I/O, and avoid performance issues. Any changes made in the database are first stored as logs in the append-only log files and then committed to the in-memory copy of the mailbox database. This way, Exchange Server ensures database consistency. However, if the logs are not committed to the database, the database becomes inconsistent, enters Dirty Shutdown state, and dismounts from the server. Such a situation may occur due to one or more of the following reasons:

• Sudden power cut
• Hardware failure
• Software failure like updates
• Third-party software are not application compatible
• Incorrect antivirus configuration
• Human error
• Malware and viruses
• Lack of storage space

You can replay the changes stored in the uncommitted logs on the database copy using the EseUtil Soft Recovery command (EseUtil /r) to recover the database and mount it back on the server to restore mailbox connectivity. If the Soft Recovery fails or you can't find the logs that are required to recover the database, you have to rely on the EseUtil Hard Recovery or Hard Repair process.

In this guide, you will learn when and how to safely use the Hard Repair or Hard Recovery cmdlet?EseUtil /P?to recover inaccessible, inconsistent, or corrupt databases from the Dirty Shutdown (dismounted) to Clean Shutdown (mounted) state.

Steps to Perform Exchange Database Hard Repair Process using EseUtil

Follow the steps discussed below to perform the hard repair process using EseUtil cmdlets and recover a corrupt or inaccessible Exchange database.

Step 1: Verify the Database Status

On the Exchange Server, open Command Prompt or the Exchange Management Shell (EMS) as administrator and navigate to the location of the affected EDB file using the CD command. Then execute the following command to check the database status:

EseUtil /mh 
databasename /databasename

For instance,

EseUtil /mh "EX01DB02.edb"

Check the State. If it displays a Dirty Shutdown, the database needs repair and recovery. If the logs are available, try Soft Recovery. However, if Soft Recovery fails or the logs are missing or deleted, skip to the next step.

Step 2: Backup Database Files

Before running EseUtil cmdlets to recover an inconsistent or corrupt database, you must back up the database folder and logs folder to a safe location. This will help prevent the permanent loss of mail items or mailboxes that may occur during the hard repair process.

To create a backup of failed, corrupt, or inconsistent Exchange database, go to the folder location and copy it to an external or internal storage volume.

Step 3: Run Hard Repair Command

You can run the following command to execute the hard repair process on the affected database for recovery. Make sure the drive where the database is stored has free space available, at least 1.2 times of the database size.

EseUtil /p "EX01DB02.edb"

You will see a warning message stating that this may cause the information to be lost. If you accept the risk of data loss, click OK and start the hard repair process.

This may take a while to complete. During the repair process, it may remove the irrecoverable mailboxes and mail items, including any changes that were made but not committed to the database. Thus, there's a huge risk of losing important mail items.

Warning: Do not close or stop the hard repair process when started as it can permanently damage the database.

Step 4: Move Mailboxes to a New Database

Once a database is recovered or repaired using the Hard Repair EseUtil cmdlets, it is marked as hard-coded. Besides, it's not safe to keep using a repaired database. Thus, you must move all mailboxes from the recovered Exchange mailbox database to another database on the same or another server.

Final Thoughts

While the hard repair process using EseUtil /p command can restore an inaccessible, inconsistent, or corrupt database, it may remove the irrecoverable information and changes to mailboxes due to uncommitted logs. However, to avoid data loss and the hassle of running EseUtil and IsInteg cmdlets, you can use advanced Exchange database recovery software, such as Stellar Repair for Exchange.

Unlike EseUtil hard repair or hard recovery, the software is GUI-based and does not alter the original database file. It runs in read-only mode to repair the database structure and extracts all mailboxes from the corrupt database with complete integrity. After the recovery, you can save the recovered mailboxes as individual PST files that you can easily import into Exchange Server or Outlook. You may also export the mailboxes recovered from damaged database files directly to a live Exchange database or Office 365 tenant in a few clicks.

The software can make a big difference when it comes to the downtime that your organization may have to experience if you choose the Hard Repair process. With the help of the software, you can not only avoid data loss but also reduce downtime by up to 75%.