Exchange Server database corruption issue is one of the crucial tasks ever. Quite often, we come across corruption of MS Exchange Server, when access to mailboxes gets lost completely. Many organizations experience the same hazard with complete loss of data accessibility. The manual solution treated as a primary option to overcome this database corruption issue. ESEUTIL is one of the Exchange inbuilt tools that helps in repairing corrupted or damaged Exchange Server. It also ensures good health of the information store in an Exchange Server. Let us discuss this in-built tool Eseutil in detail to have optimum knowledge about it.
You can find ESEUTIL, a command-line utility in \EXCHSRVR\BIN directory. Using this tool, you can perform database repair, offline defragmentation, integrity check for database, etc. Before using it, you must ensure that Exchange database is dismounted and database replica, enough disk space is available.
ESEUTIL utility helps in performing hard recovery manually when the server fails to perform the automatic soft recovery (replaying log files to make database consistent) on restarting it. It also repairs page level database corruption issues.
Now, let us discuss how you can manually repair Exchange database corruption with the in-built utility – ESEUTIL. To learn it, you must follow the 5 steps one after another.
- CHECK FOR THE CONSISTENCY OF EXCHANGE DATABASE
- CHECK FOR THE REQUIRED LOGS STATUS
- PERFORM RECOVERY (SOFT OR HARD)
- PERFORM DEFRAGMENTATION
- MOUNT AND DEMOUNT STORES
Get in detail of the above steps to perform the hard recovery manually with ESEUTIL command-line utility – to deal with Exchange database corruption issues.
CHECK FOR THE CONSISTENCY OF EXCHANGE DATABASE –
CHECK FOR THE REQUIRED LOGS STATUS –
PERFORM RECOVERY (SOFT OR HARD) –
PERFORM DEFRAGMENTATION –
MOUNT AND DEMOUNT STORES –
Start with checking the database is consistent or not. Open the ESEUTIL utility from \EXCHSRVR\BIN directory location and run the command –
There can be two outputs – either it shows ‘Clean’ database shutdown state or it shows ‘Dirty’ database shutdown state. For Clean database shutdown state, the action you need to perform is to move all transaction log files from the folder and then mount the stores.
When the database shutdown state is Dirty, follow the next step.
If you found the Dirty database shutdown state, check if the ‘Required’ log files are present. To check the status of Required log files, run the command –
The output results will be if the log files are healthy or not.
If the output shows that log files are healthy, perform Soft recovery with the command –
After it, mount the stores. It will resolve the problem.
In case, you encountered database mismatch error, rectify it by running the command –
But, if the log files are unhealthy or not available, Hard recovery is required. Before that, restore database from backup, if available. After restoration, a file named restore.env is created at a temporary location. Copy this temporary folder and paste it at other location. In this situation, run this command for Hard recovery –
If the temporary folder is empty now, Hard recovery is successful. Mount the stores again.
In case you do not have a backup along with you, execute this command to perform the Hard recovery.
Select OK and then the Hard recovery is performed.
After that, defrag the database offline to reorganize the information stored on the system. Run this command –
Once successful defragmentation is performed, first mount and then demount the stores.
This is how we performed the manual database recovery with Eseutil command. If the database is mounted successfully, the repair is successful. And, if not, then there might be case of severe corruption in database or some other reason. In such scenario, I would recommend going for the most trusted professional Exchange Server Recovery software – Kernel for EDB to PST Converter that performs flawless and complete recovery of Exchange database.
Exchange database can be repaired with manual solution – ESEUTIL utility if run with care and database corruption is not at extreme level. At least users can give a try for it before being hopeless about the manual solutions for recovery. However, in cases like urgent need of data and corruption is not manageable, trusting third-party solutions is a better option.