These tips and the Exchange 2003 wizard make mailbox moves a snap
Since its first version, Exchange Server has included a way to move a mailbox from one server to another. Microsoft improved the Move Mailbox Wizard in Exchange Server 2003 by allowing administrators to schedule moves and introducing multiple threads to process mailboxes. The wizard was updated in Exchange 2003 Service Pack 1 (SP1) to accommodate cross-site or cross–administrative group mailbox moves for mixed-mode organizations. You can find details about these improvements in "The Exchange 2003 Move Mailbox Wizard," February 2004, InstantDoc ID 41023, and "Demystifying Exchange 2003 Mailbox Moves," September 2004, InstantDoc ID 43146. In this article, I show you how to put the upgraded Move Mailbox Wizard and some mailbox-transfer tips to work to ensure a smooth move.
Before you move a mailbox, you should have a good reason to do so. With Exchange Server 5.5 and earlier, keeping users who exchange a heavy volume of email with each other on the same server is a good idea because it reduces traffic between servers and maximizes the effect of the Single Instance Storage model used by the Exchange Information Store. But today, many Exchange 2003 and Exchange 2000 Server systems support multiple mailbox databases and administrators tend to ignore Single Instance Storage. Improvements in network capacity, throughput, and availability make arranging users on servers according to email traffic patterns less important.
Good reasons to move mailboxes include locating them on servers that are managed by administrators who are physically close to the users or on servers that have specific features that the users need. For example, in the financial industry, you might want to put all the mailboxes used by traders on a server that's configured for email journaling.
MAPI Requirements and Database Size
You can move a mailbox to any server in your Exchange organization as long as sufficient connectivity exists between the source and target servers to accommodate the Messaging API (MAPI) remote procedure calls (RPCs) that Exchange will use to transfer the mailbox content and as long as the destination server has sufficient storage to accept the transfer. A server version of MAPI that's different from the client version used by products such as Outlook is present on every Exchange server. MAPI version incompatibility is the reason why Microsoft recommends that you don't install Outlook on an Exchange server. Exchange has always used server-side MAPI for administrative tasks, and although Internet protocols such as SMTP and LDAP are gaining popularity for interserver communication, Exchange still uses MAPI RPCs for some administrative operations such as moving mailboxes.
MAPI RPCs don't function well across extended high latency or low bandwidth connections, so it's important to select a target server to which Exchange can transfer a lot of data reasonably quickly. Transferring even a 100MB mailbox across a low bandwidth link can take a long time, and average mailbox sizes continue to grow. The number of items in a mailbox can affect the transfer time because Exchange performs less processing to move a smaller number of large items than to move many small items. Fast connections are less prone to RPC timeouts that can cause data loss and result in Exchange terminating the mailbox transfer.
Moving mailboxes doesn't reduce the size of the Store databases on the source server, but you'll probably see a larger database on the target server. Any increase is dependent on the size of the mailboxes being moved and the amount of white space (i.e., unused database pages) in the target database. The only way you can reduce the size of a database after you have transferred mailboxes from it is to perform an offline rebuild with the Eseutil utility, which probably isn't worthwhile unless you know that you can recover many gigabytes of space. Note that a mailbox move will fail if you attempt to move mailboxes to a target server that runs Exchange Server Standard Edition and if that move will cause that server's single mailbox Store to exceed the 16GB limit imposed by Exchange Server Standard Edition. Microsoft plans to increase the 16GB limit in Exchange 2003 SP2, but you'll still need to comply with the new limit.
The Move Mailbox command is exposed as an option in the Exchange Task Wizard, which you can access through the Microsoft Management Console (MMC) Active Directory Users and Computers console (in Exchange 2003 and Exchange 2000) or the Exchange System Manager (ESM) console (in Exchange 2003). You can run either console from a Windows XP workstation as long as the workstation has adequate RPC connectivity with both the source and target servers.
First, open the console and select the mail-enabled object that you want to move. Note that Exchange won't let you move a system mailbox or the mailbox used by the SMTP service because these are special mailboxes that are tied to their home server. Then start the Exchange Task Wizard and select the Move Mailbox option. Click Next, and the following wizard page allows you to select the target server and mailbox store, as Figure 1 shows.
Figure 2 shows how to instruct the wizard to deal with problem items in the source mailbox. Prior to Exchange 2003, the move-mailbox code stops processing if it encounters a corrupted item. With Exchange 2003, you can specify how you want the wizard to deal with corrupted items and opt to either stop and create a failure report or skip corrupted items. You can specify how many corrupted items the wizard can skip per mailbox. Note that the wizard will delete the corrupted items as it encounters them during the move. The wizard suggests 3 as the maximum number of corrupted items to skip, but the GUI will let you go as high as 100. If the number of corrupted items in a mailbox exceeds the threshold that you set, the move will fail. The default value is appropriate; you shouldn't attempt to move a highly corrupted mailbox. A mailbox that holds more than a few corrupted items is a sign that some fundamental problems exist in the underlying database.
Some corruptions are caused by problems in client-server communication that result in bad or missing MAPI properties for an item, others are caused by software bugs in either Exchange or a client, and some result from minor database corruptions caused by hardware problems, usually in the storage subsystem. You can fix minor corruptions by running the Isinteg utility against the problem database; more critical problems can be fixed only through a complete offline database rebuild with the Eseutil utility.
Scheduling a Move
Exchange 2003 introduces the ability to move mailboxes on a scheduled basis. In earlier versions, Exchange processes mailbox moves immediately after an administrator initiates the move, so if you want to move mailboxes when server activity is quiet, you have to wait until then to start the move. If you schedule a move by using the Task Schedule window that Figure 3 shows, the Exchange 2003 system attendant process creates a thread that runs in the background until the scheduled time arrives, at which point, the system attendant starts the move. The second option on the Task Schedule page (obscured in Figure 3) allows you to specify a time at which Exchange will terminate any task still running. For example, you could set a cut-off time of 8:00 A.M. to ensure that mailbox moves don't continue into a time of peak demand. If a mailbox move is in progress at the cut-off time, Exchange will continue to transfer contents until that mailbox is complete, but it won't proceed with any other mailboxes that you have queued to be moved.
During the Move
The first step the wizard takes in moving a mailbox is to make MAPI connections to the source and target servers. Once the connections are established, the wizard starts to transfer content and reports its progress as shown in Figure 4. Exchange 2003 uses as many as four threads to move as many as four mailboxes at a time, allocating one thread per mailbox. Previous versions of the wizard are single-threaded and can therefore process just one mailbox at a time. Exchange 2003 also allows you to move multiple groups of mailboxes concurrently, with each move operation using as many as four threads.
While a move is in progress, the processing thread sets the MAPI PR_IN_TRANSIT flag on the source mailbox. This flag indicates to the Store that the mailbox contents are being moved and prevents the Store from delivering new messages to the mailbox. The mailbox user can continue to access mailbox content while the move is in progress but can't receive or send new mail. Users are also unable to log on to their mailboxes once a mailbox move starts (the Store logs event ID 9660 when a user attempts to log on to a mailbox during a move). To avoid potential problems, most administrators ask users not to use their mailboxes during a move. For users who use Outlook 2003 in Cached Exchange Mode, you can set Outlook to offline mode to work with the offline copy of the mailbox. When users reconnect to Exchange after the move is finished, Outlook updates their profiles automatically to point to the server that now hosts their mailboxes and synchronizes any changes, including the delivery of new mail.
During a move, the wizard also sets the PR_IN_TRANSIT flag for the new mailbox on the target server to prevent new messages from being delivered there. Exchange 2003 places any messages that arrive for a mailbox in transit into the Deferred Delivery queue. The Store and the Advanced Queuing engine reroute these messages to the moved mailbox after the move is complete. Exchange 2000 handles incoming messages differently: It holds the messages in a special folder within the Store and reroutes the messages via the Message Transfer Agent (MTA) after the move is completed. If the move fails for any reason, the thread resets the PR_IN_TRANSIT flag to let the Store deliver any waiting messages before you try to move the mailbox again.
For best performance, Exchange uses the MAPI IMapiProp::CopyTo() function to move a mailbox as one object rather than moving individual mailbox items. The fact that Exchange uses a function that specifies a complete mailbox as the object to work with doesn't mean that Exchange attempts to push the complete mailbox to the target server in one step. It merely indicates that Exchange transfers all the items in the mailbox from start to finish without pausing after each item to confirm that it should continue to transfer items.
The Store holds a single copy of each item's content (including attachments) in its database and uses pointers to indicate the mailboxes in which the item is present. The advantage of this model is obvious: A message with a 10MB attachment sent to 10 mailboxes in the same database occupies just 10MB instead of the 110MB required if the Store held each message for the sender and each recipient. During a move, the Store uses a message's unique identifier to check whether the message is already present in the target database. If it is, the Store creates a new pointer to the content rather than creating another copy. Depending on the performance characteristics of your server, especially the disk subsystem, you can expect to move between 400MB and 2GB of mailbox data per hour for a single mailbox, with an increase (albeit not a linear increase) in the amount of data when Exchange uses multiple threads.
If the wizard succeeds in moving the mailbox, it then updates the directory information (in Active Directory—AD—for Exchange 2003 and Exchange 2000 mailboxes and in the Directory Store for Exchange 5.5 mailboxes), including the HomeMDB (name of the owning mailbox store) attribute and HomeMTA (name of the owning MTA) attribute and the msExchHomeServerName attribute on Exchange 2003 and Exchange 2000 servers. If you move a mailbox from an Exchange 2003 server to an Exchange 2000 or Exchange 5.5 server, the thread removes the attributes that Exchange 2003 uses for Outlook Mobile Access (OMA) because these aren't valid on the earlier versions. If the wizard fails to update the directory, it treats the move as unsuccessful and rolls everything back.
The wizard then resets the PR_IN_TRANSIT flag on the mailbox on the target server to allow the user to access his or her mailbox and completes the move by deleting the contents of the original mailbox from the source server. After all mailboxes are processed, the wizard displays the Task Summary screen, which lets you view the move log. As you can see in Figure 5, the log is in XML format, so you can either view it raw or format it with an XML style sheet into something more readable.
The Store records each moved item in the current transaction log on both the source and target servers. You can expect the number of transaction logs generated by a mailbox move operation to be equal to at least the size of the transferred mailboxes divided by 5MB (the size of a transaction log) plus 5 percent overhead. For example, moving a 100MB mailbox generates at least 21 logs on both the source and target server.
Check that the disks on both servers have enough free space for the transaction logs. You can free up the space occupied by the additional logs by running a full backup after all the mailbox moves are finished. This is a wise step anyway to ensure that you don't have to move the mailboxes again if a catastrophic database failure happens before the next scheduled backup.
All versions of Exchange support mailbox moves and Exchange 2003 offers the best functionality yet. Once you've decided that you need to move mailbox data between servers, the process is pretty simple.