By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
- Move Mailboxes
Migrating using the Move Mailbox approach
Moving user mailboxes between servers is the safest migration method because the servers' databases are not in jeopardy if the migration fails. Moving the users also provides the opportunity to use new hardware with little or no downtime. In addition, moving users allows the organization to migrate users in sizeable chunks over time. Outlook profiles automatically are updated on the desktop, and users are redirected to the new Exchange Server 2003 systems when they log on. The limitation of moving users to a new server is that they can be moved only to an Exchange Server 2003 system in the same Administrative Group. Moving users can also slow the speed of the migration, which can be seen as a positive or negative, depending on the organization's goals.
The Exchange Server 2003 database is much more efficient than Exchange 5.5 was at storing messages. Even with full copies of all messages created by moving the users, administrators might actually see the database size shrink when comparing the size of the Exchange 5.5 and Exchange Server 2003 databases before and after migration. Quite a bit of empty space in the Exchange 5.5 database might also account for a portion of the reduced database size.
To move user mailboxes, open the Active Directory Users and Computers administrative tool and right-click the user to move; then select Exchange Tasks, as illustrated in Figure 15.8.
- Click Next at the welcome screen.
- Choose the option for Move Mailbox and click Next.
- Select the destination server and mailbox store, and click Next.
- At the next screen, choose either to create a failure report if corruption is detected or to skip corrupted items and continue the mailbox move. Click Next to continue.
- At the next prompt, you can specify what time the Move Mailbox command should start and finish by. This is very useful when scheduling mailbox moves for off-hour periods. Click Next to continue.
Connections are then made to the source and destination server, and the mailbox contents are moved four at a time, as illustrated in Figure 15.9. If the move is unsuccessful, the user's mailbox still is available on the source Exchange 5.5 server.
Leapfrogging server migrations to reduce costs
If server hardware or budget is a limiting factor in the project, the organization might want to consider using a leapfrog method (also called the swing upgrade method) to migrate the users to Exchange Server 2003. Using the leapfrog method, fewer servers need to be purchased to perform the migration through the move users method.
One server still needs to be installed into the Exchange 5.5 site to house the SRS. Users can then be moved to that server or a second Exchange Server 2003 system installed into the site. After all users, connectors, and public folders are moved off the Exchange 5.5 server, that server can be formatted and reinstalled as an Exchange Server 2003 system, allowing the next Exchange 5.5 server's users to be migrated to Exchange Server 2003.
This greatly reduces the speed of the migration process and also requires a Native Mode Windows Server 2003 domain to support the public folders if they are scattered across the Exchange 5.5 servers. Another option for public folders in this scenario is to consolidate the public folders by replicating all the folders to a single Exchange 5.5 server in the site if a Native Mode Windows Server 2003 domain is not available. Connectors could also pose a problem with this method and require a solution before starting the leapfrog process.
One problem with this leapfrog method to be aware of is to not remove the first Exchange 5.5 server in a site until it's the last remaining system in that site. The first Exchange server in the site hosts folders and other functions that are required by the Exchange 5.5 organization.
Using ExMerge to migrate mailboxes
Exmerge.exe is a Microsoft utility that can extract the contents of a user's mailbox to a personal store (PST) file. The PST file created by ExMerge can be added to a user's Outlook profile so the user can access the contents of his old mailbox. ExMerge can also import the PST file to a destination mailbox to another server, site, or organization. On the destination server, ExMerge can merge the imported PST file or overwrite data in the target mailbox.
ExMerge can be used in disaster recovery and in migration scenarios to move user data from point A to point B by selecting the source and destination Exchange servers. ExMerge can be used when an organization wants to start with a clean Exchange Server 2003 environment and wants to be able to move mailbox contents to the new Exchange Server 2003 mailbox or archive the contents of the Exchange 5.5 mailbox in case a user needs access to his old information. ExMerge can also be used to move mailbox contents in organization-naming hierarchies that are the same or different. This is beneficial to organizations that want to build a new naming context when converting to Active Directory and Exchange Server 2003.
A few issues should be considered when using ExMerge to move mailbox contents to a new organization. The biggest one is that the capability to reply to all recipients on old messages could be lost. At a minimum, end-users need to force the names on old messages to be resolved against the new directory by using Alt+K or the Check Name button on the toolbar. End-users might be confused and frustrated if the new system cannot locate all of the users. This can occur if all users have not been migrated from the old organization or if mail connectivity to foreign mail systems has not been re-established in the new Exchange organization. To avoid these problems, every migrated mailbox must have the X.500 address of the old organization added to it, either manually or via a third-party tool.
The second-biggest issue is that appointments on the user's calendar that contain other attendees are severed. The original appointments were resolved to the attendee's old addresses when they were created. This means that if the user deletes the appointment or makes a change to the time or location of the meeting, the other attendees will not be notified.
Even with these issues, ExMerge can be just the thing organizations are looking for, especially when they have survived multiple mergers and acquisitions and are looking to start over with Exchange Server 2003. If the organization plans to use ExMerge for the entire migration process, spend extensive time prototyping the merge process to catch other issues the organization might encounter.
ExMerge merges the following information:
- User folders
- User messages
- Outlook calendars
- Folder rules that were created in Exchange 5.0 or later
ExMerge does not support the following:
- Schedule+ data
- Folder rules that were created in Exchange 4.0
ExMerge also supports advanced options such as extracting folder permissions. It can filter the messages for extraction from the source store by attachment name or subject that are accessible under the Options button on the source server selection screen.
ExMerge can be configured in either a one- or a two-step merge process. One-step merge processes copy the data from the source mailbox to a PST and then merge the data into the same mailbox on the destination server. The distinguished name of the mailbox and container path of the source and destination servers must be identical to perform a one-step merge.
When using ExMerge to move mailbox data from different organizations and sites, administrators need to be aware that ExMerge cannot create a mailbox on a destination server or set alternative recipient and forwarding rules on the source server. Another item that administrators should be aware of is that ExMerge runs only on Windows Server 2003. ExMerge needs to be able to access several Exchange Server 2003 DLL files. To run ExMerge, copy the Exmerge.exe and Exmerge.ini files to the Exchange \bin directory, or update the system path to include the Exchange \bin directory if ExMerge will run from another file location.
To run ExMerge using Exchange 5.5 as the source and Exchange Server 2003 as the destination, the credentials used for ExMerge must have Service Account Administrator privileges in Exchange 5.5 at the Organization, Site, and Configuration container levels. The credentials must also have at least Receive As permission on the destination Exchange 2003 mailbox.
Migrating from Exchange Server 5.5 to 2003 -- 11 tips in 11 minutes
Tip 1: Comparing Microsoft Exchange Server 5.5 and 2003
Tip 2: Prerequisites for migrating to Exchange Server 2003
Tip 3: Structuring an Exchange migration for the best results
Tip 4: Preparing the Active Directory forest and domain
Tip 5: Installing and configuring the Active Directory Connector
Tip 6: Installing the first Exchange 2003 system in a 5.5 site
Tip 7: Understanding Exchange 2003 mailbox migration methods
Tip 8: Migrating Exchange Server 5.5 public folders to 2003
Tip 9: Migrating Exchange 5.5 connectors and services to 2003
Tip 10: Completing the migration to Exchange Server 2003
Tip 11: Best practices for migrating from Exchange 5.5 to 2003
This chapter excerpt from Microsoft Exchange Server 2003 Unleashed, by Rand Morimoto, is printed with permission from Pearson Education, Copyright 2005. Click here for the chapter download or purchase the book here.
Dig Deeper on Exchange Server Deployment and Migration Advice