Recovering a Mailbox Database after Accidental Deletion from Active Directory

Not too long ago some colleagues wanted to know how to recover an Exchange 2010 mailbox database in the event someone was to actually delete the database object from Active Directory. Kind of an odd request since the Exchange Management Shell & the Exchange Management Console prevents you from doing this on a database with mailboxes still on it but an interesting scenario to play with.

So let’s say a hapless Jr. Admin is playing around in ADSIEDIT or maybe even LDP (Active Directory for Grown Ups if you ask Exchange Principal Program Manager Greg Taylor) & accidentally deletes a Mailbox Database object from AD. Doesn’t matter how many copies of that database you have in your DAG, its lifetime is now tied to the speed of your AD replication.

So what do you do? Likely the best answer is for you to perform an Active Directory Authoritative Restore; this assumes of course that you have one & you know how to do it. It can also mean a serious undertaking if you’re in a large global environment. I suppose you could also immediately shut down your Domain Controllers in that AD Site before it has a chance to replicate the deletion to the other AD Sites.; then setup a new DC in that site ASAP. That also has its issues in terms of outages.

So I feel that in a crappy situation you should always have a clear understanding of all your options. So here’s another one that involves the old database file switcheroo & some Exchange shell commands.

So in this scenario I have a couple test mailboxes (TestUser1 & TestUser2) on a database called TestDB1 in an Exchange 2010 Environment.

The below screenshot shows via OWA that we have an email in the inbox for TestUser1 which is ultimately residing within the .EDB Jet database file for TestDB1.

Now let’s live life on the edge & get rid of TestDB1 via ADSIEDIT (children & the squeamish may wish to divert their eyes).

Now that wasn’t that bad. Let me just run a Get-Mailbox command to verify the mailboxes are still present in Active Directory…..

Uh oh… I’m met with yellow text which states:

WARNING: The object ASH.COM\Users\TestUser1 has been corrupted, and it’s in an inconsistent state. The following validation errors happened:
WARNING: Database is mandatory on UserMailbox.

It’s important to note that while the Mailbox Database object has been removed from AD, the actual database files have remained untouched; so all of the mailbox data is still intact. I didn’t test this but I imagine the database itself would still remain mounted until the next time the Information Store Service was restarted or its cache of AD info expired. However, transport to/from that database or IIS would likely be the first components to fail.

So how do we fix this using a method not already listed above? Simple, just move the existing database files to a safe location (good idea to use Eseutil /mh to confirm the database is in a clean shutdown) & then create a new Mailbox Database in EMC with the same name as the one you just accidentally deleted.

Note: We’re about to create a blank database that users could be accessing & mail can potentially flow to. So to prevent data loss or Outlook .OST files being affected, go ahead & Disable/Stop the Microsoft Exchange Transport Service as well as the RPC Client Access Service so that no mail can be delivered to this database & no Outlook clients can access it.

Once the new blank (aka Dial-Tone) database is mounted, go ahead & dismount it.

Delete all the database files within this new mailbox database. Move the original .EDB file into the new database’s location (assuming it was in a Clean Shutdown state after running the Eseutil /mh command).

Go to the Properties of the Mailbox Database in EMC & check the box for “This database can be overwritten by a restore”. You should now be able to mount the database.

Go to Exchange Management Shell & run a Clean-MailboxDatabase against this database.

You should now see the “Inconsistent/Corrupt” mailboxes showing up in the “Disconnected Mailboxes” pane in EMC (in my example below, TestUser2 isn’t showing because I already fixed him before taking this screenshot).

You can now use the “Set-Mailbox” shell command to set the Mailbox to use the Database in Active Directory. This value got nulled-out after the accidental deletion which caused the object to be corrupt/inconsistent. EX: Set-Mailbox TestUser1 –Database TestDB1

You can now set the Information Store & RPC Client Access Services back to Auto & Start them. At this point the user should be able to login to their mailbox & access their original inbox with all data still there.

And that’s it. It may not be the method your organization uses to recover from this particular situation but I feel it’s important to understand your options & if anything, this serves as a demonstration of the flexibility you have with Database Portability as well as Shell. This same process can be used in Exchange 2013 with only the Management Tools being different.