A couple of years ago, most SMB Exchange email migrations involved .pst files, or they were swing migrations that involved moving mailbox databases and remounting them, or moving mailboxes between one server and another. All that is changed now. Why? More and more, your clients will be moving back and forth between cloud and local storage, between hosted mail (whether that be Google Apps or Intermedia Hosted Exchange) and on-premises mail. Sometime you might have a multi-site corporation that wants to relocate. A growing percentage of the migrations being conducted now involve having to move data over WAN links, and that’s a game-changer.

So you have a migration planned, and you want to change MX records and cut over, but it looks like it’s going to take 5 days to migrate those 59gb of email down from the hosted provider! What do you do?

First, you think differently. No, I’m not talking about provisioning mac.com accounts, I’m asking us to stop thinking about the mail as a big chunk of data to be moved in one unit. Don’t even think of a single mailbox in that way. Start thinking about what part of the user’s mailbox they couldn’t live without for a day or two. The last two weeks of mail? The last two months? Once you’ve identified that interval that we’ll call “staple data”, make your plan: first cut over the MX record and immediately migrate that staple data. The reduced footprint of that data will turn your multi-day mailbox move effort into a several-hour effort. As soon as the staple data is in place on the new server, then begin the import of the rest of the data. I usually call that data the “historical backfill.”

Now how do you accomplish this date-delimited dissection of the mailbox? Pretty easily. All the basic tools we use or have used have all had date-specific parameters we can use during exports and imports. Exmerge had them, the PowerShell Export\Import-Mailbox commandlets have them. What are the other tools we can use? There’s one main other one that people aren’t usually familiar with. It’s called the Exchange Transporter Suite. It was built primarily to assist people in migrating from non-Microsoft mail platforms. In addition to tools to assist with Lotus migrations, it also has a very nice IMAP and POP migration tool. The IMAP tool is especially helpful for bringing client mail off of Google Apps and onto an Exchange server without having to do it from the Outlook client. Wouldn’t it be nice to do it in one place, all the mailboxes at once? Yep. It is. I’ll introduce you more formally to that tool in a future post.

How Come ExMerge Won’t Run?

One thing I’ve realized is that many SMB consultants aren’t sure how to move mail around in a world in which ExMerge isn’t easily accessible. That’s right, you can’t run ExMerge on an SBS 2008 or Exchange 2007 server to export\import mail. Ah, you might say, I’ve heard that you have to use PowerShell instead. Partly true, but you still can’t run the PowerShell import\export scripts on the server. You have to set up a separate management workstation to run them from. In fact, you can actually run ExMerge from a separate management workstation. The same change in functionality that will not let you run the PowerShell cmdlets on the server also “broke” ExMerge on the server.

The need for a separate management workstation to handle mail import\export procedures gets complicated for those who are trying to host their SBS 2008 box at a colo. In those situations, we’ve temporarily installed VMWare on the server and installed an XP Pro VM to use as a management workstation. Trying to handle the migration via a workstation connected to the colo via VPN is NOT a good idea.

So what’s involved in setting up a management workstation to run ExMerge or use the Import\Export scripts? I would suggest that you focus on running the PowerShell scripts rather than using ExMerge, but I’ll give you the details for both:

Installing ExMerge on a 32-bit Management Workstation

For ExMerge, you are going to follow the normal rules for running Exmerge on a workstation.

1. If on XP, install the IIS Snap-In component from the Add Components Add/Remove applet.
2. If on XP, install the Windows Server AdminPack tools.
3. Install the Exchange 2003 (yes, 2003) management tools on the workstation from the Exchange 2003 media. Ignore the schema error.
4. Download and install ExMerge on the workstation.
5. Pick or create a user who is not a member of the Domain Admins group to use for the import process.
6. Create an “ExMerge” group to assign Exchange permissions to and add the target user to the group.
7. Use the Exchange Management Console to delegate “Exchange View Only Administrator” control to the ExMerge group.

8. Give the ExMerge group Send-As and Receive-As rights. The easiest way to do this is in Exchange Powershell, like this:

Get-MailboxDatabase -identity “SERVER\First Storage Group\Mailbox Database” | Add-ADPermission         -user “DOMAIN\ExMergeGroup” -ExtendedRights Receive-As, Send-As

(You’d swap SERVER and DOMAIN\ExMergeGroup with the appropriate server name and domain and group names in your environment.)

You should now be able to log on to that workstation as a member of the ExMerge group and run ExMerge to pull data out of Exchange 2007 or migrate data into Exchange 2007. I will show you how to do date-delimited extraction later in this article.

If you are interested in knowing whether ExMerge will work in the same way with Exchange 2010, the answer is no, but you can read more about that in this helpful article by Alexander Zammit.

Getting Ready to use Import-Mailbox on a 32-bit Management Workstation

If you are going to use PowerShell to pull the mail into the new Exchange 2007 server (which I recommend), then you are going to need to get a workstation ready to run the import process on. This is mainly written with an XP system in mind.

1. Install these prerequisites: .Net Framework 2.0 and its update, MMC 3.0 (if on XP), and Powershell 1.0. Ah yes, and Outlook 2007 or 2010.
2. Download, extract and install the Exchange 2007 32-bit Management Tools. Make sure you download the version that matches the service pack level of your Exchange 2007 installation, otherwise you will have problems.
3. Pick or create an account that is NOT a member of the Domain Admins or any other privileged group in the domain. Add that user to the local Administrators group on the Exchange 2007 server.
4. In the Exchange 2007 Management Console on the server (click on Organization), use the Add Exchange Administrator action to grant that user account the Exchange Server Administrator role.
5. To import and export mail, you need to grant import user account Receive-As and Send-As permission on any mailbox databases on the Exchange 2007 server. To do that, run this command at an “escalated” Exchange PowerShell prompt:

Get-MailboxDatabase | Add-ADPermission –User Importer –ExtendedRights Receive-As,Send-As
(replace Importer with the name of the user that you created\picked.)

To import all the .pst files in a specific directory into appropriate mailboxes, just make sure that each .pst file is named to match the user’s mailbox alias (jsmith’s .pst would be called jsmith.pst), and then execute something like this:

Dir D:\PSTDump\*.pst | Import-Mailbox

This will look at each .pst, match it to it’s mailbox on the server and import the contents of the .pst.

To import a single .pst file that doesn’t match the mailbox name, you can do this:

import-mailbox jsmith@domain.com -pstfolderpath d:\PSTDump\johnnyboy.pst

You can also do date-delimited imports, but that’s primarily something you’d want to do as an export process in ExMerge. I’ll go over that now.

Date-Delimited Mail Exports using ExMerge

Using date-delimited exports is commonly used when mailboxes are very large and need to be exported in chunks in order to avoid the 2gb limit on ANSI .pst files. It is also useful when there are many mailboxes to be moved in a short time and it is not practical to move all the data at once.

Let’s create a scenario: It’s March 13th, 2010 and tonight we need to migrate 115 users from an Exchange 2003 server in one domain to an Exchange 2007 server in another domain. We’ve already migrated the user accounts to the new domain using LDIFDE, but now it’s time to migrate the mail. We changed the firewall’s configuration an hour ago so that new email is being delivered to the mailboxes on the new server. We’ve set up our export\import account and are ready to use ExMerge.

Because the total amount of mail on the server is equal to 79gb (yes, this is an urgent project!) and a dozen of the mailboxes are larger than 3gb, it would take quite a bit of time to export all the mail out this evening. What we will do is export the “staple data” first: all the mail from January 1st 2010 up till today. Because that is only 73 days of mail, the .pst file for each mailbox will will be relatively small, and the entire export process will probably take 35 minutes or so. Since ExMerge will automatically name the .pst file after the user alias, the exported files are ready to be imported into Exchange 2007 immediately.

Once the initial run of .pst files has been exported and then imported successfully, it’s time to start working on historical backfill. We will go back to ExMerge and begin running another date-delimited export covering all of 2009, choosing a separate directory as the destination. When that export finishes, we will use import-mailbox again (pointing it at the new directory) to bring that mail into the mailboxes on the new server. We can go backwards, year by year, until all the mail has been brought in. Since the most critical data has already been imported, the migration should seem smooth to the users even if data is continuing to be imported over the next 24 hours. It is the rare user that refers to 36-month old emails on a daily basis.

What if you have just set up Exchange 2010? Can the management workstation you set up for importing into Exchange 2007 still be used? Nope, while the strategies I’ve outlined here are still valid, you can only use a system set up with Exchange 2007 management tools to import data into an Exchange 2007 mailbox server. If you have SP1 loaded on Exchange 2010, you can run the new-mailboximportrequest and new-mailboxexportrequest commands to export or import to\from .pst files. See this article for more details: http://msexchangeteam.com/archive/2010/04/26/454733.aspx

Using strategies like these can reduce the stress of having to migrate a lot of mailbox data in a short time-frame, and make large-mailboxes less formidable seeming. I hope you find this helpful. Of course, if you’re in the middle of it and short on patience, go ahead and open a ticket, and I’ll help you out!

—–

So who wrote this blog and what do they do for a living anyway?
We’re Third Tier. We provide advanced Third Tier support for IT Professionals.
Get Support Blog Twitter Facebook LinkedIN