Exchange Dirty Shutdown Repair Done Right
If you are a system admin who does not know how to do an Exchange dirty shutdown repair then don’t worry we will explain to you the four-stage process which involves:
- Database State Check (eseutil /mh)
- Soft Recovery (eseutil /r) (If eseutil /ml reports no sequence errors)
- Hard Recovery (eseutil /p) (Only if soft recovery fails and you have no usable backups)
Before that you should make a backup of the Exchange Server data. Then proceed with the following.
Phase 1: Before Exchange Dirty Shutdown Repair See Server Status via Cmd
- Press Windows + r to launch the run module
- Type cmd in the given space and then press enter.
- This opens up a command line instance.
- If you are about to type(copy/paste) the scripts from here directly into your own environment then you have to use the command line as these tools only work there.
eseutil /mh "Path\To\Your\Database.edb"
Before you press enter, make sure you replace the “Path\To\Your\Database” part with the correct value.
It is a pretty well-known fact that if an organization’s admin delays putting the Exchange Server in maintenance mode for too long, dirty shutdowns become highly likely.
This is a command-line tool, and you can’t run it directly inside the Exchange Management Shell or the regular PowerShell. If you see somewhere that it says to put this code in EMS, it’s probably wrong and not well-researched.
If you still want to use PowerShell, we can make it a control engine to run our cmdlets in a command-line window.
Type:
Start-Process -FilePath "C:\Program Files\Microsoft\Exchange Server\V15\Bin\eseutil.exe" -ArgumentList "/mh ""C:\ExchangeDatabase\Mailbox Database 1.edb""" -Wait
Here is a breakdown (what and why) of this script.
- FilePath: Path to eseutil.exe
- ArgumentList: Command-line arguments for eseutil
- Wait: Ensures PowerShell waits for eseutil to finish
- Workflow Convenience: Manages recovery process within a single session
- Scripting and Automation: Automates parts of the recovery process
Phase 2: Soft Recovery (Eseutil /r)
It is called a soft recovery as it does not interact with data directly but rather reads and replays the logs to bring the database to a consistent state.
This is the go-to solution as it causes minimal data loss. Some admins may prefer it if they are fixing other problems like stopping an Exchange Server from recreating meetings.
Before you attempt any sort of method for Exchange dirty shutdown repair double-check that the database is dismounted. This is to be done even though a dirty shutdown dismounts the database.
For this, you can use EMS or the regular PowerShell. Type
Dismount-Database “YourDatabaseName”
Go back to the command line instance and within the same elevated setup you used to check the logs type:
eseutil /r <Log File Prefix> /l "Path\To\Log\Files" /d "Path\To\Database.edb"
Note you need to replace:
<Log File Prefix> with the prefix noted earlier (e.g., E00).
“Path\To\Log\Files” with the path to your transaction logs.
“Path\To\Database.edb” with the path to the database file.
Finally, once again use eseutil /mh to see if everything happened according to plan or not.
If you see a “Clean Shutdown” state it means that soft recovery was successful. Otherwise, go for the next phase.
Phase 3: Hard Recovery (Eseutil /p) Method for Exchange Dirty Shutdown Repair – Last Resort!
Use hard recovery only if soft recovery fails. This will result in data loss.
Ensure the database is dismounted. This step is a mandatory safety precaution in all recovery scenarios.
Then type:
eseutil /p "Path\To\Your\Database.edb"
Defrag the Database (Mandatory After /p):
eseutil /d "Path\To\Your\Database.edb"
Integrity Check (Isinteg – Recommended): After defragmentation and with Exchange services running:
isinteg -s <YourServerName> -fix -test alltests
You can use the method mentioned in phase 1 to use PowerShell and make the code work in the command line instance without manually opening it yourself.
Best Practices
Backup not only the data but also the infrastructure on which you run which means keep a secondary power source at the ready in case something happens to the main powerline.
You may have to operate the Exchange server at reduced loads so if all of a sudden there is a huge spike your server doesn’t shut down.
Is your Server cyber-secure? How well can it handle outside threats that intend to make use (or in this case misuse) of the Exchange Server’s safety features?
One valid reason why veteran admins skip over the manual repair work is its unreliability. Despite being so cumbersome they are not a 100 % guarantee to work. Even if the server appears normal it may soon return to the dirty shutdown state without warning. This is because most of these methods try to get rid of the symptom rather than the disease.
So, just forcefully trying to restart the server won’t work. That is why you need a solution that works on fixing core issues which majority of the time is a faulty database.
Therefore, using the SysTools EDB Repair Tool kit is the best way out of the mess.
Its unique interface reduces the time and effort required from the admin side by doing all the heavy lifting on its own.
Conclusion
It is not easy to do an Exchange dirty shutdown repair on your own. However, with the help of the instructions given in this tutorial admins can cut down on a lot of time. Not only that, the tool prescribed above text saves a lot of unnecessary effort that would have otherwise been wasted on hit-and-trial methods.
Frequently Asked Questions
What will happen if I don’t fix the Dirty Shutdown immediately?
Any delays made in the fix of the dirty shutdown can amplify the problems even further. Admins may face longer downtime, and even the database itself can get corrupted. All of this adds more time to bring back the server in the working state.
If the Exchange Server is non-functioning because of the dirty shutdown then how does it process the command line repairs?
This is possible because it is not the Exchange Server database that runs the commands but rather a separate but connected part of the server called ESE that processes all the queries.
Why can’t I run the repair queries without dismounting the database first?
A dismounting request is necessary to make sure that there are no active connections between the repair module and the server.
When the dirty shutdown causes a dismount why should I do it again?
Even though a dirty shutdown almost always causes a dismount admins should nevertheless attempt a manual dismount just as a precautionary measure.