Computing environments change all the time. Systems administrators add hardware and software, and users move among servers. Network administrators must take these facts in stride and accommodate change when necessary. Therefore, Microsoft Exchange Server administrators need to know how to move user mailboxes. Exchange Administrator makes moving mailboxes between servers in the same site a breeze, but the process of moving mailboxes between servers in different sites requires manual work. Like any task that involves manual intervention, moving mailboxes between sites opens up the possibility that administrators might make a mistake—for example, forgetting to update distribution lists or permissions on a public folder. Moving mailboxes between sites can be so problematic that some system designers reduce the number of sites in an Exchange organization if they know that the organization's user population is prone to move between offices. Fortunately, several tools can help you move mailboxes within and between sites.
Why Move Mailboxes?
Administrators typically assign user mailboxes to servers according to the users' work groups. This organizational design takes advantage of the old 80/20 rule for email, which predicts that 80 percent of a user's messages go to recipients within the user's primary work group and only 20 percent of a user's messages have recipients outside the user's work group. This ratio obviously varies among companies, but most users send most of their messages to people they work closely with.
If the 80/20 rule describes many of your users, keeping users who are in the same work group on one server saves storage space on your server and reduces network activity. Exchange Server uses the single-instance storage model to save messages with multiple recipients on the same server—Exchange Server stores one copy of the messages' content and attachments, and the recipient mailboxes access the content and attachments via a system of pointers. When a user sends a message to multiple recipients, Exchange Server sets the message's reference count to the number of mailboxes with pointers to the message. When the user of one mailbox deletes the shared message, Exchange Server decrements the message's reference count by one. When the reference count reaches zero, the Information Store (IS) removes the content from the database. If one server holds mailboxes for all a message's recipients, the message takes up a minimal amount of space in your servers' ISs. The smaller your ISs, the less time you'll need to spend backing up your systems and performing other administrative activities. Therefore, if most of your users send messages primarily to members of their work group, you'll save time and money by keeping users in each work group on the same server.
In addition, making sure users' mailboxes are on the same server as mailboxes for the rest of their work group can reduce network traffic. The IS delivers messages to mailboxes on the same server as the sender's mailbox, so Exchange Server doesn't route those messages through the network. The Message Transfer Agent (MTA) must handle messages that users send off the server, so those messages generate network traffic.
Finally, if users physically move to a new location, leaving the users' mailboxes on their current server might require the users to have an extended network connection to their mailboxes. Such an extended network connection generates network traffic every time users check their inboxes, and the users experience slower response from Exchange Server than they would experience if their server was nearby. Users don't care about extra network traffic, but they tend to hate anything that slows response.
For these reasons, moving mailboxes to increase the number of messages that the mailboxes can share might be a good idea for your organization. However, before you move any mailboxes, think about whether you really need to move them. Moving mailboxes has a few disadvantages. First, moving mailboxes takes time. Second, when you move a mailbox off its current server, you lose the efficiency of the single-instance storage of any messages the mailbox shares with other mailboxes on its current server. Third, when you move mailboxes, the mailboxes' users temporarily lose email service.
Exchange implementations vary greatly. Avoiding mailbox moves is probably a good tactic if your servers hold thousands of user mailboxes in a centralized environment. But if you have users distributed in small groups across the country, moving mailboxes might be a good idea, because providing fast service usually requires users to be close to the server that hosts their mailboxes.
The Move Mailbox Function
If you decide to move mailboxes from one server to another within the same site, you can do so easily. Select one or more mailboxes from the list of the server's recipients in Exchange Administrator, then click Tools, Move Mailbox. Exchange Server will prompt you with a list of servers in the site. Select the server you want to move the mailboxes to, and click OK to start the move.
When you move mailboxes, messages and other items such as e-forms and attachments must move between servers. Exchange Administrator uses standard Messaging API (MAPI) remote procedure calls (RPCs) to transfer these mailbox items; Exchange Server transfers the data as a stream of messages to the target server that continues until the transfer completes.
Exchange Server treats the data transfer like it treats every other insertion into the IS, so the target server's transaction logs report the traffic. This logging means that if each of your logs is 5MB, transferring a mailbox that contains 30MB of content would create six log files just to hold the messages. The IS also expands depending on how much data the mailbox move transfers. Therefore, always ask users to purge their mailboxes before a move. A reduced number of messages makes the transfer of mailboxes proceed faster and decreases the move's strain on the IS.
Users of MAPI clients don't even notice when you use the Move Mailbox function to move their mailboxes. Users of non-MAPI clients (i.e., Web browsers, Post Office Protocol 3—POP3—clients, and Internet Message Access Protocol 4—IMAP4—clients) have to change the server name in their profile to connect to the correct server after you move their mailboxes. But users of MAPI clients don't have to make such a change because Exchange Server redirects MAPI client connections to the new server and updates the profile the first time MAPI users attempt to access their mailboxes after the mailboxes move.
Move Mailbox Side Effects
Exchange Administrator doesn't move the contents of a mailbox's deleted items cache when it moves the mailbox. The deleted items cache (available only in Exchange Server 5.5) holds items for a retention period after the user deletes them. You can define a default retention period for all mailboxes, then allocate specific retention periods for certain users. For example, you might want to give your company's senior executives shorter retention periods than you give the rest of your users because your corporate lawyers want the executives' messages to be unrecoverable shortly after the executives delete them. (For more information about setting up a deleted items cache, see "Maintaining Exchange's Information Store," May 1998.)
The Move Mailbox function has a couple of known problems. Most of these problems occur when you move mailboxes in Exchange Server 4.0 or Exchange Server 5.0. For more information about some of the side effects of moving mailboxes in versions of Exchange Server earlier than version 5.5, review the Microsoft articles "XADM: Calendar Reminders Not Functioning After Move Mailbox" (http://support.microsoft.com/support/kb/articles/q178/6/98.asp), "XADM: Possible Loss of Mail with Move Mailbox" (http://support.microsoft.com/support/ kb/articles/q168/1/88.asp), and "XADM: Delegates Unable to View New Messages After Move Mailbox" (http://support.microsoft.com/support/ kb/articles/q178/6/99.asp).
I have experienced only one problem moving mailboxes between servers in the same site in Exchange Server 5.5: Exchange Server sometimes resets the seen map (which tracks the items a user has read so that Exchange Server can display unread items in boldface) for public folders that a moved user accesses. Exchange Server directs users to local replicas of public folders. If the server a user's mailbox is on contains a replica of a public folder the user requests, Exchange Server directs the user to that replica. If the user's server doesn't have a replica, the user accesses a public folder replica on another server in the site. Exchange Server resets the user's seen map for a public folder if, after the move, the user accesses a replica of the folder that differs from the one the user accessed before the move. This problem is minor, but it can be distracting for users who access public folders extensively. Regardless of which version of Exchange Server you use, test the Move Mailbox function before implementing it to ensure that it works properly in your environment.
Intersite Mailbox Movement
Moving mailboxes between sites is much more difficult than moving mailboxes within a site because of the way the Exchange Directory references objects such as mailboxes. The Directory gives each object a unique distinguished name (DN). You can view a mailbox's DN by running Exchange Administrator in raw mode; type
admin /r
at a command prompt. Exchange Server stores the mailbox's DN in the Obj-Dist-Name property, as Screen 1, page 116, shows. The mailbox in Screen 1 has the DN
/o=Digital Equipment Corporation/ou=Dublin/cn=Recipients/cn=TonyR
This DN tells me that the mailbox belongs to the Digital Equipment Corporation organization and the Dublin site. The mailbox object is in the Recipients container, and it has the unique alias TonyR. (Aliases are unique only within a container, so another mailbox with the alias TonyR might exist in another container elsewhere in the organization.)
The root of the difficulty with moving servers between sites is the fact that the site name is part of the mailbox's DN. If I want to move a mailbox to another site, the /ou portion of the mailbox's DN must change. Likewise, if I want to move a mailbox to a container with a different name, the first /cn portion of the mailbox's DN must change.
These requirements cause problems because many Exchange Server functions reference DNs. Exchange Server uses DNs to route messages, to identify mailboxes within MAPI profiles, and to relate data in the IS to the mailbox. Changing a mailbox's DN is serious business.
If you can, design your Exchange Server implementation so that you never need to move mailboxes between containers with different names; use Address Book Views (ABVs) instead. ABVs sort objects in the Directory to let you keep all your mailboxes in one container but provide users with different views of the container's contents. For example, my Exchange Server organization uses an ABV to sort recipients by company and country so that I can find people quickly, as Screen 2 shows.
Utilities Help the Move
Warnings aside, you can move a mailbox between containers or sites if you must. Microsoft provides no out-of-the-box tools with Exchange Server for moving mailboxes between containers or sites, so you have to look further afield for help with this task. The Microsoft BackOffice Resource Kit contains two utilities—Exmerge and Migrate—that help you move mailboxes between containers or sites. I usually recommend using the latest version of tools, because software tends to improve in functionality and quality over time. Therefore, I recommend using the Exmerge and Migrate tools in the resource kit's second edition, which Microsoft released in 1998. Microsoft has updated Exmerge since releasing the resource kit's second edition. The latest version of the utility (2.32) adds useful features and fixes a few minor bugs; for example, the new version lets you process only specific folders or move only items that meet date criteria. However, Microsoft hasn't provided any formal mechanism for distributing Exmerge 2.32. If you want the latest copy of Exmerge, you'll have to request it from your local Microsoft contact. The Exmerge version in the resource kit's second edition works well, and administrators have used it successfully in many large projects, so I see no compelling reason to worry about obtaining the new version.
Both Exmerge and Migrate aim to automate the process of exporting mailbox data to a personal store and then importing the data into a new mailbox on the target server. Manually exporting and importing data is tedious, and the operation becomes more irksome when you're moving mailboxes that contain more than a few megabytes. You'll appreciate the tools if you ever move a mailbox between sites.
Exmerge is newer than Migrate and is my favorite of the two tools, even though Exmerge requires NT 4.0 Service Pack 3 (SP3) and is available only for Intel servers. Migrate runs on both Intel and Alpha systems. You can use Exmerge to move mailboxes between Alpha servers, as long as you run the utility on an Intel server that's running Exchange Server and as long as the Intel and Alpha servers can communicate. To decide which tool works best for you, test both tools and review the available documentation (which is skimpy). You can find information about the utilities in the exchange\docs\exchtool.hlp folder on the resource kit CD-ROM. The Microsoft article "XADM: How to Use the Mailbox Migration Utility" (http://support.microsoft.com/support/kb/articles/q177/7/76.asp) provides tips for running Migrate.
Exmerge isn't perfect, but the utility gets the job done. If you choose to use the resource kit's version of Exmerge, use the following advice to make your mailbox move as smooth as possible.
Set Expectations for Exmerge
Exmerge provides two methods for moving mailboxes. If the sites you're moving mailboxes between connect via a network link that's 64Kbps or faster and you have administrative permissions in both sites, Exmerge moves mailboxes in a one-step process. However, Exmerge can't create mailboxes. You must set up new mailboxes on the target server for the old mailboxes' data to move into, and you must access the mailboxes once before you run Exmerge. The easiest way to ensure you're ready to run Exmerge is to send a message to all the mailboxes you're moving data into before you run the utility.
If you don't have administrative privileges in your target site, you can use Exmerge to export mailbox data to a personal store. Then, you can provide the systems administrator in the target site with the personal store, and the other administrator can run Exmerge to import the data into the new mailbox. You have to use a similar two-step process if the names of the source and target sites' recipient containers don't match.
Running Exmerge or handing a personal store to the administrator of another site isn't the only step you need to take to move mailboxes between sites. Whether you use Exmerge to move mailboxes in a one-step or two-step process, you must manually remove or disable the old mailboxes, hide them from the Global Address List (GAL), and update permissions on public folders and distribution lists.
I can't stress enough the importance of good coordination among administrators. Exporting mailbox data is pointless if the systems administrator in the target site isn't ready for or doesn't expect to import the data.
Run Exmerge
Exmerge runs on an NT 4.0 workstation or server that's running SP3. To begin Exmerge, log on under an account that has administrative permissions for the Exchange Server system you want to move mailboxes from. Experienced administrators report that you will obtain the best results if you use the Exchange Service account, but any account with the necessary permissions will suffice. After you start Exmerge, the program asks you to identify the server that holds the mailboxes you want to move, as Screen 3 shows. Later in the migration process, Exmerge logs on to the source server to access mailbox data.
Next, Exmerge prompts you to select the mailboxes you want to move, as Screen 4 shows. You can select one mailbox or multiple mailboxes. Exmerge exports the contents of each mailbox to a separate personal store. If you can, export the mailboxes to a local disk to speed up the data transfer. Exmerge processes data on a 233MHz Pentium server at about 5MB per minute, so exporting large mailboxes can take a while. Exporting data on servers with fast disks and CPUs or performing the move when your server has a light workload will speed up this pace, but the operation won't be fast. If you plan to migrate many mailboxes and you have access to several NT workstations, consider running Exmerge on several machines concurrently, letting each computer process a small group of mailboxes. Make sure the users whose mailboxes you're moving are logged off when Exmerge processes their mailboxes.
As Screen 4 shows, Exmerge's Mailbox Merge wizard clearly displays each mailbox's size and estimates the amount of space that mailbox's personal store will require. Exmerge might tell you that each mailbox's personal store will be approximately the same size as the mailbox; this estimate is optimistic. Storing mailbox contents in a personal store always requires more space than storing the same information on a server. One reason for this difference in space consumption is that Exchange Server doesn't compress personal stores. Another reason is that Exmerge stores messages as Rich Text Format (RTF) and ASCII files because you might use different clients to connect to the personal store. For planning purposes, estimate that your mailboxes will double in size when you export them. Expect a 30MB mailbox to become a 60MB personal store. The size of personal stores will vary, but you want to make sure you have enough disk space available for the amount of data you need to process. Fortunately, personal stores consume space only temporarily. However, don't delete personal stores too soon after you move the mailboxes they hold data for. Always wait until you're sure the move caused no problems and the user can access all mailbox data before you remove the old mailbox or delete the personal store.
When you've selected all the mailboxes you want to move, Exmerge can begin the data transfer. Screen 5 shows the Mailbox Merge Wizard dialog box that updates you about how the move is proceeding. As Exmerge moves your mailboxes, keep an eye on the utility's activities to ensure that it is accessing the correct mailboxes and that the move is progressing according to plan.
After Exmerge exports a mailbox's contents, the utility either proceeds to import the data into a mailbox on the target server or exits to let you pass the resulting personal store to the target site. Always verify that the import works properly. Ensure that the new mailbox contains all the old mailbox's folders and items. Also, you can check Exmerge's log files. The utility logs its activities in C:\exmerge.log by default, but you can change the filename when you run Exmerge. I encourage you to be reasonably paranoid and to back up your Exchange Server systems before and after you move any large amount of data. You certainly don't want to have to move mailboxes again if your target system crashes shortly after you transfer the data.
The final step in the mailbox-moving process is to let users know that they have to reconfigure their MAPI profile to point to their new mailbox. Some installations perform this step automatically by editing logon scripts to create the new profile the next time a user connects.
Single-Instance Storage
If you move a mailbox to another server in the mailbox's site, Exchange Server avoids creating redundant copies of messages by checking each message's interpersonal message identifier—a unique value that identifies a message within the database—against the target server's IS before transferring the message. Exchange Server doesn't create a new copy of a message if it discovers the message's interpersonal message identifier in the database it is moving the mailbox to. Instead, Exchange Server increments the message's reference count by one and places a pointer to the content in the new mailbox. This method effectively maximizes the strengths of Exchange Server's single-instance storage model.
However, Exmerge and Migrate don't perform similar checks when they move mailboxes between sites. The utilities don't check interpersonal message identifiers when they import messages and attachments from a personal store into the target server's IS. If some of the messages these utilities copy already exist on the target server, the utilities create redundant copies of the messages.
The Boy Scouts Are Right
When you need to migrate mailboxes, you can't afford to assume that nothing within the mailbox will change. As the Boy Scouts advocate, be prepared. Before you take on mailbox moves, take the time to understand and test the various methods and tools you have available so you know how to approach the task.
The good news about mailbox movement is that Active Directory (AD) in Windows 2000 (Win2K—formerly NT 5.0) lets you use Exchange Server to move mailboxes between sites and between containers with different names. AD uses DNs to reference mailboxes, but it uses a globally unique ID (GUID) to recognize objects internally. In AD, DNs can change, but GUIDs remain intact, so moving mailboxes between sites in Win2K won't require as much work as it requires today.
