An issue faced by the Exchange administrators is when the database is dismounted due to issues like, server crash, abrupt shutdown, corruption etc. while the Exchange database is in a dismounted state, users will be unable to access their mailboxes. To mount the database back on the server, you can use EAC or Mount-Database Cmdlet in EMS.
However, If you are failing to mount the database. It is an indication of the Dirty Shutdown error.
Whenever the database goes into a Dirty Shutdown state, it is an indication of database corruption or inconsistency. This error occurs when the transaction log files are not committed to the database file or the log files are inconsistent. Once your Exchange database is in a Dirty Shutdown state, users will be unable to use their mailboxes until the corruption is repaired and the database is restored to a Clean Shutdown state.
To repair the corruption in database and make it consistent, you can use native tools like EseUtil. However, if there is any error while attempting to repair the database, it can cause permanent data loss. Hence, it is important to ensure you are using the correct procedure to repair the database using EseUtil.
This article describes the detailed process to resolve Exchange Dirty Shutdown error using EseUtil.
How to resolve Exchange Dirty Shutdown error
Before proceeding, you have to create a backup of the server using WSB or any other tool and stop the exchange services.
Let us look at the steps to resolve the Dirty Shutdown error using EseUtil.
Step 1- Check the state of the database
First you need to check the state of the database to ensure if it is in dirty shutdown or not. Use the eseutil /mh command to see if the state field is displayed as Dirty Shutdown. Use the following syntax:
EseUtil /mh “databasepath” /”databasepath.edb”
In the output, check the following 2 fields:
- State: This filed will display that the state of the database is in Dirty Shutdown.
- Log Required: This field will display the log files that are causing the error.
Step 2: Check the state of the required log files
To get the database in a clean shutdowns state, you need to commit all the uncommitted transactions in the log file that is displayed in the Log-Required field. However, you can only replay the log file if it is not corrupted. To check if the log file is corrupted, run the following command:
eseutil /ml “<Path to the required log file>”
If the output of the command displays No damaged log files were found, you can proceed with Soft Recovery process, otherwise, you need to perform Hard Recovery.
Step 3: Use EseUtil to repair corruption in the database
If the log files are healthy, you need to perform Soft Recovery using the EseUtil /r command to repaly the log file in the Log-Required field. Use the following syntax:
ESEUTIL /r <log_prefix> /l <Log Files Folder Path> /d <Database Folder Path> /i
This will commit all the uncommitted transactions on the database.
Run the EseUtil /mh command again to check the state of the database. The state should be set to Clean Shutdown, indicating the Dirty Shutdown error is resolved.
However if the log files are corrupted or Soft Recovery Process fails, Perform Hard Recovery using the EseUtil /p command. Hard recovery will use the edb file and truncate the inconsistent log files to make the database consistent. Use the following syntax:
EseUtil /p “name of the edb file”
It is important to note that If you run Hard Recovery:
- There is no 100% guarantee that the database will be mounted.
- You must accept data loss as it deletes any corrupted data.
- You cannot get Microsoft support after you run this as the database becomes hard coded.
In addition, you cannot directly mount the database after performing Hard Recovery. You need to run a defragmentation process on the database, to free up the space occupied by the old data and unused pages. However, this process is time consuming if you are dealing with a large database. You also need to move the mailboxes from the repaired database to a new database file (EDB) on your server as the repaired database may fail or are damaged again.
To avoid the risk of data loss, do not run the Hard Recovery on your corrupt or inconsistent Exchange database with Dirty Shutdown state.
Instead, use a third-party exchange recovery software, such as Stellar Repair for Exchange, to fix the database file (EDB). The software can extract mailboxes from the inconsistent or corrupt Exchange database and save them to PST format. You may also export the mailboxes from the corrupt or dismounted databases to the live Exchange Server or Office 365.
Conclusion
By using native tools like EseUtil to resolve the Dirty Shutdown error, you will have to spend several hours with no guarantee of recovery. On the other hand, the users will not be able to access, send, or receive emails during the process. Apart from the business aspects, where business opportunities can be lost due to downtime, loss of data can result in legal obligations.
You can use Stellar Repair for Exchange software that can repair damaged databases and extract mailboxes in common formats, such as PST, EML, MSG, HTML, RTF, and PDF. In case the database is dismounted due to Dirty Shutdown or severe corruption, you can create a new blank database so that the users can continue their work and resume sending and receiving emails. The application is also used for Office 365 migration as it can export an EDB file directly to an Office 365 accounts. Stellar Repair for Exchange is compatible with all Exchange database formats – from 5.5 to the latest 2019 version.