Recently, I ran into an interesting situation where a client’s computer (MAC) decided to have a Microsoft Outlook issue. Outlook crashed; and when it re-opened, it identified an issue with the client’s identity. Subsequently, it requested a rebuild of the user’s identity. Sadly, the rebuild was performed rather than the proper procedure of erasing the identity and recreating it. (I only service one Apple PC, so I don’t encounter this a lot. I only found out the proper procedure after the damage had already been done.)

Subsequently, the profile was rebuilt to the server; but all the calendar entries had been wiped out, as well as about 1GB of data was vaporized from the client’s exchange store. Needless to say, the client was overly pleased with the results. The client had not elected to use my preferred backup application, but at least had the Windows Small Business Server backups running.

I began the procedure to recover missing data from a specific email box as described by Microsoft. This requires the technician to perform a complete restore of the entire mail store (based on size and server speed, anywhere from 1-4 hours) to a redirected folder on the server. Once that is complete, you create an Exchange Recovery database and associate the required mail store to the recovery mailbox.

Following that you attempt to mount the mail store (AKA database) on the server so that it can be viewed and restored from. So far this all sounded rosy save for the initial recovery mechanism. If the file mounts successfully from the restore, you perform a mail merge operation and recover the user’s missing information and are off to the races.

Here’s the sour point: when you attempt to recover the database, the logs are likely missing and the database won’t mount gracefully. This will leave you in a heap of trouble since now you need to repair the database before you can mount the database (this is almost sexual, but I will leave that to another topic and this wouldn’t be a site you would be browsing for that type of story.)

Microsoft has made it much easier to run the old command lines for eseutil /d and eseutil /r by automating these commands for you. Keep in mind that since they have automated it, you can’t set the locations of the temporary databases (DBs). So if you have no space on the email store drive, this will fail. The major issue is the time taken to repair the DB before you can even begin to recover the mail.

Once I realized that my newly recovered database wouldn’t mount, I started the repair mechanism. Three hours later I was finally able to mount the database. At this point, I went through the basic steps of merging the user’s particular mailbox back into the existing email box and was successfully able to recover the missing 1GB of messages and their calendar items.

The end result of the story was that the user paid about $400 in service time to recover a singular failed mailbox because they didn’t want to spend $700 to buy a proper backup application.

Happily, the Microsoft application worked as advertised. I wouldn’t want to rely on it if I am interested in saving the client time in terms of recovery and lost productivity due to missing email.