If you would like to read the next part in this article series please go to A look at the Import/Export Mailbox improvements in Exchange 2010 Service Pack 1 (Part 2).
A Trip Down Memory Lane
Before we make it to the Exchange 2010 SP1 improvements, I want to first take a step back in time, more specifically, back to 1996. Back then, Exchange 4.0 RTM’d and quickly thereafter the Exchange 4.0 Resource Kit (second edition) was made available. One of the most popular tools on the Resource Kit media was without doubt the Microsoft Exchange Mailbox Merge Program (Exmerge.exe) tool, which could be used to extract data from mailboxes on one Exchange 4.0 server and merge it into the same mailboxes on another Exchange 4.0 server or simply extract the data to PST files that was needed for other purposes. So it was a great tool both for disaster recovery and migrations.
Figure 1: Microsoft Exchange Mailbox Merge Program (Exmerge.exe) tool
I remember that some people even used the tool as a mailbox-level backup solution instead of a real brick level backup solution that by the time were delivered by the major 3rd party backup vendors on the market. By the way weren’t those brick-level backup times just fantastic?
With and between each Exchange Server version all the way up to Exchange Server 2003, the ExMerge.exe tool was improved significantly. For instance, it could be used to remove messages with specific subjects and data ranges from mailbox stores. I remember the tool saved a lot of organizations during virus outbreaks such as back in 2000, when the SMTP borne virus – “ILoveYou” virus spread quickly primarily via mailing lists and from there infected most organizations around the world. Back then many actually used ExMerge to clean the mailbox stores from thousands of “ILoveYou” messages using ExMerge. The ExMerge.exe tool has also been used for many other things over the years especially for inter-organization Exchange migrations.
ExMerge.exe used the native MAPI provider included with Exchange Server 4.0 all the way up to Exchange 2003. This meant that you did not have to worry about manually installing the Messaging API (MAPI) client libraries or an Outlook client on the machine on which you wanted to run ExMerge.exe. Actually it was not even supported to install the Outlook client on an Exchange Server prior to Exchange 2007 as the two MAPI providers could conflict.
During the development of Exchange 2007, the Exchange Product group thought that it was time to replace the ExMerge.exe tool with native PowerShell based functionality. When Exchange 2007 RTM’d came two new cmdlets known as Import-Mailbox and Export-Mailbox.
What came as a big surprise to many was that you couldn’t just log on to an Exchange 2007 64-bit server and then export the mailbox data to a PST file using the Export-Mailbox cmdlet. Actually, it was not possible to export data to a PST file from a 64 bit based Exchange 2007 server. Instead, you had to run this cmdlet on a server or client machine with the 32-bit version of the Exchange 2007 System Management tools installed. In addition, you had install Outlook 2003 SP2 or later on this machine. Yes I’m not kidding here, and the reason why this was required was because Exchange 2007 unlike earlier versions of Exchange Server didn’t include a MAPI provider.
Another big disappointments with the Exchange Server 2007 RTM version was the lack of being able to export an Exchange 2007 mailbox to a personal folder (.PST) file using the Export-Mailbox cmdlet. You see with Exchange 2007 RTM, you could only export data to a folder in another mailbox not to PST files.
Although the Microsoft Exchange Server 2003 Mailbox Merge Wizard (ExMerge) tool allowed us to extract mailbox data from an Exchange 2007 mailbox to a PST file, this scenario wasn’t tested and therefore not recommended nor supported by Microsoft. As you can see this situation wasn’t ideal, so something had to be done to make this possible. The solution came with Exchange 2007 SP1 as this service pack allowed us to export data to a PST file using the Export-Mailbox cmdlet (uncovered in an old article of mine).
Exchange 2010 RTM still uses the Import-Mailbox and Export-Mailbox cmdlets that were introduced with Exchange 2007, and although the support for remote PowerShell improves things a little by allowing you to run these cmdlet’s remotely on a desktop or server without the Exchange 2010 Management tools installed, you still need to install Outlook 2010 64-bit on the Mailbox server itself. In addition, the cmdlets have shown to be relatively error prone in Exchange 2010 RTM.
Exchange 2010 Service Pack 1 which is under development and will be released later this calendar year changes things once again, and this time I think the Exchange Product group managed to deliver a great solution when it comes to importing and exporting data to and from mailboxes.
With Exchange 2010 SP1, the Import-Mailbox and Export-Mailbox cmdlets has been replaced with a new set of cmdlets named New-MailboxImportRequest and New-MailboxExportRequest.
Even better, the Exchange Product group also thought it was a good idea to get rid of the requirement of the Outlook 2010 MAPI provider. Instead Exchange 2010 has its own MAPI provider (again some would say) and did I mention that these two new cmdlets take advantage of the Exchange Mailbox Replication Service (MRS) which makes it possible to import or export data via an asynchronous process just like when you move mailboxes using the New-MoveRequest cmdlet.
Alright enough history, let’s have a look at the new cool import/export stuff in Exchange 2010 SP1.
Permissions Required to run the Mailbox Import/Export Requests
By default no one is granted the permissions necessary to import and export data to and from mailboxes in Exchange 2010 SP1, not even users in the Exchange Organization Administrator role group. So before continuing, we need to assign the user or group that we want to grant the necessary permissions to the “Mailbox Import Export” management role.
For instance, to assign the management role to all users in a group called “Mailbox Support”, I would use the following command:
New-ManagementRoleAssignment -Name “Import Export Mailbox Admins” -SecurityGroup “Mailbox Support” -Role “Mailbox Import Export”
Figure 2: Assigning the necessary management role permissions to users that need to import/export mailbox data
New Import and Export Mailbox cmdlets in Exchange 2010 SP1
Earlier I mentioned we had two new cmdlets at our disposal, but this is not completely true. Unlike Exchange 2007 and 2010 RTM, we have 14 cmdlets. I have listed all of them below with a short description. We will of course take a closer look at each of these later on in this articles series.
- New-MailboxImportRequest – This cmdlet is used to import all or some data from a PST file to an Exchange 2010 SP1 mailbox or online archive. There’s no limitation to how many import requests you can create for a given mailbox, but note that a unique name only will be created for the first 10 requests. It should be rare you need to create more than 10 requests for a single mailbox. The cmdlet checks for duplication of items, so you will not end up with duplicates in the mailbox even though you create multiple requests for one mailbox. When creating a new import request you can specify things such as included or excluded folders, whether dumpster should be imported, what MRS server to use and so on.
- Get-MailboxImportRequest – This cmdlet is used to view detailed information about mailbox import request. The cmdlet will give us information about things such as file path for PST file, target database, mailbox name, status of the import and so on.
- Get-MailboxImportRequestStatistics – This cmdlet is also used to view detailed information about mailbox import request, but provides much more information than the Get-MailboxImportRequest cmdlet. In addition to what we can see with the Get-MailboxImportRequest cmdlet, this one also provides information such as Status detail, sync stage, target Exchange GUID, whether dumpster is excluded, bad item limit, how many bad items encountered, start time, completion timestamp, overall duration of the import, percent complete and so on.
- Remove-MailboxImportRequest – This cmdlet is used to remove a completed or ongoing import request. Note that completed imports won’t be removed automatically, they need to be removed by the Exchange admin. Also bear in mind that if you remove an ongoing import request, the data that has been imported already won’t be reverted back.
- Resume-MailboxImportRequest – This cmdlet is used to resumes a suspended or failed import request. You can suspend an import request when you run the New-MailboxImportRequest cmdlet or after using the Suspend-MailboxImportRequest cmdlet.
- Set-MailboxImportRequest –This cmdlet is used to change options of an already created import request. It can also be used to recover from a failed import request.
- Suspend-MailboxImportRequest – This cmdlet is used to suspend one or more ongoing import requests. The import request must be suspended before it reaches status “completed”.
- New-MailboxExportRequest – This cmdlet is used to export all or some data from a mailbox or online archive mailbox to a PST file. There’s no limitation to how many export requests you can create for a given mailbox, but note that a unique name only will be created for the first 10 requests. It should be rare you need to create more than 10 requests for a single mailbox. The cmdlet checks for duplication of items, so you will not end up with duplicates in the PST file even though you create multiple requests for one mailbox or online archive mailbox. When creating a new export request you can specify things such as included or excluded folders, whether dumpster should be exported, what MRS server to use and so on.
- Get-MailboxExportRequest – This cmdlet is used to view detailed status of an ongoing export requests initiated using the New-MailboxExportRequest cmdlet.
- Get-MailboxExportRequestStatistics – This cmdlet is used to get detailed information about any ongoing export requests initiated using the New-MailboxExportRequest cmdlet.
- Remove-MailboxExportRequest – This cmdlet is used to remove a completed or ongoing export request. Note that completed exports won’t be removed automatically, they need to be removed by the Exchange admin. Also bear in mind that if you remove an ongoing export request, the data that has been exported to a PST file already won’t be reverted back.
- Resume-MailboxExportRequest – This cmdlet is used to resumes a suspended or failed export request. You can suspend an export request when you run the New-MailboxExportRequest cmdlet or after using the Suspend-MailboxExportRequest cmdlet.
- Set-MailboxExportRequest – This cmdlet is used to change options of an already created export request. It can also be used to recover from a failed export request.
- Suspend-MailboxExportRequest – This cmdlet is used to suspend one or more ongoing export requests. The import request must be suspended before it reaches status “completed”.
There’s no doubt about it, the new cmdlets overall are much better than the old relatively limited and error prone Import-Mailbox and Export-Mailbox cmdlets. But there are a few things missing that were available with the old cmdlets. Parameters such as “-StartDate”, “-EndDate”, “-AttachmentFileNames”, and “-DeleteContent” didn’t make it into the new cmdlets, but for the first three parameters mentioned the “-ContentFilter” parameter comes to the rescue. This parameter allows you to filter exported content like the aforementioned parameters did, but adds several other options (for details see the Exchange 2010 SP1 TechNet documentation). There’s no replacement for the “-DeleteContent” parameter though. To delete the content of a mailbox, you must use the Search-Mailbox cmdlet with the “-DeleteContent” parameter.
Alright we have reached the end of part 1, but you can look forward to part 2 which will be published in the near future. In part 2, I will take you through using the above cmdlets in a step by step fashion plus provide you with plenty of exciting information as we move on.
If you would like to read the next part in this article series please go to A look at the Import/Export Mailbox improvements in Exchange 2010 Service Pack 1 (Part 2).
