Read time 6 minutes
Exchange Server errors are some unavoidable truths that each Exchange administrator must face routinely. Due to some hardware or software reasons, the integrity of mailbox is affected and shows an error with an error number. An experienced administrator may recognize the cause of error and remove it manually. But, for complicated errors, there is an inbuilt repair tool that can scan the EDB file and perform some basic recovery. ESEUTIL is one of the Exchange inbuilt tools that help in repairing corrupted or damaged Exchange Server. It also ensures good health of the information store in an Exchange Server.
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, fix JET ENGINE or Extensible Storage Engine errors, etc. Before using it, you must ensure that Exchange database is dismounted and database replica, enough disk space (minimum 1.2 times the database file size) is available.
The Exchange administrator can Run ESEUTIL tool to check the consistency of database performance and its health. It can diagnose the functional issues and several health-related symptoms of the Exchange database. Apart from corruption, ESEUTIL can recover the database items from abrupt Exchange shutdown, spyware attacks, server crashes, deleted transaction logs, etc. It can recover data even when the backups are not available or deleted.
Get Kernel for Exchange Server recovery software to repair corrupt, damaged and healthy Exchange EDB files and perform flawless conversion from EDB to PST without Outlook.
Now, let us discuss how you can manually repair Exchange database corruption with the in-built utility – ESEUTIL. First, take a backup of the Exchange database file, note down the location of the Exchange EDB file (default path location is C:\Program Files\Microsoft\Exchange Server\V\Mailbox\<database_name>), and then dismount the database before performing this manual recovery through ESEUTIL application. Also, ensure that enough disk space is available.
To learn the manual recovery, 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 defragmentataion
- Mount and dismount stores
To run these above-mentioned steps, you require the help of several switches at each step of recovery. The following table will inform you about various Eseutil switches.
| Switches | Functions |
|---|---|
| /G | Checks the integrity of the selected database. |
| /K | Runs the checksums on database file, log files, and checkpoint files. |
| /D | Defragments the whole database thus saves the storage by removing the white spaces. |
| /P | Repairs the corrupt offline database files and discards such pages that it cannot repair. |
| /R | Places the database in a consistent state by replaying the transaction logs. |
| /M | Provides a display of headers of database files, transaction logs, and checkpoint files. |
| /C | Conducts a hard recovery of database after recovering data from backup files. |
| /Y | Copies the large database EDB files quickly. |
Now, get the details of the above steps to manually perform the hard recovery with ESEUTIL command-line utility and deal with Exchange database corruption issues.
Check for the consistency of Exchange database
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.
Check for the required logs status
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.
Perform recovery (soft or hard)
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.
Perform defragmentataion
After that, defrag the database offline to reorganize the information stored on the system by removing or eliminating the empty spaces in the database. Run this command –
Mount and dismount stores
Once successful defragmentation is performed, first, mount and then dismount 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. The Exchange database recovery through in-built ESEUTIL application commands has some drawbacks as well.
- The need for technical expertise
- Chances of incomplete recovery
- The need for disk space
- Lengthy procedure
- May result in further corruption of data
- Keen attention is required to avoid mistakes
- Able to fix minor corruption errors or glitches
In such scenario, I would recommend Kernel for Exchange Server the most trusted professional Exchange Server recovery software for EDB to PST conversion that performs flawless and complete recovery of Exchange database.
Final Words
Exchange database can be repaired with a manual solution – ESEUTIL utility, if run with care and database corruption is not extreme. At least users can give a try for it before being hopeless about the manual solutions for recovery. However, in cases like an urgent need for data and corruption is not manageable, trusting third-party solutions is a better option.
Exchange server minor corruption issues can be handled by eseutil very easily, but for major corruption and loss issue can’t be repaired using it. Kernel for Exchange is an excellent approach to handle such problems.