We recently implemented an email archiving solution at work. One of the requirements was that we configure automatic purging of messages older than 6 months in Exchange.
One of our IT managers spent the better part of a month moving items out of the only copy of his PST into his mailbox so that they could be captured by the archive system and free him from his PST. For whatever reason none of these messages were captured by the archive system and were purged by Exchange as per the items older than 6mo managed folder rule. It took the manager 3 weeks to realize this so I had to come up with a creative way to get these messages back.
Today’s post covers how I was able to recover messages from his dumpster out of a 3 week old database backup.
Step 1: The Restore
Without boring you too much, the first thing required was to create a recovery database using the New-MailboxDatabase cmdlet.
New-MailboxDatabase –Recovery –Name RecoveryDB –Server MAIL1 –EDBFilePath D:\Recovery\DB\Recovery.edb –LogFolderPath D:\Recovery\Logs
The –Recovery option is very important as it specifies your new database as a recovery database.
Once the database was built, I made sure to leave it offline and called in the Operations team to redirect the database restore in BackupExec to the Recovery Database. Complete the restore then mount your database.
Step 2: Pulling Data from the Recovery DB
In order to restore mail from a recovery database you must have another mailbox on a live database. Exchange does not allow you to take data from the RDB and move it directly to a PST file, it must first be moved to a mailbox. There are actually two mail recovery cmdlets for Exchange 2010 SP1. The first one I used was restore-mailbox. This cmdlet is great however after 3 hours I learned that if you want to recover dumpster data, this is NOT the one to use.
The proper powershell command to use is New-MailboxRestoreRequest. In addition to restoring email and dumpster data, you can also use this on disconnected and disabled mailboxes. The most important thing to know is that mailbox you list after –Identity is the target mailbox you want to restore mail to and –RecoveryMailbox is really the source mailbox you are copying mail from. Also the –TargetFolder option is also helpful as you can specify where data should go to. This is especially helpful if you are restoring data to the mailbox of a live user.
New-MailboxRestoreRequest –identity targetuser –RecoveryMailbox sourceuser –RecoveryDatabase RecoveryDB –TargetFolder RecoveryFolder
Like my last post, this process is also managed by the Mailbox Replication Service. This gets queued up and to get the status you can run Get-MailboxRestoreRequest with no attributes. Once the process is completed you will have a live mailbox full of someone else’s data along with all of their dumpster items.
Step 3: Dumpster Diving
There are several ways to get mail out of the dumpster depending on what you need to do with it. The first is to export the mailbox to PST. You can do this using the New-MailboxExportRequest cmdlet. For more information on how to use that, check my last post Exporting Mailboxes to PSTs. This will take all contents of the mailbox and put it in a PST. The items from the dumpster will be found under \Recoverable Items.
The command I chose to use was Search-Mailbox. Similar to the previous step, you will require yet another live mailbox to export the mail to as it cannot be exported to itself. Since this cmdlet is part of the enhanced auditing tools in Exchange 2010 I suppose it makes sense that you’d want to export the results to a separate mailbox but was obnoxious for my purposes. Another reason I chose this cmdlet is because of the –searchdumpster option which let’s you do what it says. So away I went:
Search-Mailbox –Identity SourceUser –TargetMailbox TargetUser –searchdumpster –TargetFolder DumpsterRecovery
Once this command completed I was able to open up the TargetUser mailbox in Outlook and there, see picture below, I found all of the lost messages purged by Exchange and ignored by my archiving system. Hopefully, I’ll never have to do this again and neither will you.
To give some credit where it is due, Andy Olson’s blog post Working With Exchange 2010 Recovery Databases was essential in helping me figure out where to begin.