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)
- Log File Sequence Integrity verification (eseutil /ml)
- 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 You do an Exchange Dirty Shutdown Repair See Server Status via the Command line
- 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 that you replace the “Path\To\Your\Database” part with the correct value.
It is a pretty well-known fact that if in an organization admin delay putting the Exchange Server in maintenance mode for too long such dirty shutdowns become higlylikely.
This is a command line tool and you can’t run it directly inside Exchange Management Shell or the regular PowerShell. If you see somewhere where it says to put this code in EMS it’s probably wrong and not well-researched.
If you still want to use PowerShell for some reason what we can do is make PowerShell a control engine to run our cmdlets on 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"
Defragment 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.