How to get rid of Exchange Dirty Shutdown Problem?

This is a very common problem that every Exchange user has to face.

Symptoms: - Following are the main factors that need to be determined in case of an Exchange System in a Dirty shutdown state.

• Collect the database and the required logs

User must find a copy of the .edb file and needed logs. These logs are required from database perspective and this can be completed by suspending the older database copy, and then copying the needed files to a separate location or creating a snapshot of the volume which can be reverted to at a later time.

• Check database state

This can be done through the command below:-

eseutil /mh "c:\DBRecovery\Mailbox Database 0436312751.edb"

Then check the database header for log files generation that is needed for the recovery, in this case use this step:-

Log Required 124-124 (0x7c-0x7c) which indicate file E000000007C. These log files are required for the recovery of the database at a minimum to a clean shutdown without any data loss of the user.

• Check consistency of needed logs

Before starting to apply the logs it is important to check that all logs should be in consistent state and must be available.

Or if you need to handle a large number of logs and have used the Windows Explorer to copy the files, then keep one thing in your mind that some files are missing when you are sorting them in the Windows Explorer view.

To ensure that you will not fail afterwards when performing the recovery use eseutil /ml together with your log directory path and log prefix, like as obtain here E00.

Log file check within directory by using this:-

eseutil /ml c:\DBRecovery\E00

Recover database state to “clean shutdown”

After finishing both checks successfully, start the recovery by using:-

eseutil /R E00 /l "c:\DBRecovery" /d "c:\DBRecovery\Mailbox Database 0436312751.edb"

It failed with an Error “-1216” and this can be fixed by using the “/I"

And then try this:-

eseutil /R E00 /l c:\DBRecovery /d "c:\DBRecovery\Mailbox Database 0436312751.edb" /i

And YES it results in “Operation completed successfully in 0.140 seconds.” Then check the Application event log and YES, there is no Error.

Check before mounting the database by running:-

eseutil /mh "c:\DBRecovery\Mailbox Database 0436312751.edb."

No need to worry if still it is in a “dirty shutdown” stage.

Then run ESEUTIL/P to get the database into a clean shutdown. (Microsoft strongly discourages using eseutil /P because it may lead to data loss and known for the hard recovery. The /P should be a measure of extreme desperation when there’s no way at all to recover your database via /R).

Solution:-

The last command is eseutil command:

eseutil /R E00 /l "c:\DBRecovery" /d "c:\DBRecovery\Mailbox Database 0436312751.edb” /i

Following are the three things that may happen:-

• “/i” is a parameter for skipping missing log stream that are attached with the databases. In older versions of Exchange one log stream was used per storage group. As a storage group could have contained multiple databases, the “/i” option was provided when only one out of multiple databases has to be recovered. As Exchange 2010 doesn’t use storage groups any more, this parameter shouldn’t be used any more.

• Then come to “/d” parameter, with the fully qualified path to the EDB file. Now in such case you must use the directory path not the full path to the .edb file.

• There is no system path specified, so the actual path of the cmd prompt is used. This directory is used to check for, or to create, an E0x.chk file. It is always recommended to the user to specify the same path as the .edb and log directory to keep the files together, and ensure that the files you expect to be used are the ones which are always used.

These above steps will bring your system to a clean state because this error may lead to corruption in EDB file and if the EDB file gets corrupted then your whole effort will be in waste. Once I also got stuck in such a situation and my EDB file was damaged very badly but soon I recovered from that scenario because of Stellar Phoenix Exchange Server Recovery software. This is really a very effective tool for EDB repair and recovers all items from Exchange database file. This is be compatible with all versions of the Exchange Server.