You probably know that you can't upgrade in-place to Microsoft Exchange Server 2010 from older versions of Exchange, so moving mailboxes is the only way to migrate user data to the new platform. Although the move mailboxes concept isn't new, the implementation in Exchange 2010 incorporates some innovative aspects to ease migrations. This article reviews how the Exchange 2010 move mailbox feature works and shows why the new approach taken by Microsoft makes a real difference.

Swelling Mailboxes
In all previous versions of Exchange, mailbox moves are executed within the process that initiates the move. In other words, if you initiate a mailbox move with the management console of Exchange 2007 or Exchange 2003, the move continues until the last item has been transferred from the source to the target server. During this process, the administrator can do nothing else with the console and the user is locked out of his or her mailbox because Exchange needs exclusive access to ensure that it can transfer the full mailbox content reliably. This process works and is well understood by administrators, so why change it?

The answer lies in the ever-swelling size of mailboxes. It's OK to disconnect users to move their mailboxes when the standard mailbox quota is 100MB and only a few mailboxes might grow to the giddy heights of 1GB or more. It's quite another matter when the average mailbox quota grows to 1GB and it's common to find mailboxes with quotas of 10GB or more. Indeed, in November 2009, Microsoft announced its intention to provide 25GB mailboxes to subscribers to its hosted version of Exchange ("Global Organizations Choose Microsoft Cloud Applications") in a direct competitive move against Google, who also provides 25GB mailboxes to users of Gmail for business ("Run your business, not your email server").

It's all very well to assign 25GB of storage to a mailbox as long as that storage never has to move—or if it can be moved without affecting the user. In fact, Microsoft designed Exchange 2010 as a platform to elegantly handle very large mailboxes, and many of the changes developers made to the Exchange Information Store are to reduce the impact on the server of multigigabyte mailboxes that contain tens of thousands of items. Changes have also been made in Microsoft Office Outlook 2007 SP2 and later versions (including Outlook 2010, expected to be released around June 2010) to make sure that Outlook performs much better when asked to access large mailboxes.

The server and clients seem set to support large mailboxes, but as administrators are all too aware, mailbox mobility is a part of regular system management; it's a technique used to move users to new servers or to balance mailbox activity across available servers. In a world of large mailboxes, it simply becomes too slow and administratively unwieldy to disconnect users for long periods to move their mailboxes from server to server. We're moving into a world where the distinction between on-premises and cloud services blurs and companies will expect to be able to move users seamlessly between the two environments. In a nutshell, these are the reasons why the need to disconnect mailboxes before they can be moved has been replaced by a new mechanism involving move requests that are processed by the Mailbox Replication Service (MRS).

Move Requests
A move request states that an administrator wishes to move a specific mailbox from a database to another database. The databases can be on an Exchange 2010 server or on a legacy Exchange 2007 SP2 or Exchange 2003 SP2 server in the same or a different organization. Note that we don't talk about source and target servers anymore. The focus in Exchange 2010 is on databases because databases, not servers, are the management entity in Exchange 2010. As you probably know, Exchange 2010 databases can have multiple copies and can move between Mailbox servers. It doesn't make sense to refer to source and target servers because you don't know which server hosts the currently active copy of the database to which you want to move a mailbox.

You create move requests with Exchange Management Console (EMC) or by using the New-MoveRequest cmdlet with Exchange Management Shell (EMS). In either case, you can select a group of mailboxes and have a separate move request generated for each. You can sort mailboxes by database to make it easy to select a group from a specific database. In Figure 1, you can see I've selected a group of mailboxes to move from one database to another, then clicked New Local Move Request in the Actions pane of EMC, which invokes a wizard that generates the move requests. You can generate a group move like this if the destination database is the same for all mailboxes. If you need to move mailboxes to different databases, you have to go through the wizard separately for each destination to generate the move requests.

A local move request is a move to another database in the same Exchange organization. A remote move request is a move to a database in another Exchange organization, a feature designed to support companies that operate multiple Exchange organizations or who want to migrate from one Exchange organization to another, possibly as a result of a merger or acquisition.

The remaining steps of the wizard ask what to do if corrupt items are found in the source mailboxes. You can skip the entire mailbox and fail the move, or you can let Exchange ignore a certain number of corrupt items. The default option is to skip the mailbox, which seems extreme unless the mailbox is very new. Older versions of Exchange were less exact about item formats, and if you have mailboxes that have been used with Exchange 2003 or Exchange 2000 or have been migrated from a different email system, there's a reasonable chance that some mailboxes will contain a few corrupt items.

If you opt to skip corrupt items and Exchange encounters some during the move, they'll be ignored and you might lose some data, albeit data that can't be read by Exchange 2010. I typically set the value to 5 to let Exchange skip as many as 5 corrupt items during a move. You can check the move logs to find out if any corrupt items were found. Exchange stores details for the last two moves of a mailbox as hidden items in the mailbox's root. As you'll see later, you can access these reports with the Get-MailboxStatistics cmdlet. When everything is ready, click OK and the wizard generates the move requests for each mailbox.