Lucid8 created this article as a courtesy and will not provide further support or guidance unless you have engaged a team member for paid Professional Services for Microsoft Exchange.  All information in this article is provided on an "AS IS" basis with no warranties, guarantees of completeness, accuracy, usefulness or timeliness, and as such any action you take thereafter, are done so at your own risk.  

NOTE: If you would like assistance in regards to your Exchange Database .EDB files, for self-service check out DigiScope or engage one of our experts for paid  Professional Services for Microsoft Exchange  assistance.

FORENSIC MOUNT: You may want to consider using DigiScope's Forensic Mount option along with the Dial-Tone Recovery method since allow you to skip the repair process and get your end-users to back online in a shorter period of time

ESEUTIL /P - Hard Recovery/Repair of Exchange Database (EDB)

STOP - THIS IS A DESTRUCTIVE PROCESS THAT MAY CAUSE DATA LOSS

It is strongly advised against using this type of database recovery as it may cause data loss and its difficult to predict how much data may be lost. The Hard Recovery/Repair process should be used only as the last resort when there is no other alternative to recover the database. Before running ESEUTIL /P or any other utility against your Exchange Database files;

  • All end-users mailboxes within the effected database will not have access to their mailboxes during this process
  • Review the SYSTEM & APPLICATION "Event Logs" You need to review and correct all ERROR or CRITICAL events before taking additional actions. Hardware & Disk Storage related issues cause a large % of DB corruption issues, therefore you want to resolve any such issues before taking action, else DAMAGE & DATA LOSS WILL OCCUR
  • BACKUP: Create a "MASTER Backup" of the .EDB and its associated (log & .chk) files so that if something goes wrong such as a power outage, hardware failure, etc. ALWAYS store the MASTER BACKUP on an alternate machine/disk experience so that if there are hardware has issues you can still recover.
  • SPEED: The time to complete a repair depends on many variables, such as but not limited to DB size, level of corruption, the # of passes the repair process has to make and of course the speed of the hardware.  On average it processes between 3 to 6GB per hour and that's an average, i.e. it can go much faster or slower depending on all the variables. Short story be very patient and don't interrupt the process, it will be done when its done.



Below is an example of the -1216 mismatched error experienced during a defragmentation attempt via ESEUTIL /D. This error can be caused by EDB or Log related corruption. 


STOP: If you have not yet reviewed and corrected any ERROR or CRITICAL events within the System & Application log, do so now. 


REPAIR OF THE EXCHANGE DATABASE

Start the hard recovery/repair procedure by executing this cmdlet:

Template: 

ESEUTIL /P <path_to_the_database>


Usage Example: In our case, the cmdlet string below is utilized:

ESEUTIL /P Fabrikam-13.edb


NOTE: Since we executed the command within the folder that contained the EDB we did not have to designate the actual database path.

  • When starting the /P (Repair) process you will see images similar to the ones shown below warning of the potential consequences.




  • Click OK to start the repair process


SPEED: As stated earlier, the time to complete a repair depends on many variables, such as but not limited to DB size, level of corruption, the # of passes the repair process has to make and of course the speed of the hardware.  On average it processes between 3 to 6GB per hour and that's an average, i.e. it can go much faster or slower depending on all the variables. Short story be very patient and don't interrupt the process, it will be done when its done.


  • Once completed the process will display a result code as shown in the example below

  •  If the result states the database corruption has been repaired validate the EDB is in a Clean Shutdown state using the ESEUTIL /MH <database_name> cmdlet for the Fabrikam-13 database, i.e. as shown below ESEUTIL /MH Fabrikam-13.edb



As you can see above the Fabrikam-13 database is now in a Clean Shutdown state. Best Practice at calls for the database to be defragmented via ESEUTIL /D before putting it back into service. That said ESEUTIL /D can take considerable time to complete.  Also once a database is repaired the best practice is to mount the DB, create a new DB and move all the mailboxes from the current DB to a new DB.  With that in mind it may be more productive to skip the defragmentation process since you will need to move the mailboxes to an alternate DB after mounting it


The database can be remounted by using the following cmdlet within Exchange PowerShell


Template:

Mount-Database -identity <database_name>


Usage Example:

Mount-Database -identity Fabrikam-13


FINAL ACTIONS: 

  • Run/Execute a new full Exchange Aware Backup of defragmented database
  • Delete the offline master backup copy of the EDB to free up disk space

NOTE:  Lucid8 created this article as a courtesy and will not provide further support or guidance unless you have engaged a team member for paid Professional Services for Microsoft Exchange.  All information in this article is provided on an "AS IS" basis with no warranties, guarantees of completeness, accuracy, usefulness or timeliness, and as such any action you take thereafter, are done so at your own risk. 

NOTE: If you would like assistance in regards to your Exchange Database .EDB files, for self-service check out DigiScope or engage one of our experts for paid  Professional Services for Microsoft Exchange  assistance.