Fix Error After Dirty Shutdown in Exchange Server 2016, 2013, 2010?

During regular Exchange database operations, an unexpected termination of the database process is not very surprising. It is one of the common scenarios that may occur anytime.

Most of the Exchange server problems arise due to corrupt databases which don’t get mounted, and thus, prevents users from accessing their mailbox data. There are many issues which prevent the mounting of an Exchange database, and one of these issues is the “Dirty Shutdown” issue when it happens, the database administrators (DBAs) are required to handle Dirty Shutdown in Exchange Server 2016 or whichever variant of Exchange Server is installed to make sure that the database gets mounted.

What exactly is “Dirty Shutdown”?

The term “Dirty Shutdown” implies that the database is down and is not in a healthy state. When this happens, the DBAs are required to follow a proper course of action in order to fix the Dirty Shutdown in Exchange Server 2010, 2016, 2013 or 2007. Once the issue is fixed, the database can be restored and made accessible to users.

How To Repair The Exchange Server Database After A Dirty Shutdown?

Follow the below-given steps to fix the issue and recover your database on the Exchange Server efficiently after a Dirty shut down without any data loss. The following methodology can be applied to both the latest version of the Exchange server as well as the older versions —

1.   Back up The Files

First of all, back up all the edb, stm files, as well the logs. To do this, copy the pub.edb, priv.edb, all the stm files and logs to a secure location like the disk.

2.  Free Up the Disk Space

In order  to recover the database from a Dirty Shutdown state, you need to ensure that there is 110% of empty disk space. Don’t use the shared space and make sure to keep a continuous space for recovery, which is 110% of the size of the database.

3. Check for Database Consistency

In order to check the consistency of the Database, run the following command:

[eseutil /mh “path of priv.edb”]

So, if you have stored your priv.edb file in the C partition and database folder, then you can write this command in the following manner:

(eseutil /mh “c:\database\mailbox database.edb”)

4.  Check The Database Status

The status of the database must indicate – “Dirty Shutdown”

Once you encounter that the status is showing “Dirty Shutdown”, you can first try the “Soft Repair” and if that does not work, then try using “Hard Repair”. Let’s look into each method:

i.  Run Soft Repair

The following command that initiates the soft repair is [eseutil /r]; however, it must be run from the database log folder only.

[eseutil /r “prefix“<E00> /l <log file location> /d <location of database>]

If both the log file and database are located in the C partition, then you can run the aforementioned command as:

Eseutil /r E00 /l c:\dblog /d c:\db

Check The DB Consistency

Check the database consistency again and if it shows a clear shutdown, directly go to Step 6. But, if soft repair didn’t work, then run the hard repair.

ii.  Hard Repair

Following is the command for running the hard repair

(Eseutil /p “location of mailbox database.edb”)

If the mailbox database is located in the C partition, under the “Program Files” folder in the relevant folder and files, then run the following command:

Eseutil /p “c:\program files\exchangesrvr\maildbdata\priv1.edb”

5. Defragment the DB

Now defragment the DB using the eseutil /d command applied to the mailbox database file. Run the command with the following syntax:

Eseutil /d “c:\program files\exchsrvr\mdbdata\priv1.edb”

After executing this command, remove the log files in the MDBDATA folder before commencing with the database mounting.

6.  Check DB Integrity

This command takes up to 10 minutes per Gig of Data; therefore, if you don’t have enough time, this step can be skipped after a soft recovery procedure.

But, if you have attempted hard recovery, then you must run it. Try checking the integer of the database with the following command:

[isinteg -s “name of the server” -test alltests]

If this integer check fails, then run the following command

[isinteg -s “servername” –fix –test – alltests]

Run this command repeatedly till all the errors reach the level 0, or the status starts showing no changes.

7.  Check the DB Consistency

Now check the DB consistency, with the following command

Eseutil /mh and it must show “clear shutdown” as the status.

With the aforementioned steps, one can easily recover the database repair exchange database file.