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.
Late last week it came to my attention that in Exchange 2010 SP1, Microsoft made some major changes to the way we export mailboxes to PST files. While I usually say that I embrace change, I don't when it comes to applications I manage.
For those familiar with Exchange 2007, the Export-Mailbox cmdlet was a nice and easy method to take some email and dump it into a PST. All you had to do was provide yourself full access to the mailboxes you were looking to export and run the cmdlet. Well goodbye Export-Mailbox, hello
New-MailboxExportRequest.
How does this new New-MailboxExportRequest cmdlet work? Well, don't even try to run it until you have made some security modifications. Before even being able to run this cmdlet, you need to add the new Import Export security role to a Role Group. If you don't do this, you will not even be able to run the cmdlet.
Add the Import Export Security Role to a Role Group:
- Create a new universal security group to provide the Import Export role to. ie: Enterprise Support
- Populate the group with the account(s) you want to perform the mailbox exports to.
- Run the below command from the Exchange Management Shell:
New-ManagementRoleAssignment -Name "Import Export_Enterprise Support" -SecurityGroup "Enterprise Support" -Role "Mailbox Import Export"
- Close and re-open the Exchange Management Shell.
- For a complete explanation of this process, you can peruse the following Microsoft article:
http://technet.microsoft.com/en-us/library/ee633452.asp
An Additional Note on Security:
Microsoft has changed how this process works as it now uses the Mailbox Replication Service. Because of this, you must ensure that the Exchange Trusted Subsystem group has read/write access to the network share you are going to save your PSTs to. If you were paying attention to my last sentence I did use network share. The syntax of the New-MailboxExportRequest cmdlet looks for a UNC path so make sure you provide access for that group.
Exporting Mailboxes:
Now that Exchange security is all set, it's time to export some email. The general process is pretty straight forward, pick your mailbox then set your file path (UNC of course) and you're done.
New-MailboxExportRequest -Mailbox AylaKol -FilePath \\MBX-01\PSTFileShare\Ayla_Recovered.pst
For complete details on how to run this command you can check out http://technet.microsoft.com/en-us/library/ff459227.aspx
Normally, we never just have to export 1 mailbox, it is usually all mailboxes or a large group which can be in achieved in a number of ways. For those of you not 100% comfortable with Powershell, I've found that Excel and the =Concatenate command help make excellent .bat files. For all of the powershell guru's out there, I'm sure creating loops with variables that read names from .txt files will be no problem.
Importing Mailboxes:
Importing Mailboxes uses the same security roles so there are no additional pre-reqs. This is utilizes the New-MailboxImportRequest cmdlet. You can find complete details on the command here:
http://technet.microsoft.com/en-us/library/ff607310.aspx
I hope everyone finds this posting to be helpful.
Well not really that long ago, this is actually a brand new for me. I just decided today to start blogging about my experiences as an IT professional. Since none of you know me, I am a systems engineer for a NJ based energy company. My main areas of expertise are in Microsoft server technologies specifically Exchange, Active Directory and plane old Windows Server along with vSphere and many more. My job responsibilities entail life-cycle management, developing infrastructure standards and solutions for the company. You can expect to hear about severs, storage, and applications of all sorts from many different vendors. Like many of you, I'm not quite able to specialize on one specific application or technology and need to maintain a broad skill set to properly do my job.
So why am I doing this? As I write this I'm currently in Atlanta for MS TechEd 2011. While preparing for the conference, I spent some time looking through the discussion boards and stumbled upon the Twitter Army. This is a group of conference attendees who committed (as much as people commit online) themselves to tweeting the hell out of the conference. This includes the sessions they attended, what they did for meals, vendors they spoke with, and the fun after hours. Prior to Teched, I had not used twitter for anything because I didn't really get it, but figured I would give it a try and join the army.
Much to my surprise, Twitter is pretty excellent and has been extremely useful throughout TechEd. It really provided me with another perspective on the conference and gave me access to a whole community that I never would have known existed had I not become such a junkie. I'm happy to say that I finally get it but don't quite know how it will translate to my every day life. People at work don't use it and I know that tweeting decisions that come from meetings probably wouldn't go over all that well (or am I on to something), so instead I have decided to take out my social media frustrations on this blog. I hope you all enjoy.