Exchange almost gone KABOOM?

There is an old Bugs Bunny cartoon where Marvin the Martian is working with his illudium Q-36 Explosive Space Modulator and it doesn’t work.  “Where’s the kaboom? There was supposed to be an earth-shattering kaboom!”, says Marvin when nothing happens.  For Marvin this wasn’t good, for you with what looks to be a dead Exchange server it is also not good but, because there was no kaboom you may be able to rescue things.

Here’s the situation:  you have one or more Exchange mailbox databases that will not mount and, silly you, you have no valid backups of Exchange and you are sweating bullets (a non-profit I do some work with and which will remain nameless to protect the not-so-innocent was in this situation recently).  What do you do?

Well, first, you get users to shut Outlook down.  Their Outlook data (the local cached copy of their Exchange data in their local OST file) is probably still intact.  You do NOT want that data to be erased, corrupted or otherwise modified by what may be a broken Exchange so shut ‘em down.  If worse comes to worse you will have to rely on that Outlook data for recovery.  Second, you need to run all the various eseutil tests and procedures to see if you can recover the mailbox database.  If the database is not totally corrupted, eseutil may be able to recover something of the database.  Be aware that many of the procedures that eseutil can perform are destructive in the sense that they will result in data loss and the amount of data loss is not easy to predict.  You will need to lookup the appropriate eseutil commands for your version of Exchange.

Let’s assume that eseutil bombs out on you as your mailbox database is totally corrupted (as was the case with my non-profit), now what do you do?  You replace it with a new, clean, intact database.  To do that you need to do the following:

1. Create new directory to hold the database and name it so that it is meaningful to you.  The idea here is to keep new and old completely separated.
2. Using the Exchange console or the Exchange Management shell (powershell) create a new, empty mailbox database (sometimes called a “dial tone database”).  This link describes the process for Exchange 2010.
3. Mount the database.
4. Now you have to run some Powershell commands to move users from the old database to the new one.  This may seem counterintuitive because there is no data that can be moved from the old, corrupted database but Exchange (and AD) doesn’t know this.  What you have to do is move the “configuration pointers” so that Exchange will allow you to remove the old database and also allow you to populate the new database.  In Exchange 2007 you accomplish this with the Move-Mailbox –ConfigurationOnly cmdlet (good description here).  In Exchange 2010 and newer the process is changed and the cmdlet used is New-MoveRequest (good description here).

At this point Exchange is live, users will have a new, empty mailbox in the mailbox database and inbound email will start to flow as there is now an Information Store to hold the email.  But users email history is still not in Exchange.  This is where a little bit of work with users will really pay off.  Users need to be instructed to NOT start Outlook at this point as that will result in their Outlook being cleared of all data as the empty mailbox in Exchange will overwrite their local OST file.  What each user will need to do is start Outlook in offline mode; this mode tells Outlook to NOT make a connection to Exchange and you get to this mode by opening a command prompt and issuing the command outlook.exe /safe.  Once Outlook is open in offline mode the user will need to export all of their Outlook data out to a PST file.  Once data is safely exported to a PST Outlook can be restarted in regular mode; Exchange will overwrite the user’s OST file and then the user can import the contents of their PST file back into Outlook which will, in turn, push that data back up to Exchange.

This is not a perfect procedure by any means as there is sure to be some data loss but it is way better than losing ALL Exchange data.

And if there was ever an argument for moving to Office 365 this has to be it!  Backing up Exchange can be a royal pain and if you are not the type to manage your systems properly (as is my non-profit) then why not let someone else do it for you?  Microsoft carries the ball when your Exchange is Office 365 and the scenario described above would simply never happen.  Something to think about as you work through this process.