Exchange 2010 made significant advancements in providing out-of-the-box Archiving, together with improved High Availability and Resilience functionality. This is likely to cause a decline in demand for brick level backups. Nevertheless, the occasional need to transfer mailbox content to/from PSTs is unlikely to go away completely.

From ExMerge to Import-Mailbox/Export-Mailbox

Do you remember the time when Exchange 2007 was released and Service Pack 1 was not yet available? In those days, many were angry for not having a supported method to export/import mailboxes to/from PSTs. ExMerge, the tool of choice in Exchange 2003 and earlier, was on its way out making space for the new export-mailbox and import-mailbox cmdlets. Exchange 2007 SP1, apart for filling this void, also addressed some major ExMerge limitations. Most notably it brought Unicode support and the ability to have PSTs larger than 2GB.

Despite the advancements, the Exchange 2007 cmdlets still shared a common characteristic with ExMerge. This was the intricate procedure in getting the functionality to work. In the past we dedicated three articles discussing the setup requirements in different scenarios:

Meeting the ExMerge Requirements

Using ExMerge with Exchange 2007

Replacing ExMerge by Import-Mailbox and Export-Mailbox

It Started with an Error!

Having written an article on setting up these cmdlets in Exchange 2007, I was uncertain if there would be any need to revisit this topic. I changed my mind as soon as I saw the error export-mailbox returned on Exchange 2010:

"To export to or import from a .pst file, the 64-bit version of Outlook 2010 or later must be installed on the server to which you are connecting (HAMRUN.wtest-dom1.local)."

Following that error I looked up the Export-Mailbox TechNet documentation, and found this:

"To export data from a .pst file, you must run the Export-Mailbox cmdlet against an Exchange server that has the 64-bit version of Microsoft Outlook 2010 installed. We recommend that you run the command on a dedicated Exchange server that doesn't have any mailboxes."

These two bits of information immediately highlight some changes in the cmdlet usage requirements.

1. Outlook 2010 - Outlook was also required in Exchange 2007 since it provided the necessary PST drivers. So the need for the latest Outlook version is not surprising.

2. 64-bit - This is already more interesting. Exchange 2007 required the use of a 32-bit platform. We had to install the Exchange 2007 32-bit Management Tools on Windows XP (for example) and run the cmdlets from there. Exchange 2010 does not provide a 32-bit build any longer and quite obviously the 2010 cmdlets had to support 64-bit platforms.

3. Install Outlook on an Exchange 2010 mailbox server! - This is the one that took me by surprise. In Exchange 2007 we had to setup a separate machine from which to run these cmdlets. It is now a requirement to install Outlook on the Exchange server and run the cmdlets from there. Actually we can run the cmdlets from another machine (will see this later), however the key point is the need to install Outlook on an Exchange mailbox server.

As the previously quoted TechNet documentation explains, the recommended setup is to have a dedicated Exchange server that doesn't have any mailboxes.

So far I did not come across any official information regarding the supported configurations where Outlook 2010 and Exchange 2010 can be run on the same machine. Please post a comment if you come across anything in this regard. Quite obviously having Outlook on a dedicated Exchange Mailbox server without mailboxes should be supported. However I can imagine that smaller shops with a single server setup won't be keen to go that way.

Account Rights

Apart for the already listed changes, there is a fourth very welcome improvement. In Exchange 2007 and earlier, assigning the necessary rights for a user to perform the import/export operations used to be the most troublesome part. Most notably the user had to be assigned rights on all mailboxes against which the cmdlets were to be run.

Exchange 2010 greatly simplifies matters. As we shall see, with the new Exchange 2010 Role Based Access Control (RBAC), all that is necessary is to assign the user the "Mailbox Import Export" role.

Setup Procedure

Now that we know all the relevant changes introduced in Exchange 2010, preparing a machine to run these cmdlets is fairly simple:

1. Install Exchange 2010 Mailbox Server. We discussed the basic Exchange installation steps in Installing Exchange 2010 Beta. On my test network I worked with a single server having Hub, Client Access and Mailbox server roles installed. Considering that at the time of writing Outlook 2010 is still beta I would definitely not recommend doing this on your live server.

   One option is to wait for Outlook 2010 to be final. Hopefully the Outlook support status will be fully clarified by then. Otherwise if you cannot wait, the dedicated server option sounds safe especially since such a server can easily be decommissioned if the necessity arises.

2. Download and install Outlook 2010 on the Exchange Server. Of course you don't need the entire Office 2010, only Outlook:

   

3. Open the Exchange Management Shell and assign the user account the "Mailbox Import Export". Here I am assigning the role to the Administrator account:

   New-ManagementRoleAssignment -Role "Mailbox Import Export" -User Administrator

   

   Following that, I had to reopen the command shell for the Role assignment to take effect.

This is it; the Administrator will now be able to run the import-mailbox/export-mailbox cmdlets.

Note1: On my test network I was able to get the system to work without ever opening Outlook. Of course I also tested the system following the setup of an Outlook profile and everything worked fine. So as far as I can tell whether or not Outlook is configured should make no difference.

Note2: Unless the "Mailbox Import Export" role is assigned, running the cmdlets returns an error that could be confusing:

"The term 'export-mailbox' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again."

Running the Import/Export from another Machine

It is also possible to run the cmdlets from a machine other than Exchange, however there's a catch. First of all this won't save you from having to install Outlook on to the Exchange server. So you will still need to follow the setup procedure on the Exchange Mailbox server discussed earlier.

Following that, install the Exchange 2010 Management Tools on another 64-bit machine. In my case I am using Windows 7.

That's it, users having the "Mailbox Import Export" role are now able to run the cmdlets. Note how I did not even install Outlook on the Windows 7 machine.

However, as promised there's a catch. Even though you are running the cmdlets from another machine the operation is actually carried out on the Exchange server where Outlook is installed. This means that if for example you want to export a mailbox with the command:

Export-mailbox -Identity alex -PSTFolderPath c:\Mailboxes

The path C:\Mailboxes is actually referencing a location on your server machine and not the local machine.

Final Tips

The Exchange 2010 setup necessary to run the import-mailbox/export-mailbox cmdlets changed significantly from its predecessor. With the help of RBAC, assigning the necessary rights for running the cmdlets, has been greatly simplified.

The new Exchange 2010 Archiving and High Availability features will hopefully diminish the need for these cmdlets. In any case if the necessity arises, you are now ready to get everything up and running.

References

Replacing ExMerge by Import-Mailbox and Export-Mailbox

Download and install Outlook 2010

Export-Mailbox TechNet documentation