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.

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.

2 thoughts on “Recovering a Mailbox Database after Accidental Deletion from Active Directory”

Hello,
Thanks a lot for detail and step by step information, I must admit it is a unique way to recover data. However nowadays most of the organizations are opting for easy and fast solutions like third party recovery tool for recovering corrupt or lost data.

Pushkar, people are relying on these solutions you mention because they do not have the kind of knowledge that this article details. most admins shy away from this kind of thing, when in truth it is vital that such information is possesed in order to react quickly to such a situation, especially when on a budget and not having the $$$ to fork out for (unneccesary) Third part tools. Great Article.

Tools

Whether a mailbox is used by multiple users as a collaborative tool or a communication gateway to customers, retaining a record of emails sent from a shared mailbox remains an important business requirement. In Exchange 2010, there was a way to configure this behavior, but we did not have this feature starting with Exchange 2013. Our customers have told us t […]

This morning we released the complete list of sessions offered at Microsoft Ignite, including the full list of Exchange sessions. Ignite is the premier event for the Exchange community, bringing together the people who build Exchange and those who work with it every day. If you are one of the many Microsoft Exchange Conference (MEC) alumni, Ignite is the evo […]

Stuart Miller is a 28 year old Database Administrator working at Blood Systems, Inc. Previously, he worked at one of the world's largest transportation and logistics corporations and started working in IT at the University where he was studying for his B.S. in Computer Science. In the last 11 years, he has taken a diverse set of roles including Unix Sys […]

Ellon has over 14 years of hands-on professional experience with SQL Server in multiple roles including architecture, development and administration. Currently he leads the database team at Campus Management Corp which focuses on building highly scalable enterprise-class solutions leveraging SQL Server for the higher education space. Ellon plans to blog i […]