Lesson 2: Multiphase Migration Strategies
Most organizations refrain from using the big-bang approach to migrate their messaging environments and opt to perform multiple steps. Multiphase migration is attractive because it allows you to determine your own pace to move to Exchange 2000 Server. However, migrating in multiple steps does not free you from developing single-phase migration strategies. As a matter of fact, you need to develop several single-phase strategies to complete the multiphase migration project. There is also one additional element. You need to integrate Exchange 2000 Server with the existing messaging system to enable migrated and non- migrated users to seamlessly communicate with each other. The systems must coexist until the last resource is migrated.
This lesson tackles the additional element that you need to address in a multiphase migration, which is the requirement for seamless interoperability with the foreign messaging system. You will read about the routing of messages in a heterogeneous environment and the maintenance of global address information. You can also learn how to preserve existing e-mail addresses and how to ensure that messages sent to the old recipients arrive in the new Exchange 2000 mailboxes.
After this lesson, you will be able to
- Describe the advantages and disadvantages of multiphase migration strategies.
- Build a consistent global address list (GAL) in an environment where users move from the old system to Exchange 2000 Server.
- Develop a multiphase migration strategy according to the specific needs of your organization.
Estimated time to complete this lesson: 60 minutes
Understanding Multiphase Migration
The purpose of the multiphase migration is to move users in comprehensible numbers to Exchange 2000 Server—similar to boarding an airplane (board rows 49 and higher, then rows 20 and higher, and so forth). Among other things, this gives you the means to provide training to the end-user community in stages. It is often feasible to train between 20 and 25 users in one session. According to the training schedule, your project team can gradually deploy Outlook 2000 on users’ desktops and move the mailboxes to the new system.
The following are the most important advantages of the multiphase migration. You can
- Synchronize end-user training and migration activities.
- Continue to support complex workgroup applications on the old system until new versions are available for Exchange 2000.
- Reuse old hardware for new systems, similar to the leapfrog upgrade strategy discussed in Chapter 6, "Designing an Upgrade Plan to Microsoft Exchange 2000 Server."
- Minimize the system downtime per migration step.
- Migrate heterogeneous messaging environments to Exchange 2000 Server without consolidating the resources in the old environment prior to migration.
- Migrate large organizations in a coordinated manner according to departments, business units, or teams.
The most significant disadvantage of the multiphase approach is the need for coexistence with the foreign messaging system. Several issues are important, such as uninterrupted message transfer, consistent address book information, and calendar integration, and it is not always simple to achieve the desired level of interoperability. Another disadvantage is that the multiphase approach is less compelling than the single-phase strategy. You can migrate all users or only some of them. There is a risk that your multiphase migration will slow down and end in a heterogeneous environment with yet another additional messaging system.
Note
Regardless of the size and complexity of your messaging environment, strive to complete the migration in less than 12 months. If this appears to be an unrealistic time frame, consider adding more resources to the project team or narrowing down the project scope, as discussed in Chapter 2, "Preparing for a Microsoft Exchange 2000 Server Deployment Project."
The following are the most important disadvantages of the multiphase migration:
- Compared to single-phase migrations, multiphase migrations are more time consuming and therefore more expensive.
- Multiphase migrations are less compelling than single-phase migrations.
- Some features may be unavailable between the foreign messaging system and Exchange 2000 Server. For instance, advanced message attributes may be lost due to message conversion performed by gateway connectors.
- The network must sustain an increased amount of data traffic, which results from the need to communicate with users on the old system, as well as directory synchronization and calendar interoperability.
- You need to connect the foreign messaging system to the new Exchange 2000 organization in such a way that both platforms appear as part of the same messaging environment.
Planning for Coexistence
As explained in Chapter 4, "Assessing the Current Messaging Infrastructure," you can connect Exchange 2000 Server to foreign messaging systems either directly or by means of a common messaging backbone. If possible, use a direct messaging connector and perform automated directory synchronization.
Connecting to a Foreign Messaging System
It is easy to determine which messaging connector to use (the names are usually very indicative, such as Connector to Lotus cc:Mail), but it is not that simple to determine the best way to run the systems together. Among other things, you need to avoid performance bottlenecks. This might require you to implement multiple high- performance bridgeheads to achieve an optimal transfer rate. Multiple bridgeheads are necessary because it is generally not possible to configure multiple gateways of the same type on a single Exchange 2000 bridgehead server. With the exception of the MS Mail connector, all gateway connectors are able to connect to only one system in the foreign messaging environment (see Figure 7.5). The foreign system can then route the messages further to down-level post offices.
Figure 7.5 - Multiple message paths to the same foreign messaging environment
When configuring multiple messaging connectors to the same foreign environment, you need to carefully outline the system configuration to avoid message loops and other transfer problems. For instance, in the environment shown in Figure 7.5, an Exchange user in Seattle may send a message to a cc:Mail user in Seattle via the Exchange 2000 server and cc:Mail post office in Washington, DC. The WAN would have to handle two message transmissions, whereas only one transfer in the LAN of Seattle was needed. You have two options to avoid this problem: You can either restrict the scope of the connector instances to the local routing groups or provide detailed routing information for each connector in the connector’s Address Space tab. Table 7.3 illustrates both configuration options.
Table 7.3 Address Space Configuration for Multiple Connector Instances to the Same Foreign System
| Configuration | Illustration |
|---|---|
| Restricting the connector scope to the local routing group | A locally scoped cc:Mail connector |
| Configuring detailed address spaces | Globally available connectors with detailed address spaces |
The difference between both configuration options is that with locally scoped connectors, message routing between the post offices is performed in the foreign messaging environment. For instance, a message from Seattle to ccPO2 would take the following route: Connector to Lotus cc:Mail (Seattle), ccPO1, Lotus cc:Mail Router, ccPO2. Conversely, globally available Exchange 2000 connectors with detailed address spaces allow you to route the messages in the Exchange 2000 organization to the best connector first and then transfer the messages to the foreign system directly. For a message from Seattle to ccPO2 this would mean: SMTP Connector to Washington, DC, Connector to Lotus cc:Mail (Washington, DC), ccPO2. The situation will determine which message routing topology is preferable. More often than not, you should choose to route the messages in the Exchange 2000 organization to benefit from Exchange 2000 Server’s powerful routing capabilities. The Exchange 2000 Server message routing based on link state information (LSI) is discussed in Chapter 5, "Designing a Basic Messaging Infrastructure with Microsoft Exchange 2000 Server."
It is important to note that it is not possible to provide fault tolerance through multiple gateway connector instances. For example, if you assign globally available connectors in Seattle and Washington, DC the same address spaces (such as CCMAIL: * at *), messages may be routed to either one of the connectors. Exchange 2000 Server considers the messages delivered as soon as they are placed in a particular gateway connector’s message queues, so message rerouting does not occur if this connector has transmission problems. However, it is possible to configure a general address space (CCMAIL: * at *) and more detailed address spaces per connector to provide a default as well as specific message paths. More detailed address spaces take precedence over general placeholders. You can read more about message routing and the configuration of foreign messaging connectors in MCSE Training Kit—Microsoft Exchange 2000 Server Implementation and Administration.
Configuring Proxy Address Information
Besides outbound message transfer, you might want to distribute the inbound message traffic to Exchange 2000 across multiple gateway connector instances. This requires you to split your Exchange 2000 organization into multiple proxy post offices to route messages to these virtual repositories individually. By default, the Exchange 2000 organization acts as one huge proxy system that usually can receive messages from a particular foreign messaging network only through one connector. In Figure 7.6, the entire Exchange 2000 organization appears as the proxy cc:Mail post office FirstAdministrativeGroup. To split your organization, assign your Exchange users CCMAIL proxy addresses that appear to be from different proxy post offices (for example, User at Seattle and User at WashingtonDC). To automate this process, configure appropriate recipient policies. In the Exchange System Manager snap-in, right-click Recipient Policies, point to New, and select Recipient Policy. Under Name, type Users in Seattle (or Users in WashingtonDC ), and then click Modify. In the Find Exchange Recipients dialog box, click the Advanced tab, click Field, point to User, and, from the list of attributes, select City (or any other attribute that contains useful information and suits you). From the Condition list box, select Is (Exactly). Under Value, type Seattle (or WashingtonDC ), and then click Add. It is a good idea to verify the results of your filter by clicking Find Now. If everything is fine, click OK, and then, in the Exchange System Manager dialog box informing you that existing recipient addresses don’t change when a filter changes, click OK. Next, click the E-Mail Addresses tab, select the CCMAIL check box, and then adjust the proxy address to indicate that the users are on the Seattle (or WashingtonDC) proxy post office. Click OK and update the existing addresses by clicking Yes in the subsequent Exchange System Manager dialog box.
Figure 7.6 - Multiple message paths to the same Exchange 2000 organization
Note
Your recipient policies have a higher priority than the default policy object. If you create additional policies, those can be arranged in the contents pane of the Exchange System Manager snap-in by right-clicking them and selecting Move Up or Move Down. The order in the list determines the policy’s priority.
Exchange 2000 Server as a Messaging Switch
Exchange 2000 Server allows you to implement multiple connector instances of the same or different types to connect the organization to the same or different foreign systems concurrently. This can lead to a situation in which Exchange 2000 Server assumes the role of a central messaging switch (see Figure 7.7).
Figure 7.7 - An Exchange 2000 organization as a messaging switch
The configuration of Figure 7.7 is promising. It appears as if MS Mail, Lotus cc:Mail, and Lotus Domino/Notes users can send messages to each other via the Exchange organization as well as to the Internet. In reality, however, the users are not able to communicate over the Exchange 2000 backbone as long as the directories are not synchronized. For example, an MS Mail user on NET1/PO1 can send a message to both an Exchange 2000 user and an MS Mail user on NET2/PO2. The message arrives at the Exchange 2000 server in Seattle, but to deliverthe message, the MS Mail connector must convert the recipient information into Exchange format. This requires a directory lookup, but if Active Directory does not have the recipient information available, the process fails and a nondelivery report (NDR) is returned to the originator. To complete the example, for the Exchange 2000 recipient, the MS Mail connector is able to replace the MS Mail address information, and the message is delivered because the user’s mailbox-enabled account is in Active Directory. The MS Mail proxy address clearly identifies the user. Without directory synchronization, however, address information is unavailable for the MS Mail user on NET2/PO2. Correspondingly, the address conversion fails and the message is not delivered to this user. The originator receives an NDR stating that the recipient is unknown.
You must make sure all recipients are in Active Directory for message switching to work. In other words, you must configure directory synchronization between Active Directory and all foreign messaging systems that you plan to switch together via Exchange 2000 Server. In Active Directory, foreign recipients appear as mail-enabled user accounts or contacts with an underlying e-mail address of the foreign type (such as MS, CCMAIL, GWISE, or NOTES). In the foreign messaging systems, external recipients appear as if they are in the Exchange 2000 organization.
Relaying to the Internet
Because Exchange 2000 Server can only forward messages to recipients for whom a contact object is available in Active Directory, it is not easy to provide Internet connectivity to users in foreign environments via the Exchange 2000 organization. Keep in mind that Internet users will be able to send messages to all internal users because they have recipient objects in Active Directory with a corresponding Simple Mail Transfer Protocol (SMTP) address. However, the same is not necessarily true the other way around. It is usually not feasible to create a contact for each and every possible Internet recipient in your directory.
For this reason, you may have to continue using SMTP gateways in the foreign environments. Exchange 2000 Server is able to relay SMTP messages between foreign systems. Applied to Figure 7.7, this means that you need to specify the server in Seattle as the SMTP relay host. You can configure message relaying for the SMTP connector that connects the Exchange 2000 organization to the Internet. The resulting configuration is shown in Figure 7.8. It is important to note that the outgoing Internet messages do not reach the Exchange 2000 organization to avoid the problem of missing recipient information. The SMTP connector relays the messages unconverted to their final destinations based on SMTP domain information.
Figure 7.8 - SMTP relaying through an Exchange 2000 Server
Note
The MS Mail connector is an exception to the rule and is able to handle messages sent from MS Mail users to SMTP gateway addresses. Therefore, you can deliver SMTP messages through an existing MS Mail Gateway to SMTP or reconfigure all gateway access components on the MS Mail postoffices to redirect SMTP messages to the shadow postoffice of the MS Mail connector. The shadow postoffice will behave as if it was running the gateway component of the Gateway to SMTP, while the messages are transferred through Exchange 2000 Server.
Performing Directory Synchronization
The preceding explanations make clear that directory synchronization is vital. Be careful when configuring directory synchronization in a complex heterogeneous environment, however. You always need to avoid synchronizing the same recipients multiple times. You can implement multiple connectors for message transfer, but only one connector should perform the directory synchronization.
The foreign messaging system can also perform directory synchronization with other platforms. For instance, in Figure 7.7, the Lotus cc:Mail post offices might already be synchronized with the Lotus Domino server, in which case you need to exclude the external references, or you will end up with duplicate references in all synchronized address books. This might require you to restructure the directory synchronization topology in the existing environment prior to including Exchange 2000 Server. For a discussion about directory synchronization methods, see Chapter 4, "Assessing the Current Messaging Infrastructure."
Directory synchronization with foreign messaging systems relies on organizational units (OUs) in Active Directory. You can specify different OUs by each connector that performs directory synchronization, and you can specify different OUs for importing and exporting recipient objects. A sophisticated OU structure allows you to propagate address information selectively to the foreign systems.
Note
All Exchange 2000 gateway connectors support automatic directory synchronization. You can adjust the connector configuration to synchronize specific custom directory attributes. You can read more about individual configuration settings for directory synchronization in MCSE Training Kit—Microsoft Exchange 2000 Server Implementation and Administration.
Integrating Schedule Information
Many popular messaging systems support scheduling features to facilitate the planning of meetings and handling of shared resources, such as conference rooms. Exchange 2000 users, for instance, can examine each other’s free and busy times when creating meeting requests (see Figure 7.9).
Figure 7.9 - Planning a meeting in Outlook 2000 with Exchange 2000
The free and busy times, however, do not reside in the users’ calendars. Instead, free/busy times are maintained in a hidden system folder called Schedule+ Free Busy. For each administrative group, a subfolder exists that holds the information for all local users. Outlook 2000 automatically synchronizes this repository with the information from the users’ calendars in the background. You can replicate the Schedule+ Free Busy folders across the entire organization to provide complete information to all your users. Public folder access strategies are discussed in Chapter 5, "Designing a Basic Messaging Infrastructure with Microsoft Exchange 2000 Server."
You can also have the ability to provide access to free/busy information across messaging platforms, which can facilitate the booking of meetings with foreign users. For example, to synchronize free/busy information with Schedule+ in an MS Mail environment, install the Schedule+ Free/Busy Connector. You must enable directory synchronization to fully support calendar interoperability. Recipient objects must exist in the server-based address book to allow users to perform free/busy queries.
Unfortunately, Exchange 2000 Server does not provide calendar connectivity to any other messaging systems (a calendar connector is planned to ship with Service Pack 1). For now, you can install the Microsoft Exchange 5.5 Calendar Connector on a computer that runs Exchange Server 5.5 Service Pack 4. This requires your organization to operate in mixed mode. You can find more information about interoperability with previous versions of Exchange Server in Chapter 6, "Designing an Upgrade Plan to Microsoft Exchange 2000 Server."
Note
Meeting requests are transferred as regular e-mail messages. Most gateway connectors support this message type and properly map the information between different message formats.
You can use the following components to provide calendar connectivity:
- Schedule+ Free/Busy Connector An Exchange 2000 component that uses the MS Mail distribution protocol to exchange free/busy information between Exchange users and Schedule+ users in an MS Mail network based on e-mail messages.
- Calendar Connector (Exchange Server 5.5) Supports queries for free/busy information between Exchange Server and Novell GroupWise, Lotus Notes, and IBM OfficeVision/VM. The Calendar Connector requires APPC/VM on the mainframe (for OfficeVision/VM), Lotus Notes client R 4.6.2 (for Lotus Domino servers), or the NLM version of the Novell GroupWise API Gateway (for Novell GroupWise 4.x and 5.x ).
Note
For the Calendar Connector to work, install the PROFS, Lotus Notes, or GroupWise connector directly on the bridgehead running Exchange Server 5.5. You might be able to use Exchange 2000 gateway connectors, but this requires manually configuring proxy addresses and Registry settings for the Calendar Connector. Running the Calendar Connector with legacy gateway connectors on the same server is the most reliable system configuration.
More Info: Configure the Calendar Connector to Use the Exchange 2000 GroupWise Connector
The Calendar Connector requires a Connector to Novell GroupWise to support free/busy lookups between Exchange and GroupWise. Specifically, this component depends on the GroupWise Connector’s router service to communicate with the GroupWise API Gateway. It is possible, although not recommended, to use the Exchange 2000 GroupWise connector for this purpose.
To support the Calendar Connector, you must install the Novell GroupWise E-Mail Address Generator on the Exchange Server 5.5 computer to support the generation of GWISE proxy addresses for system components, such as the System Attendant service of the connector server. You can install the address generator separately from the GroupWise Connector using the GroupWise Connector Setup program.
To use the Exchange Server 5.5 Calendar Connector with an Exchange 2000 GroupWise Connector, perform the following steps:
- If you have fully installed the GroupWise Connector on the Exchange Server 5.5 computer, disable the connector but leave the address generator installed on the server.
- Share the \Program Files\Exchsrvr\Conndata\Gwrouter directory on the Exchange 2000 server that is running the GroupWise Connector. A share name of GWROUTER is appropriate.
- Edit the Registry on the Exchange Server 5.5 computer running the Calendar Connector to add two values to the following Registry key:
- Restart the Exchange 5.5 Calendar Connector and the Exchange 2000 GroupWise Connector and verify that the GroupWise Connector is disabled on the Exchange Server 5.5 computer. Test the lookup of free/busy information.
HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \MSExchangeCalCon \Parameters
Add a REG_SZ value called GWISECAL.001.API_IN DIRECTORY and specify the Togwise directory from the GWROUTER network share in Universal Naming Convention (UNC), such as \\<Exchange 2000 Server>\ GWROUTER\Togwise. Add a second REG_SZ value and name it GWISECAL.001.API_OUT DIRECTORY. Specify the Freebusy directory from the GWROUTER network share in UNC, such as \\<Exchange 2000 Server>\GWROUTER\Freebusy.
Keep in mind that you edit the Registry at your own risk. Incorrect Registry settings can cause serious problems and might force you to reinstall the operating system.
Developing a Multiphase Migration Strategy
As soon as your project team has integrated Exchange 2000 Server with the foreign systems, you are ready to migrate users to the new messaging platform. To do so, you must develop appropriate migration strategies. If possible, use the Migration Wizard to move users and their data. The features and advantages of the Migration Wizard were discussed in Lesson 1.
Table 7.4 summarizes the questions that your multiphase migration strategy must address.
Table 7.4 Important Questions for Multiphase Migration Strategies
| Question | Comments |
|---|---|
| Which users do you plan to migrate in each phase of the project? | It is advantageous to move all users from a post office at once or all users who communicate with each other frequently. Migrating entire post offices enables you to retain old e-mail addresses, which allows you to route messages addressed to old recipients to the new mail-boxes. Furthermore, migrating all users who communicate frequently with each other helps minimize the work-load on the gateway connectors. If you migrate all users to the same server, no unnecessary network traffic is generated when they send each other messages, for example. |
| How do you want to handle old mailboxes if you cannot migrate entire post offices at once? | Migrating users and data to Exchange 2000 Server is a copy process. The old mailboxes remain on the foreign system. You need to delete these mailboxes manually. This implies that messages sent to the old mailboxes will no longer be deliverable and will be returned to the originators with an NDR. The originators must use the new addresses to communicate with migrated users (see Figure 7.10). You can deal with partially migrated post offices in the following ways:
|
| Do you need to support communication with external users? | If your users are communicating with external users (such as users on the Internet), you might want to preserve the existing external e-mail addresses of your users, such as the SMTP addresses. You must configure appropriate recipient policies and change the routing to deliver messages from external sources to the new mailboxes on Exchange 2000 Server. |
| How can you keep the directories in all systems updated when users are migrating? What is your backup plan if something goes wrong? | You need to clarify the directory synchronization procedures to establish global address information across all systems. After each migration cycle, perform a directory synchronization to update the server-based address lists. Your project team needs a clear understanding of how to handle problems that might occur during the multiphase migration. Keep the following issues in mind when developing the backup plan:
You can read more about disaster recovery planning in Chapter 11, "Designing a Disaster Recovery Plan for Microsoft Exchange 2000 Server." |
Note
If you migrate all users at once, you can decommission the entire old system, reconfigure the message routing, and route all messages to the new mailboxes. Migrate entire post offices if possible.
Preserving Message Paths
Perhaps the greatest migration challenge is to ensure that replies to existing messages work. This is usually not a problem for migrated users. If you keep the display names in the old and new environment the same, replies to migrated messages will cause no problems, as outlined in Lesson 1. However, you also need to take the users that are left behind into consideration.
Replies to Existing Messages
Users in the old messaging environment, as well as external users, might want to reply to existing messages and expect those messages to arrive with the intended users. The problem is that those replies usually contain outdated address information even though correct information is available in the GAL because the addresses are simply copied from the old message instead of being obtained from an address book.
For example, assume that a user at ccPO2 replies to a message from Ms. X at ccPO1. Assume further that you migrated Ms. X to Exchange 2000, but you had to retain the post office (partial migration). In this situation you are unable to change the cc:Mail routing and the reply will arrive at ccPO1. If Ms. X’s mailbox was removed from this post office, an NDR is generated. Fortunately, cc:Mail allows you to redirect the message at this point to the new mailbox of Ms. X in the Exchange 2000 organization, as mentioned earlier in this lesson. The new address is Ms. X at Seattle.
Unfortunately, not all messaging systems support message forwarding, including MS Mail. To always ensure that messages sent to the old addresses arrive, you must migrate entire post offices. You can decommission the old post office and change the message routing to deliver the messages straight to the new mailboxes. Applied to the current example, this means that e-mail sent to Ms. X at ccPO1 is routed to the Exchange 2000 server in Seattle. You can preserve the old address information in an additional proxy address (Ms. X can have two cc:Mail addresses: Ms. X at Seattle and Ms. X at ccPO1) and the message will be delivered to the recipient’s new mailbox. Figure 7.10 illustrates both approaches.
Note
The Migration Wizard preserves the old address information automatically for you. If you do not want to use the Migration Wizard, configure an appropriate recipient policy or assign correct proxy address information to migrated users manually.
Messages from the Internet
You should also strive to preserve existing external e-mail addresses. For instance, Ms. X might have an SMTP address of X@ccOld-inc-10.com. The migrated user will receive new address information through recipient policies, such as X@E2K-inc-10.com, but Internet users, who still might send messages to X@ccOld-inc-10.com, will expect to reach Ms. X. Consequently, you need to accomplish two things: You need to assign Ms. X an additional SMTP proxy address for X@ccOld-inc-10.com and change the SMTP message routing to deliver all messages sent to ccOld-inc-10.com to the Exchange 2000 organization. This will affect all messages sent to ccOld-inc-10.com, but users on ccPO2 will receive Internet messages via the Lotus cc:Mail connector—as long as youcan guarantee that their address information is in Active Directory, as explained earlier in this lesson.
Figure 7.10 - Migrating complete post offices to Exchange 2000 Server
Messages Sent to Distribution Lists
Distribution lists represent a problem in multiphase migrations. If possible, deactivate them before the migration commences. As soon as all users are on Exchange 2000 Server, you can reconfigure them in Active Directory. Note, however, that this straightforward approach is seldom feasible.
The problem with distribution lists is that they can contain recipients from several messaging systems, but when you migrate users to Exchange 2000 Server, old distribution lists might not be updated and can contain invalid or incomplete address information. Figure 7.11 illustrates how distribution lists are handled in heterogeneous environments.
Directory synchronization does not include distribution list memberships. Foreign distribution lists are represented as mail-enabled contact objects in Active Directory. Exchange 2000 distribution groups, on the other hand, end up as regular external users in the foreign directory (Figure 7.11). Consequently, a message sent to a distribution list (or group) must first be delivered to the system where the membership information is available. This system must then expand the list and deliver the message to each individual recipient. This leads to situations where messages cross the gateway connector twice.
Figure 7.11 - Distribution lists with recipients from multiple messaging systems
You have two options to migrate distribution lists to Exchange 2000 Server:
- Migrate distribution lists before users You can configure new distribution groups in Active Directory and add the required contact objects to these groups. After that, delete the original distribution lists from the foreign system to avoid duplicated groups in the GALs. Perform directory synchronization to propagate the new distribution group addresses to all messaging systems. Messages addressed to these distribution groups are first delivered to Exchange 2000 Server for group expansion. The message transfer is inefficient at the beginning of the migration when most users still reside on the old systems, but it improves automatically as more users are migrated.
- Migrate distribution lists after users You can continue to use the existing distribution lists in the foreign system. You only need to update the distribution lists’ membership information after each migration cycle to include the new Exchange recipients. Messages addressed to these distribution lists are first delivered to the foreign system for group expansion. The message transfer is efficient at the beginning of the migration when most users still reside on the old systems, but it degrades as more users are migrated.
Note
If possible, migrate distribution lists before you migrate the users because the Migration Wizard is able to update the distribution list membership automatically for you. The Migration Wizard can replace mail-enabled contacts with mailbox-enabled user accounts if you specify the contacts’ OU as the target container for the new user accounts.
Table 7.5 summarizes the advantages and disadvantages of both approaches.
Table 7.5 Advantages and Disadvantages of Distribution Lists
| Distribution Lists | Advantages | Disadvantages |
|---|---|---|
| Distribution groups in the Exchange 2000 organization | | |
| Distribution lists in the legacy environment | | |
Public Folders vs. Distribution Groups
Microsoft documentation sometimes recommends migrating distribution lists to public folders and configuring public folder rules to forward incoming messages to all recipients that were originally members of the distribution lists. If possible, do not follow this approach because it combines the disadvantages of all other migration strategies with each other without delivering tangible benefits.
Among other things, public folders have the following disadvantages when used as distribution lists:
- All messages addressed to the public folder distribution list must first reach the folder’s home server before the folder rule can be triggered to forward the message to the actual recipients. This may represent a highly inefficient message routing.
- It is not possible to use public folder distribution lists to specify permissions to other resources, such as other public folders.
- Only one server can perform the distribution list expansion (that is, the forwarding of messages to the actual recipients). If this server is unavailable, no messages are delivered.
- Public folder rules that apply to a large number of mailboxes are difficult to maintain and can negatively affect server performance.
- The complete list of public folders that forward messages to an individual mailbox is difficult to determine. It is impossible, for instance, to display a list of forwarding public folders in the recipient’s Member Of tab (where all the distribution groups are listed).
- All users require write access to the public folder distribution list repository. Users might use the public folder to post large documents, which would then be forwarded to all specified recipients automatically. It is very difficult to specify message size limits for individual folder items, but it is very easy to specify message size limits for distribution groups.
- Whenever you migrate users, you must reconfigure the public folder rules manually. The Migration Wizard cannot accomplish this task for you.
Note
If you need to implement message archives for your distribution lists, mail-enable the desired public folders, then add them as members to the appropriate distribution groups. However, do not use them to replace the distribution groups.
Developing a Multiphase Migration Strategy for Consolidated Messenger
Consolidated Messenger, an Oregon-based broadcasting company introduced in Chapter 1, is facing a complex migration from MS Mail and Lotus Notes. "We have wanted to replace our entire MS Mail environment, including all five postoffices and 1500 users, for a very long time," says Gregory J. Erickson, Senior IT Administrator at Consolidated Messenger. "I’m very excited that we are finally ready for a migration to Exchange 2000 Server. Of course, we must not forget the political interest of our Video department, formerly known as Southridge Video, which is now running a small Lotus Notes environment. We will migrate from Lotus Notes in a separate cycle to emphasize the Video department’s independence."
Erickson devised the following migration strategy for Consolidated Messenger:
- Currently, we operate an MS Mail environment with 1500 users on five postoffices. Because a single-phase migration is impossible, we will integrate Exchange 2000 Server with our environment based on the MS Mail connector. Exchange 2000 Server will participate in our directory synchronization. We still have to determine the best way to integrate Exchange 2000 in our directory synchronization environment.
- We will use the Lotus Notes connector to integrate the Video department and configure the directory synchronization with Lotus Notes. We will synchronize all recipients with all directories to enable Exchange 2000, MS Mail, and Lotus Notes users to communicate with each other conveniently.
- Our users use Outlook 2000 or the Lotus Notes client for calendaring, but we will not synchronize free/busy information between the messaging systems to avoid the installation of Exchange Server 5.5. As soon as all users are on Exchange 2000 Server, free/busy information will be available for simplified booking of meetings.
- We will migrate entire postoffices at one time beginning with the largest MS Mail postoffice. In the last step, we will migrate the Lotus Notes environment.
- Before the migration of mailboxes commences, we will migrate all distribution lists to Active Directory. All distribution groups will be placed in the same domain as the mail-enabled user accounts and mailbox-enabled user accounts, and the administrator who performs the migration will be granted full access to all OUs to ensure that the Migration Wizard can update recipient objects and distribution group memberships automatically. After the migration, we will tighten administrative permissions to conform to the political requirements of our Video department.
Activity: Developing Multiphase Migration Strategies
In this activity, you will develop multiphase migration strategies for two companies that plan to migrate to Exchange 2000 Server. The companies are Coho Vineyard & Winery and Woodgrove Bank, which have been introduced in earlier chapters.
Tip
You can use Figure B.21 in Appendix B as a guideline to accomplish this activity.
Scenario: Coho Vineyard & Winery
Paul West, Information Technology Administrator at Coho Vineyard & Winery, is still undecided about whether Coho Vineyard & Winery should use the single-phase migration strategy to move its 250 users from Alt-N Technologies MDaemon PRO for Windows to Exchange 2000 Server.
"I’m a very careful messaging administrator," says West. "It’s just that I’d like to avoid risks, if possible. A migration in multiple phases seems less risky to me than a quick rush in a single step."
- What is Coho Vineyard & Winery facing if West decides to migrate in multiple steps (assume that Coho Vineyard & Winery’s users currently communicate with Internet users)?
- Comparing the advantages and disadvantages of single-phase and multiphase migrations, which approach would you recommend to West?
Scenario: Woodgrove Bank
Woodgrove Bank maintains a complex messaging infrastructure with numerous e-mail and groupware platforms. "Currently, we intend to migrate our Swiss MS Mail environment to Exchange 2000 Server." says Luis Bonifaz, Chief Information Officer. "We also need to integrate Exchange 2000 Server into our global messaging backbone." Woodgrove Bank’s messaging environment is shown in Figure 7.12.
Figure 7.12 - The Swiss MS Mail environment of Woodgrove Bank
Reviewing the Swiss messaging environment, it is your task to develop an appropriate multiphase migration strategy for Woodgrove Bank.
- Woodgrove Bank intends to replace the X.400 backbone with a global SMTP-based network. Correspondingly, the bank plans to use the MS Mail connector to connect Exchange 2000 Server directly to the MS Mail environment and an SMTP connector to connect to the messaging backbone. Woodgrove Bank wants to consolidate all 600 mailboxes on a single Exchange 2000 server in Zurich. Assuming that you want to connect the Exchange 2000 organization to only one MS Mail postoffice, which postoffice should you choose for the Connector to MS Mail?
- Assuming that you connected the Exchange 2000 server to both the MS Mail environment and the SMTP messaging backbone, how should you perform the directory synchronization?
- You need to ensure that replies to existing messages always work. How should you migrate the postoffices to Exchange 2000 Server?
- You want to migrate existing MS Mail distribution lists. Which strategy should you use to migrate the distribution lists most conveniently?
Lesson Summary
The multiphase migration allows you to move users in small groups to Exchange 2000 Server, which is advantageous if you have to migrate a large or very complex environment. You can control the pace of migration; coordinate it according to departments, business units, or teams; and optimally deliver end-user training. Another advantage is that you can minimize system downtime per migration cycle. The multiphase approach can be considered less risky than the single-phase migration.
Multiphase migrations require you to integrate Exchange 2000 Server with the legacy systems in such a way that all users can communicate with each other and access consistent global address information. Gateway connectors are available in Exchange 2000 Server. If you need to connect to a system not directly supported, you might be able to use a connector running on Exchange Server 5.5 or use indirect connectivity via SMTP or X.400. Seamless integration requires you to establish directory synchronization. Optionally, you might also want to provide calendar interoperability to facilitate the booking of meetings or shared resources.
To ensure messages are always deliverable in a changing environment, retain existing e-mail address information and route messages addressed to the old recipients to the new mailboxes. It is easy to change the message routing if you migrate entire post offices at once. It is not possible if you must partially migrate your mail systems. In this case, message-forwarding capabilities may allow you to redirect messages sent to the old mailboxes. Alternatively, you can force all users to use new address information. Exchange 2000 Server is very flexible and it allows you to specify multiple proxy addresses for each recipient. Among other things, this allows you to preserve existing external addresses, such as Internet e-mail address information. If you deliver all incoming Internet messages to the Exchange 2000 organization, migrated users will be able to receive messages sent to their older addresses.
Distribution lists are complicated to migrate. If possible, deactivate them prior to migration. If this is not possible, migrate them before any mailboxes. When you migrate the mailboxes at a later time, the Migration Wizard can update the distribution group membership automatically. This is not the case if you migrate distribution lists after the users, in which case you need to update the distribution lists manually in the foreign system after each migration cycle. In any case, avoid using public folders with forwarding rules as temporary distribution lists.
EAN: 2147483647
Pages: 89