You've decided to take the plunge and move your organization from Novell GroupWise to Exchange 2000 Server. You face challenges such as removing the GroupWise client, configuring the new messaging server product, and installing Outlook or another Messaging API (MAPI) email client. But after you get Exchange running, the most important tasks in the GroupWise-to-Exchange migration are moving mail and calendars
Before you begin any migration, you should explain to both users and administrators how their worlds will change. If you don't take the time to convey that Outlook has a different look and feel from the GroupWise client, you'll probably hear from dissatisfied users. Moving from the GroupWise client to the Outlook client can be a life-altering change for many users. However, colleagues who use the Outlook or Outlook Express client at home might welcome the change. Regardless, you must prepare your users.
An essential step in preparing an interoperability and migration project is to assess and document the existing messaging environment. You must know where the legacy post offices or servers are located and how many there are. It is important to identify potential gateway or bridgehead servers, which your connectors should use for message transfer and directory synchronization. If your migration affects a substantial number of users who communicate heavily with one another through e-mail, you must designate multiple messaging hosts to use as gateways to build parallel transfer paths and avoid bottlenecks.
You should include the following information in infrastructure documentation:
| • | Information about the servers that host mailboxes This includes server names and locations, the installed messaging systems, the number of mailboxes, the names of administrators, and any special configuration settings (such as post office passwords and database versions). You might also want to list the administrative tools that are used to manage the systems and their versions. | ||||||||||||||
| • | Information about the servers that host collaborative applications and public forums, such as discussion boards This includes server names, locations, and purposes, and the number of users who access the discussion forums and workgroup applications. It is also a good idea to include the names of the administrators and developers who are responsible for those public forums and workgroup applications. | ||||||||||||||
| • | The structure of the messaging backbone This includes the wide area network (WAN) and local area network (LAN) topology, central transfer routes and their communication protocols, the names and locations of bridgehead servers, connections to other messaging systems and the Internet, and so on. You might also want to list the names of the administrators who are in charge of the messaging backbone, because you will work with them during your migration to connect Exchange 2003 to the existing messaging infrastructure. | ||||||||||||||
| • | The existing directory
synchronization topology The directory synchronization
topology is a logical arrangement of server resources that
is not obvious in the messaging environment. For this
reason, it is important to document the directory
synchronization topology carefully to obtain a clear
understanding of synchronization options that are available.
Your documentation should include answers to the following
questions:
|
||||||||||||||
| • | Detailed information about backup and restore procedures This includes details about the backup schedule and backup validation policies for the individual messaging resources. You should also include information about the storage location of backup media and product CDs. You will use this information to restore production systems in a computer lab to perform test migrations using real-world data. | ||||||||||||||
| • | Information about the client
environment This includes the types of messaging
clients that are currently in use and their versions, the
methods that they use to access mailboxes and public folders
(remote or local), and the messaging habits of your users.
Document where your users store their messaging data,
because migration procedures differ if users store messages
on client computers instead of in server-based mailboxes. It
is important to document current storage requirements and
the number of messages that are generated by the users in
each location on a typical business day.
Your documentation should provide answers to the following questions:
|
It is a good idea to include network diagrams and a graphical representation of your messaging infrastructure in your documentation. Depending on the size of your company, a large diagram showing all of the components might be sufficient, or you can prepare several smaller diagrams that focus on more specific characteristics, such as the global backbone and the arrangement of post offices or messaging hosts in each geographical location.
Figure 1.1 shows a sample diagram of a messaging environment (here Microsoft Mail for PC Networks) with two locations and one connection to the Internet. In this example, messages between locations are routed through a central message transfer agent (MTA). Within each location, another MTA performs message delivery. All messages to and from the Internet are routed through SEAPO2, which has a Simple Mail Transfer Protocol (SMTP) gateway that connects the entire messaging environment to the Internet.
Figure 1.1 Sample messaging infrastructure
Figure 1.2 shows a sample directory synchronization topology that corresponds to the messaging infrastructure illustrated in Figure 1.1. The example is a Microsoft Mail for PC Networks directory synchronization configuration in which NYPO1 acts as a central directory synchronization server. Your configuration will differ if you are using Lotus Notes/Domino, Novell GroupWise, or any other messaging system, but the principle remains the same: a graphical representation provides system consultants and implementers with a quick overview of your topology.
Figure 1.2 Sample directory synchronization topology
A main objective when you assess a messaging infrastructure is to identify connectivity, directory synchronization, and client migration opportunities. For example, in the messaging environment shown in Figure 1.1, SEAPO2 and NYPO1 are good choices for post offices that connect to Exchange 2003 directly, because they are the hub post offices in Seattle and New York. If this company chooses to deploy one Exchange 2003 server in each location, it is a good idea to install a separate connector to SEAPO2 and to NYPO1, respectively. In a subsequent step, the new Exchange 2003 organization can be integrated into the existing directory synchronization topology so that all users can see each other in the global address list. Directory synchronization also ensures that all address lists are updated when groups of users are moved to Exchange 2003 in their locations. Eventually, when all users are in the Exchange 2003 organization, you can retire the legacy messaging infrastructure. There is more information about migration strategies and procedures later in this chapter.
Your messaging assessment should provide answers to the following important questions:
| • | Are there any known problems in the
current infrastructure that might adversely affect the
migration project? There are three potential problems
that can occur with your migration: overtaxing of existing
connections, transmission problems due to inadequate
software components, and inefficient or incorrect message
routing. For example, bottlenecks or malfunctioning
connectors are indicated when messages accumulate in message
queues somewhere on a bridgehead. Non-delivery reports (NDRs)
are signs of incorrect message routing. Message loops,
another common problem, are created if messages are routed
multiple times through the same bridgehead.
Exchange 2003 adds trace information to all transferred messages to detect message loops and drop looping messages with a non-delivery report (NDR). However, if multiple messaging systems are included in the message path, the trace information might be lost during message conversion between the systems. In such a case, it is possible for messages to loop indefinitely. The effect can be similar to that of an e-mail flood caused by a worm virus. Therefore, you should review your existing messaging topology carefully to ensure that the implementation of Exchange 2003 does not lead to message loops. |
||||||||||||||||
| • | Are you planning to consolidate messaging resources when you deploy Exchange Server 2003? Exchange 2003 can support a very large number of mailboxes on a single server, and deployment of fewer but more powerful servers can help to simplify the messaging infrastructure. Identifying which systems you plan to consolidate helps you to determine the number of Exchange servers that you must deploy. | ||||||||||||||||
| • | Which connectors do you intend to
use to connect Exchange Server 2003 to an existing messaging
system? Connectors for Lotus Notes and Novell
GroupWise are included in the Exchange Server 2003 product
package. With the help of Microsoft Exchange 2000 Server or
Microsoft Exchange Server 5.5, it is even possible to
connect to Microsoft Mail for PC Networks, Lotus cc:Mail,
Professional Office System (PROFS) and Systems Network
Architecture Distribution Services (SNADS) with a direct
connector. If you do not want to deploy Exchange 2000 or
Exchange 5.5, or if you are running another messaging
system, use X.400 or SMTP to build the e-mail bridge, or
check with your vendor to determine if there is an
appropriate third-party connector available. Table 1.1 lists
the most common messaging systems and corresponding possible
connector choices.
|
||||||||||||||||
| • | Is it necessary to install
additional components in the production environment to
provide connectivity? This is an important question,
because Connector for Lotus Notes and Connector for Novell
GroupWise require third-party components, as listed in Table
1.2. Alternatively, if you plan to use an X.400 or SMTP
connector, it might be necessary to install a corresponding
X.400 or SMTP gateway in the legacy messaging environment.
|
||||||||||||||||
| • | Is it possible to implement an appropriate gateway connector that supports directory synchronization? All Exchange connectors to non-Exchange messaging systems support automatic directory synchronization. For example, you can use Connector for Lotus Notes to synchronize Active Directory (which is the directory of Exchange 2003) and Domino directories. The same principle applies to Connector for Novell GroupWise. If you are using Exchange 2000 on a bridgehead server, you can also use Exchange Connector for Microsoft Mail for PC Networks and Connector for Lotus cc:Mail to perform automatic directory synchronization with Microsoft Mail for PC Networks or Lotus cc:Mail. | ||||||||||||||||
| • | If automatic directory synchronization is not supported, is it possible to develop a semi-automated directory synchronization process? Semi-automated directory synchronization is required if you must use an X.400 or SMTP connector or a non-Microsoft gateway product that does not support automatic directory synchronization. Exchange 2003 directory synchronization is performed against Active Directory, which means that you can use low-level Active Directory tools, such as Ldifde.exe and Csvde.exe, to perform semi-automated directory synchronization or bulk export and import operations. Ldifde.exe works with LDAP Data Interchange Format (LDIF) files. Csvde.exe uses comma-separated value (.csv) files. Another alternative is Active Directory Service Interfaces (ADSI) and Collaboration Data Objects for Exchange Management (CDOEXM), which a business solutions developer can use to create a custom directory synchronization tool. | ||||||||||||||||
| • | What are the average and maximum mailbox sizes in the existing messaging system? Look at the current size of your users' mailboxes. This information is very important when designing the storage capacity of your Exchange servers. At a minimum, the new environment should allow all users to store the same amount of data, or more, in their mailboxes. It is not a good idea to enforce more restrictive mailbox quotas on the new system, because this might prevent users from experiencing the new Exchange 2003 organization as a positive change. | ||||||||||||||||
| • | What are your users' messaging habits? Your users' messaging habits influence your migration options. For example, if your users download all of their messages from the server to their clients, you cannot migrate their data centrally using migration tools. Users who store their messages locally usually must perform the data migration themselves. Users who encrypt their messages can also affect your migration. Migrating encrypted messages from one system to another requires that each message be decrypted in the source system before migration, because the messages must be converted from native format into Exchange format. Only the correct user can perform the decryption, so you cannot migrate encrypted messages on behalf of your users. Also, if it is not feasible to store sensitive information in non-encrypted form in Exchange 2003, you should not migrate encrypted items. | ||||||||||||||||
| • | Are the current workstations capable
of running the chosen messaging client or clients for
Exchange 2003? Usually, the chosen messaging client is
Outlook. Outlook requires, at a minimum, a 233 megahertz
(MHz) or faster Intel Pentium processor or equivalent
(Pentium III or higher recommended), and between 160 and 190
megabytes (MB) of disk space on a computer running Microsoft
Windows® XP.
If your workstations cannot support Outlook, because, for example, they run a UNIX operating system, you must find an alternative client solution, such as an Internet client like Outlook Web Access, or use a Windows Terminal Services client, which is a viable option if you want to bring full Outlook functionality to every desktop in your environment. UNIX operating systems often include client software for Windows Terminal Services. |
||||||||||||||||
| • | Is it possible to deploy Outlook in
the legacy messaging environment? Messaging migrations
are relatively straightforward if your users already work
with Outlook. Non-Microsoft vendors, such as IBM Lotus and
Novell, provide MAPI transport drivers that support Outlook
to some extent (Table 1.3). There might be additional costs
for such MAPI drivers. Users on UNIX-based Post Office
Protocol version 3 (POP3) or Internet Message Access
Protocol Version 4rev1 (IMAP4) hosts have the option to use
Outlook through POP3 or IMAP4 MAPI transport services, which
are included in Outlook.
|
||||||||||||||||
| • | Do users require training on Outlook before migration, or is it possible to continue using existing messaging clients and handle end-user training and client deployment after migrating to Exchange 2003? Users who are familiar with Outlook, such as those who already use Outlook for Internet messaging, will find a migration to Exchange 2003 very straightforward. However, novice users might face a steep learning curve, because Outlook offers a comprehensive set of messaging features. You can alleviate this situation by providing appropriate user training. You also have the option to support non-Outlook messaging clients in your Exchange 2003 organization. This is especially true for Internet clients such as Eudora Pro, because Exchange 2003 supports POP3 and IMAP4. Remember, however, that Internet clients are usually not as powerful as Outlook, and this might become a productivity issue for your users. | ||||||||||||||||
| • | Is the user help desk prepared for increased workload related to Exchange 2003 and Outlook? The interoperability and migration phase puts pressure on help desk personnel, because the support call volume increases when users start using their new messaging clients. It is recommended that you dedicate a help desk specialist specifically to Outlook-related questions and that you train this person thoroughly. To maintain productivity in larger organizations, the Outlook task force may consist of a number of experts. You might want to increase the headcount in the help desk department temporarily. It is reasonable to assume that the call level will return to normal within six months after migration is complete. | ||||||||||||||||
| • | How do you plan to keep management, IT administrators, user help desk personnel, and users updated about migration progress? It is important to keep the people in your organization fully informed about the migration progress. Your users must know when they are scheduled for Outlook training, for example, and IT administrators, user help desk personnel, and management need current information about project progress. It is recommended that you create a detailed communication plan. Many organizations implement a dedicated intranet site to facilitate communication about the migration. | ||||||||||||||||
| • | What are the options for migrating
existing workgroup and workflow applications to Exchange
Server 2003? Migrating workgroup applications can be
difficult. Workflow solutions often rely on features that
are not directly supported in Exchange 2003, such as
LotusScript or external data sources. You will probably want
to engage a business solutions developer who is skilled at
manual application reengineering and workgroup programming
using Microsoft Visual Basic® and Exchange application
programming interfaces (APIs), such as Windows Management
Instrumentation (WMI), Collaboration Data Objects for
Exchange 2000 Server (CDOEX), or Microsoft ActiveX® Data
Objects (ADO). You should evaluate your existing workgroup
and workflow solutions to decide whether you want to migrate
them or not. Document the applications that you want to
migrate in detail to ensure that your developer is porting
them to Exchange 2003 accurately.
If you must migrate Lotus Notes applications, consider using Microsoft Exchange Application Analyzer for Lotus Notes and CASAHL Technology, Inc.'s ecKnowledge solution for connecting Lotus Notes and Domino applications and migrating application data. Also, read the technical article Migration and Coexistence of Lotus Notes Applications Using Microsoft Application Services for Lotus Notes (http://go.microsoft.com/fwlink/?LinkId=7467). |
||||||||||||||||
You can migrate a messaging environment to Exchange 2003 in a single phase or in multiple phases. A third option is long-term coexistence, although this is not a true migration strategy.
Note :
Organizations might choose long-term coexistence for a number of reasons. One such reason might be that it is impossible or too costly to migrate existing workgroup and workflow applications over a short period of time.
Your assessment of the existing messaging infrastructure should give you a clear understanding of your migration options. You can use the flowchart shown in Figure 1.3 as a guide when choosing an appropriate migration strategy for your company.
Figure 1.3 Developing a migration strategy
Single-phase migration is straightforward. The day before the migration, all users are on a non-Exchange messaging system. The next day, they are all on Exchange 2003, and the legacy system is decommissioned. Existing user data might or might not be migrated. Some organizations reduce migration costs by not transferring existing messages. When this occurs, users must save memos and other important information on their local computers. Most organizations, however, prefer to migrate existing data to avoid lost productivity.
The most significant advantages of a single-phase migration to Exchange 2003 are:
| • | All users are migrated at once, which yields quick results. |
| • | If you deploy Outlook on all desktops before migration and advise your users to store all messages on their client computers, it is not necessary to move server-based user data to Exchange 2003. After migration, it is necessary only to reconfigure Outlook profiles to connect to Exchange 2003, rather than connecting to the legacy messaging system. |
| • | There is no need for messaging connectivity between the legacy messaging system and Exchange 2003. You are not required to install or configure an Exchange 2003 connector. |
| • | Preserving existing e-mail addresses is straightforward, because the new Exchange 2003 messaging system replaces the legacy messaging system. |
| • | You can establish a new messaging infrastructure that perfectly mirrors the existing recipient information. |
The most significant disadvantages of a single-phase migration to Exchange 2003 are:
| • | The migration of large numbers of users or large amounts of data results in unacceptable downtime. |
| • | You must establish the entire Exchange organization before you migrate users. It is difficult to stage server and client deployments. |
| • | You cannot control the pace of the migration. You cannot migrate divisions or departments individually, for example. |
| • | You have limited flexibility. For example, it is not possible to leave a particular group of users on the legacy system for any reason. |
For a small company with one or two messaging servers, single-phase migration is an advantageous option for migrating to Exchange 2003. However, for larger companies with a more complicated messaging infrastructure, single-phase migration is rarely possible, because these companies typically cannot react quickly enough to issues that can arise in a single-phase migration. Your company might have multiple messaging servers, which might be located in different places. You might have several different messaging clients that connect to messaging systems from multiple locations. It might not be feasible for all of the mailboxes to be migrated to Exchange 2003 and for all of the clients to be reconfigured in one giant step. In these situations, the migration process takes an extended period of time and includes multiple phases.
One of the most important issues that you must address in multiphase migrations is interoperability between the messaging systems, because users on the legacy system must be able to exchange messages with users who have already migrated to Exchange 2003. Because users tend to exchange e-mail messages primarily with other users in the same workgroup or department, it is recommended that you migrate users according to workgroup or department. This can help to reduce the number of messages that a messaging connector must transfer from one messaging system to the other.
The most significant advantages of a multiphase migration to Exchange 2003 are:
| • | You can complete the migration in incremental and manageable steps. In a large company, you can migrate departments, business units, or teams at one time. It is recommended that you migrate users who require delegate access to each other's calendars and mailboxes in the same cycle. |
| • | You can continue to support complex workgroup applications on the legacy system until new versions are available for Exchange 2003. However, it is important to evaluate and test your legacy application's ability to support users with mailboxes in the Exchange 2003 organization. |
| • | You can migrate heterogeneous messaging environments to Exchange 2003 without consolidating the resources in the old environment before migration. |
| • | You can minimize risks. If one particular operation in the multiphase migration is not successful, a limited number of people are affected, and you can back out of the operation fairly quickly. If migration of a group of users fails for any reason, users can continue to work with their old mailboxes until you fix the problem. |
| • | You can minimize the system downtime for messaging users. If you choose to perform the migration during non-business hours, you might be able to nearly eliminate downtime for users. |
| • | You can synchronize the reconfiguration of the messaging client and end-user training with the migration of mailboxes. |
| • | You have control over the pace of the migration. You do not need to establish the entire Exchange organization before you migrate users. You can stage server and client deployments according to your migration phases. |
The most significant disadvantages of a multiphase migration to Exchange 2003 are:
| • | Compared to single-phase migrations, multiphase migrations are more time consuming and therefore more expensive. |
| • | The computer network experiences an increased amount of data traffic, which results from the need to communicate with users on the legacy messaging system, as well as from directory synchronization and calendar interoperability. |
| • | The legacy messaging system and the Exchange 2003 organization must interoperate as seamlessly as possible. You must deploy a messaging connector and configure directory synchronization between the systems. |
| • | You cannot establish a new messaging infrastructure that perfectly mirrors the existing recipient information. Preserving existing e-mail addresses is difficult, because message transfer processes use address information to distinguish the legacy system from the Exchange organization. Therefore, the Exchange organization cannot reuse the address information that already exists in the legacy environment. |
| • | You must maintain both the legacy messaging system and Exchange 2003 for a period of time. |
Long-term coexistence is essentially a multiphase migration without an end point. After you migrate users to Exchange 2003, you do not decommission the legacy messaging system. Some companies might want to choose this strategy to preserve investments in existing technologies, such as complex business applications that rely on the legacy messaging system. With long-term coexistence, users must work with multiple clients, for example, Outlook to participate in the Exchange 2003 organization and another client (such as Lotus Notes or a Web-based interface) to work with the legacy business application (such as a Lotus Notes solution). Coexistence is costly, support-intensive, and requires administrator knowledge of multiple messaging systems. For this reason, many companies consider standardizing their communication infrastructure on a single messaging system to be a key element in their messaging strategy.
Long-term coexistence and interoperability are also required in distributed environments with autonomous sites that use diverse messaging systems that are connected with each other over a corporate messaging backbone or central message switch. If this describes your situation, consult your infrastructure documentation, and collaborate with administrators in charge of the messaging backbone to determine appropriate technologies to connect the new Exchange 2003 organization to the existing infrastructure. Most backbones support X.400 or SMTP, and message switches might even support native Exchange communication protocols.
Single-phase migrations include several key steps:
| • | Selecting the right migration tools |
| • | Testing migration procedures in a computer lab and then deploying Exchange 2003 |
| • | Creating recipient objects in Active Directory |
| • | Deploying Outlook and providing user training |
| • | Migrating user data |
| • | Decommissioning the legacy system |
The order of these steps depends on your specific situation. For example, you might want to deploy Outlook early if your legacy messaging system supports MAPI, as explained earlier. Deploying Outlook before migration allows users to download existing messages, appointments, and tasks to .pst files on their workstations and retain this data in the new Exchange 2003 organization. In this case, it is not necessary to migrate server-based data using the Exchange Migration Wizard or other tools. You must only replace the existing messaging system and reconfigure your users' Outlook profiles for Exchange 2003.
Remember that the success of a single-phase migration depends to a large degree on your preparations. You must test the individual migration steps in a computer lab and address any critical issues in your procedures before you work in the production environment. In addition, users must familiarize themselves with Outlook before migration. This can be accomplished through training and hands-on experience, either in the legacy messaging environment, if Outlook is supported, or in the new Exchange 2003 organization, if you cannot deploy Outlook beforehand. In the latter case, wait for an appropriate period of time after deploying Exchange 2003 and Outlook—usually a few weeks or a month—before migrating mailboxes to give your users a chance to use the new messaging client.
Important :
In a single-phase migration, adhere to step-by-step instructions that you have verified in a computer lab.
Use the flowchart shown in Figure 1.4 as a guide to determine an appropriate sequence of migration steps.
Figure 1.4 Generic single-phase migration approach
The procedures for moving mailboxes and data to Exchange 2003 depend to a large extent on the features of the migration tools that you select. A recommended tool is the Exchange Migration Wizard, included in the Exchange 2003 product package. A variety of tools are also available from non-Microsoft vendors.
Primary migration tools are:
| • | Exchange Migration Wizard This wizard automates the migration of mailboxes and server-based data to Exchange 2003. The Exchange Migration Wizard extracts and converts folders, messages, and address books, where applicable. | ||||||||||||||||||||||||||||||||||||
| • | Outlook 2003 Outlook can also be classified as a migration tool, because this client is able to import data from a wide range of sources, including Lotus cc:Mail archives, Lotus Organizer calendars, .pst files, databases, and so on. The Import/Export feature in Outlook might require additional software on the client computer, such as the program files of Lotus Organizer. | ||||||||||||||||||||||||||||||||||||
| • | Exchange application converters Application
converters can facilitate the migration of workgroup
applications. For example, simple discussion forms might be
converted quickly to Outlook forms applications.
Sophisticated applications, however, require complete
reengineering. Microsoft provides some Exchange application
converters and analyzers for Lotus Notes, but these tools do
not eliminate the need for an experienced business solutions
developer.
Microsoft offers the following application converters:
|
||||||||||||||||||||||||||||||||||||
| • | Importer for Lotus cc:Mail Archives You can use this tool to import Lotus cc:Mail archive files to folders in an Exchange 2003 mailbox store or to one or more .pst files. To download the Importer for Lotus cc:Mail Archives, go to http://go.microsoft.com/fwlink/?LinkId=25933. | ||||||||||||||||||||||||||||||||||||
| • | Non-Microsoft tools A variety
of non-Microsoft tools exist to facilitate migrations to
Exchange. Many of these tools rely on MAPI and communicate
with Exchange 2003 through an Outlook client. Microsoft does
not support these tools and does not warrant their
usefulness in any migration scenario. You must verify their
functionality and reliability in a test lab. Table 1.4 lists
examples of non-Microsoft migration tools for Exchange 2003.
|
||||||||||||||||||||||||||||||||||||
The Exchange Migration Wizard is a key migration tool. It is installed together with Exchange System Manager on your Exchange 2003 server. You can use the Exchange Migration Wizard to connect to the legacy mail system, extract the user data into temporary migration files, and then connect to the target Exchange 2003 server to place the data into the corresponding mailboxes. The wizard can even create the mailboxes automatically for you during this process. You can complete the entire process in one step, or in two steps if you want to modify the migration files.
Note :
As a tool dedicated to extracting and importing data, the Exchange Migration Wizard is not designed to analyze security settings. Consequently, the wizard does not preserve delegate permissions to other mailboxes, Inbox rules, or other special configuration settings that are applied to individual mailboxes. Your users must apply their specific Inbox rules, views, access permissions, and so on to their new mailboxes in the Exchange 2003 organization.
The Exchange Migration Wizard relies on two steps:
| • | Source extraction Source
extractors connect to source mail systems and extract the
data to save it in a set of migration files. The Exchange
Migration Wizard can use a variety of source extractors for
several messaging systems, including Microsoft Mail for PC
Networks, Lotus cc:Mail, Lotus Notes/Domino, Novell
GroupWise, and IMAP4 hosts, as well as Lightweight Directory
Access Protocol (LDAP)-conforming directories. You choose
the source extractor that you want on the Migration Wizard
page that appears when you click Next in the
Welcome page of the wizard.
Note : Some source extractors might require additional software to be fully functional, such as the Lotus cc:Mail Export.exe tool, a Lotus Notes client, or a Novell GroupWise client installed on the local computer. |
| • | Migration file import The
Exchange Migration Wizard uses its internal migration file
importer component to inject messages, calendar information,
and collaboration data into the selected Exchange store and
recipient information into Active Directory. Although there
are many different types of source extractors, there is only
one migration file importer.
Note : You must be an Exchange Full Administrator in the target administrative group and an account administrator in the target Active Directory domain or organizational unit to import mail data and directory information. |
Migration files are .csv files and can be opened in a text editor or using Microsoft Excel. You can also use Excel to edit the migration files before you import them with the Exchange Migration Wizard. In this way, you can change mailbox aliases or generate first name and last name fields based on display names. You can also add additional information, such as telephone numbers, department names, and so on. Furthermore, you can delete all messages sent before a certain date.
The Exchange Migration Wizard migration file importer requires the following three types of files to accomplish a migration:
| • | A packing list file This is used to identify the primary and secondary migration files. The Exchange Migration Wizard requires the packing list file to determine all primary and secondary files involved in the migration. |
| • | Primary files These include directory information as well as message headers and pointers to secondary files. There is one primary file, called directory.pri, containing the directory information for all users and their attributes (such as display name, alias, and e-mail addresses) There is also one primary file for each user that contains corresponding message header information (such as To, From, Cc, Subject, Date, and Time) and pointers to secondary files. Primary files for users are named in numbered sequence (for example, 00000001.pri, 00000002.pri, 00000003.pri, and so on). |
| • | Secondary files These contain
raw data, such as message bodies, attachments, and so on.
Note : Do not edit secondary migration files. Changes to secondary files invalidate all offsets and pointers in the corresponding primary file. Editing primary migration files can also lead to incorrect data. Save a copy of the original migration files, and test your changes carefully before applying them in the production environment. |
The Exchange Migration Wizard does not change or delete messages from the source mailboxes. The source mailboxes remain intact and continue to receive mail after you perform a migration. There is no option to delete old mailboxes automatically. You must reconfigure the message routing and decommission the legacy system.
Before you can copy existing messages, appointments, tasks, contacts, and other user-related data to Exchange 2003, you must create mailboxes that correspond to those available in the legacy messaging system. It is also useful to mirror other recipient objects, such as distribution lists and foreign recipients that exist outside of the environment that is being migrated. Performing a complete migration of recipient information allows your users to continue using familiar e-mail addresses in their new messaging environment.
You can migrate directory information in one of the following ways:
| • | Automated migration Using the Exchange Migration Wizard, you can automatically create mailbox-enabled user accounts in Active Directory when you migrate mailboxes. However, the Exchange Migration Wizard has limited capabilities for handling distribution lists or groups. |
| • | Manual migration You can use Active Directory Users and Computers to create mailbox-enabled user accounts and other recipient objects manually. This strategy works well if you are migrating a small number of users. |
| • | Programmatic migration You can use ADSI and CDOEXM to develop custom applications in Microsoft Visual Basic, Scripting Edition (VBScript). For example, you can create an ASP page to migrate and maintain recipient information. This approach is flexible and allows you to mirror mailboxes, distribution lists, and foreign recipients as in the legacy messaging system, but it requires programming skills. |
| • | Semi-automated migration If you can export all recipient information from the legacy messaging system into a text file, you can use this information to create an LDIF file to import the recipients to Active Directory using Ldifde.exe, or create a .csv file and import the information using Csvde.exe. |
The Exchange Migration Wizard can create mailboxes automatically. You can specify the organizational unit for new mailbox-enabled user accounts. You can also specify how passwords are generated. The Exchange Migration Wizard can use the account name as the password or generate random password strings for all users, which are then written to an ACCOUNT.PASSWORD file in the temporary migration directory.
If you want to change or add recipient information, you can perform a two-step migration in the Exchange Migration Wizard and edit the Directory.pri user list file before you apply the changes in Exchange 2003. If possible, however, avoid changing the Secondary-Proxy-Addresses field of your users. The Exchange Migration Wizard retains each user's original e-mail address in this field when it creates the user accounts in Active Directory, so that Exchange can route replies to old messages to the user's new Exchange 2003 mailbox. For example, assume a migrated user (now an Exchange user) replies to an old message of yours or specifies your old e-mail address in a new message. When the user clicks the Check Names button on the toolbar (or sends the message without performing this step, at which time Outlook checks the name automatically), Exchange can find a recipient object in Active Directory that refers to your mailbox, because this recipient object has a matching secondary proxy address. The e-mail message is then delivered to your Exchange 2003 mailbox. There is more information about secondary proxy addresses later in this chapter.
Note :
If non-Exchange users send messages to the old addresses of migrated users, NDRs might be generated if you have deleted the old mailboxes from the legacy messaging system after migration. Some messaging systems support auto-forwarding rules. In this case, it might be advantageous to hide migrated mailboxes instead of deleting them and to configure an auto-forwarding rule to forward all messages that are sent to the old addresses to the new Exchange mailboxes.
Recipient information might already exist in Active Directory before you run the Exchange Migration Wizard because, for example, your Lotus Notes, Novell GroupWise, or IMAP4 users already have user accounts in a Windows domain that belongs to your Active Directory forest. Running the Exchange Migration Wizard in this situation should not lead to duplicate user information. The Exchange Migration Wizard searches Active Directory for matching recipient objects in an attempt to minimize account duplication.
If you migrate from a non-Exchange mail system, the Exchange Migration Wizard uses the following information to determine matches:
| • | The Exchange Migration Wizard matches
the e-mail address of the account to be migrated to the
e-mail address of the target user object in
Active Directory. Because e-mail addresses in a messaging
system are unique, any matching accounts are considered
definite matches.
If you attempt to break a definite match during a migration, the Exchange Migration Wizard warns you that the selected object cannot be unmatched because the association is based on a matching proxy address. When you migrate from a non-Exchange system and want to avoid definite matches with existing user accounts, you must edit the user's e-mail address in the messaging system from which you are migrating or the e-mail address of the Active Directory user object so that the addresses no longer match before you start the migration process using the Exchange Migration Wizard. |
||||
| • | The Exchange Migration Wizard matches
the Full Name and Logon ID attributes of the
account to be migrated to the Full Name and Logon
ID attributes of the target user object. Because the
Full Name and Logon ID attributes might not be
unique in an Active Directory forest with multiple domains,
any matching accounts are considered probable matches.
You have two options for modifying probable matches, which appear in the Existing Windows Account column on the Windows Account Creation and Association page in Exchange System Manager:
|
When you examine the account creation options in the Exchange Migration Wizard (click Options on the Container for New Windows Accounts wizard page), you find that the Exchange Migration Wizard is able to associate migrated accounts with accounts in an external domain. You also have the option to create associated accounts in an external domain if you specify an Administrator account with appropriate account administrator rights. This functionality is useful if you plan to migrate non-Exchange users into an Exchange 2003 organization that is deployed into a resource forest.
Organizations deploy Exchange 2003 in a resource forest if internal resources are distributed over a variety of Microsoft Windows NT® domains or separate Active Directory forests. In this situation, you deploy a separate forest for the Exchange 2003 organization with deactivated mailbox-enabled user accounts. You must establish trust relationships between the resource forest and the account domains. You can then assign an external account from an account domain the Associated external account permission for a deactivated mailbox-enabled user account in the resource forest. To do so, go to the properties of a mailbox-enabled user account in Active Directory Users and Computers, switch to the Exchange Advanced tab, and click Mailbox Rights. This mailbox right enables specified users to log on to the mailbox using their own accounts. The Exchange Migration Wizard can establish the external account association automatically. For more information about the deployment of Exchange Server 2003 in a resource forest, see Planning an Exchange Server 2003 Messaging System (http://go.microsoft.com/fwlink/?LinkId=21766).
If Exchange System Manager does not support your legacy messaging system, or if you opted to use a different migration method, you might need to create mailboxes and other recipient objects in Exchange 2003 manually. In Exchange 2003, mailboxes are created by mailbox-enabling user accounts in Active Directory. Legacy distribution lists correspond to mail-enabled user groups, and address references to recipients outside of the legacy messaging system correspond to mail-enabled user accounts or contacts in Active Directory. You can use Active Directory Users and Computers to mailbox-enable user accounts or mail-enable user accounts, groups, and contacts. Table 1.5 matches typical recipient objects in a non-Microsoft messaging system to corresponding recipient objects in Active Directory.
| Table 1.5 Recipient objects in non-Microsoft messaging systems and in Exchange 2003 | ||||||||||
| Non-Microsoft messaging system | Exchange 2003 messaging system | Comments | ||||||||
|
Mailbox |
Mailbox-enabled user account |
If your users already have accounts in Active Directory (for example, because they are working with Microsoft Windows XP workstations in a Windows domain environment), mailbox-enable the existing accounts. For users who do not exist in the Active Directory forest, create new mailbox-enabled accounts. |
||||||||
|
External recipient |
Mail-enabled user account |
Use mail-enabled user accounts if the users are in your Active Directory forest but remain on a non-Exchange messaging system that is not being migrated. |
||||||||
|
External recipient |
Mail-enabled contact |
Use mail-enabled contact objects for users who are not in your Active Directory forest and are on a non-Microsoft messaging system that is not being migrated. |
||||||||
|
Distribution list |
Mail-enabled universal distribution or security group |
If possible, create mail-enabled security groups and configure the group membership according to the distribution lists in the legacy system. Mail-enabled groups can contain any type of recipient object, including mailbox-enabled users, mail-enabled users, mail-enabled groups, mail-enabled contacts, and mail-enabled public folders. |
||||||||
|
Distribution list |
Mail-enabled public folder |
Under some
circumstances, you might want to configure mail-enabled
public folders for legacy distribution lists. For example,
you can migrate distribution lists to public folders and
configure public folder rules to forward incoming messages
to all recipients that were originally members of the
distribution lists. This approach has several disadvantages,
however, including:
Note : To implement a message archive for a distribution list, you can mail-enable a public folder, and then add the public folder as a member to the distribution group, but you should not use a public folder to replace a distribution group. |
||||||||
Exchange 2003 maintains server-based address lists, such as the global address list, automatically when you mailbox- or mail-enable directory objects in Active Directory. This is the job of the Recipient Update Service. This service assigns default e-mail addresses to all mailbox- or mail-enabled recipient objects, such as user accounts, groups, and contacts. A recipient policy determines the format of generated e-mail addresses.
Use Exchange System Manager to adjust the settings in the default recipient policy, as follows:
| 1. | In the console tree, expand the Recipients container and then select Recipient Policies. In the details pane, the Default Policy object is listed. If you want to preserve existing recipient information, you must adjust this recipient policy or create a new policy with a higher priority that applies to all relevant objects and assigns default e-mail addresses that correspond to those in the legacy messaging system. | ||||||||||||||
| 2. | Double-click the Default Policy object to display
its properties, and then click the E-Mail Addresses
tab. You can now change the various address generation
rules, such as those for SMTP addresses. You can use
placeholders in your e-mail address generation rules. For
example, if you want to change from the default address
format of <User Logon Name>@<Domain Name> to
an address format of <First Name>.<Last Name>@<Domain
Name> (for example, Ted.Bremer@contoso.com), you must
use placeholders for the first and last names, because this
is variable information. In this example, you select the
entry for SMTP addresses on the E-Mail Addresses tab,
click Edit, and, under Address, add %g.%s
to the beginning of the address definition (for example,
%g.%s@contoso.com). In addition, you can specify how many
characters to use (for example, %g%1s@contoso.com results in
TedB@contoso.com). Table 1.6 lists the possible placeholders
in address generation rules.
Note : For information about additional placeholders that can be used, see Microsoft Knowledge Base Article 285136, "XADM: How to Customize the SMTP E-mail Address Generators Through Recipient Policies" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=285136). |
||||||||||||||
Some organizations want to change their SMTP addresses during migration, especially if they are involved in a company merger. However, if you assign new e-mail addresses to your users, replies to old messages become non-deliverable. To preserve the old address information, adjust your recipient policies to assign secondary SMTP addresses to your users, in addition to new primary SMTP addresses. You must specify an address generation rule that generates secondary addresses that match the legacy system. Exchange 2003 then uses the primary SMTP address for all outgoing e-mail and also delivers all incoming e-mail addressed to any of the assigned secondary addresses. Recipients in an Exchange 2003 organization can have one primary SMTP address and as many as 32 secondary SMTP addresses, which is sufficient for most users.
You can use ADSI and CDOEXM to create mailbox- and mail-enabled recipient objects in Active Directory. Important objects are CDO.Person and ADSI.User. The following VBScript code example uses CDO.Person to create a user account in Active Directory and mailbox-enable it.
Note :
The following code example was written and tested on a domain controller named Server01 with an Exchange server named EX-SRV1 in the domain contoso.com. If you want to test this code on another computer, you must change the LDAP path. The same applies to all other code examples in this chapter.
An example for working with Active Directory information using ADSI.User follows in the section "Updating Recipient Information Through VBScript."
Set oPerson = CreateObject("CDO.Person")
oPerson.LastName = "Bremer"
oPerson.DataSource.SaveTo "LDAP://server01.contoso.com/" _
& "CN=Ted,CN=Users,DC=Contoso,DC=com"
Set oMailbox = oPerson.GetInterface("IMailboxStore")
oMailbox.CreateMailbox _
"CN=Mailbox Store (EX-SRV1),cn=First Storage Group," _
& "cn=InformationStore,cn=EX-SRV1,cn=Servers," _
& "cn=First Administrative Group," _
& "cn=Administrative Groups,cn=Exchange," _
& "cn=Microsoft Exchange,cn=Services,cn=Configuration," _
& "dc=Contoso,dc=com"
oPerson.DataSource.Save
set oMailbox = nothing
set oPerson = Nothing
Notice the use of the IMailboxStore interface, which you can retrieve from CDOEX and ADSI objects through the GetInterface method. IMailboxStore is a CDOEXM interface that facilitates the creation of mailboxes for user accounts. This code example does not specify any e-mail addresses. The Exchange Recipient Update Service assigns the information based on recipient policies, as explained earlier. For more information about ADSI, CDOEX, and CDOEXM, see the Exchange Software Development Kit (SDK) (http://go.microsoft.com/fwlink/?LinkId=25925).
If you are not a programmer, you can use Ldifde.exe or Csvde.exe to create the required recipient objects. Ldifde.exe works with LDIF files, a file-format standard for batch operations against LDAP-conforming directories. To view the general parameters of Ldifde.exe, open the command prompt, type ldifde, and press ENTER. The output on the screen explains available options and gives sample command lines. For detailed information about Ldifde.exe, see Microsoft Knowledge Base article 237677, "Using LDIFDE to Import and Export Directory Objects to Active Directory" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=237677).
Many large companies that operate heterogeneous messaging environments prefer to perform directory synchronization manually. This allows them to keep the synchronization of directories, which contain hundreds of thousands of recipient objects, under control. Address book files are usually distributed in .csv format. This file format is convenient because it allows you to process address information in Excel before you import the information. You use the Csvde.exe tool to process this file type. The command syntax is the same as for the LDIFDE tool. Both tools have many features in common.
The following example uses Ldifde.exe to create a mailbox-enabled user account named Ted with SMTP and X.400 proxy addresses. You can import this file with the following command: ldifde -i -f <Import File> -s <Domain Controller> (for example, ldifde -i -f Import.ldf -s server01).
dn: CN=Ted,CN=Users,DC=contoso,DC=com changetype: add displayName: Ted objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=contoso,DC=com objectClass: user proxyAddresses: X400:c=us;a= ;p=Exchange;o=Exchange;s=Ted; proxyAddresses: smtp:OldTed@Contoso.com proxyAddresses: SMTP:Ted@Contoso.com name: Ted sAMAccountName: Ted userAccountControl: 512 userPrincipalName: Ted@Contoso.com msExchHomeServerName: /o=Exchange/ou=First Administrative Group/cn=Configuration/cn=Servers/cn=EX-SRV1 mailNickname: Ted
Important :
When you create user accounts with Ldifde.exe and Csvde.exe, ensure that the information specified in your import file applies to your specific environment. Neither Ldifde.exe nor Csvde.exe performs validity checks. For example, it is possible to import msExchHomeServerName information that is not valid, in which case the mailbox is placed on a nonexistent server, and the user cannot participate in the Exchange organization. If this happens, correct the information by modifying the affected attributes through Ldifde.exe, in a manner similar to the procedures outlined in the previous sections.
After you create recipient objects in Active Directory using the Exchange Migration Wizard, Active Directory Users and Computers, or any of the other described methods, you might want to verify and update primary or secondary e-mail addresses. This is especially true if you must preserve existing address information that does not follow a specific pattern. If your users have arbitrary e-mail addresses, you cannot preserve this information by using recipient policies. You must adjust the e-mail addresses manually in Active Directory Users and Computers after the Recipient Update Service has assigned the default addresses. This can be confusing, especially if you are migrating a large number of users. To simplify this task, use Ldifde.exe, Csvde.exe, or ADSI and CDOEXM to perform batch operations against Active Directory.
The process of updating recipient information in Active Directory using Ldifde.exe is almost the same as the process for creating mailbox-enabled user accounts that is described earlier. You only need to specify the type of change and the directory object that you want to modify. To modify the e-mail addresses of user accounts, groups, and contacts, export the directory information from a domain controller first. From the resulting export file, you can then determine the distinguished name of each individual recipient object that you want to update. The distinguished name uniquely identifies directory objects.
Use the command ldifde -f c:\Export.ldf -s <Domain Controller> (for example, ldifde -f export.ldf -s server01) to export all available directory information in the domain. You can restrict output to a specific organizational unit or even to a specific user account, if you use the –d parameter and specify the distinguished name of the search base for data export. Use the following command to export all objects in the Users container: ldifde -f Export.ldf -s <Domain Controller> -d "CN=Users,DC=<Domain>,DC=<com>" (for example, ldifde -f Export.ldf -s server01 -d "CN=Users,DC=Contoso,DC=com").
After exporting the directory information and determining the distinguished names of the recipient objects that interest you, it is relatively easy to create an import file for an e-mail address update. The lines containing distinguished names start with dn:. The following example shows an import file that assigns two SMTP addresses and one X.400 address to a mailbox-enabled account named Ted. You can import this file the same way that you create accounts (for example, ldifde -i -f Import.ldf -s server01).
dn: CN=Ted,CN=Users,DC=contoso,DC=com changetype: modify replace: proxyAddresses proxyAddresses: SMTP:Ted@contoso.com proxyAddresses: X400:c=US;a= ;p=FirstOrg;o=Exchange;s=Ted; proxyAddresses: smtp:postmaster@contoso.com -
Remember the hyphen between update records and on the last line of your import file.
Important :
Back up your domain controllers and global catalog servers, test your import files in a computer lab, and verify the results carefully before you use Ldifde.exe in your production environment. Using Ldifde.exe with incorrect import settings can corrupt Active Directory and force you to restore Active Directory from backup.
Csvde.exe is not as powerful a tool as Ldifde.exe, because Csvde.exe is unable to modify or delete existing directory objects. Therefore, if you plan to update recipient information based on a .csv file, you must extract the relevant .csv entries and write them into an .ldf file. You can then use Ldifde.exe as described earlier.
The following Excel macro demonstrates how to generate an .ldf file from a .csv file that contains the proxyAddresses attribute. In this code, it is assumed that the distinguished name is in the first column of the file and loops through all remaining header cells to determine the proxyAddresses column. The result is an entry for each recipient object from the .csv file to modify the proxyAddresses attribute. This approach can be applied with minimal modification to other directory attributes, as well.
Sub LDFfromCSV(Optional sAttribute As String = "proxyAddresses")
' Create the LDF file.
sDefName = Application.DefaultFilePath & "\Import.ldf"
sFile = Application.GetSaveAsFilename(InitialFilename:=sDefName, _
Title:="Save LDF file")
If sFile = "" Then
Exit Sub
Else
Set fso = CreateObject("Scripting.FileSystemObject")
Set f = fso.CreateTextFile(sFile, True)
End If
' Determine the number of entries in the .csv file.
nRows = ActiveSheet.UsedRange.Rows.Count
nColumns = ActiveSheet.UsedRange.Columns.Count
For i = 2 To nRows
' Specify the distinguished name of each recipient
' for whom you want to modify a value.
sVal = ActiveSheet.Cells(1, 1).Value & ": " _
& ActiveSheet.Cells(i, 1).Value _
& vbCrLf & "changetype: modify" & vbCrLf
For j = 2 To nColumns
sHdrValue = ActiveSheet.Cells(1, j).Value
If sHdrValue = sAttribute Then
' You are now in the appropriate column.
sVal = sVal & "replace: " & sHdrValue & vbCrLf _
& sHdrValue & ": " & ActiveSheet.Cells(i, j).Value _
& vbCrLf & "-" & vbCrLf
End If
Next
sEntry = VBA.Replace(sVal, "\,", "\,", 1, -1, vbTextCompare)
f.writeline sEntry
Next
f.Close
Set f = Nothing
Set fso = Nothing
End Sub
To demonstrate the conversion of a .csv file into an .ldf file, export the objects from the Users container using Csvde.exe. For example, type the following command: csvde -f export.csv -s <Domain Controller> -d "CN=Users,DC=<Domain>,DC=<com>". Among other information, the resulting file contains the proxyAddresses attribute for all mailbox-enabled user accounts. You can then change the proxyAddresses information for selected users and run the macro to generate the .ldf file.
If you want to update recipient information in a more straightforward way than with Ldifde.exe and Excel macros, you can use ADSI and VBScript in a custom administration tool. The following code example demonstrates how to set e-mail addresses for a user account programmatically using the ADSI.User object. You can use this code in an ASP page, for example. Remember to include your own code for checking permissions and error handling. The code example is a good starting point for an Active Directory application.
Const ADS_PROPERTY_CLEAR = 1
Const ADS_PROPERTY_UPDATE = 2
Const ADS_PROPERTY_APPEND = 3
Const ADS_PROPERTY_DELETE = 4
Set oUser = GetObject("LDAP://CN=testuser,CN=Users,DC=contoso,DC=com")
oUser.PutEx ADS_PROPERTY_UPDATE, "proxyAddresses", _
Array("SMTP:olduseraddr@contoso.com", _
"SMTP:updateduser@contoso.com", _
"X400:c=us;a= ;p=Exchange;o=Exchange;s=updateduser;")
oUser.SetInfo
Important :
As with Ldifde.exe and Csvde.exe, you must thoroughly test your solutions in a computer lab before deploying them in the production environment. Incorrect use of ADSI can corrupt Active Directory and force you to restore Active Directory from a backup. Ensure that you have a functioning backup of your domain controllers and global catalog servers.
Users usually insist that important messages, appointments, tasks, and contact information be preserved during migration. To accomplish this, you must develop strategies for moving existing data to Exchange 2003. Data might reside on the server in mailboxes, discussion boards, and other repositories, or on the client computers in personal message stores.
If your users store the majority of their data on the server, you must develop a strategy for migrating data on their behalf. This requires addressing the following questions:
| • | Are special resource accounts included in the migration to Exchange 2003? Special accounts might be used to represent a particular resource or piece of equipment, such as a meeting room, online conference, and so on. The account's calendar is used to book that resource or equipment, similar to the way a meeting is scheduled. Using the Exchange Migration Wizard, you can move special accounts and their data to Exchange 2003. However, the configuration is not retained. The wizard cannot distinguish user mailboxes from resource mailboxes, for example. Therefore, you must adjust the configuration manually. You must grant the user responsible for the resource Full Mailbox Access rights to the corresponding mailbox-enabled resource account in Active Directory Users and Computers, and you must connect to the resource mailbox in Outlook to reconfigure it as a resource account. On the Tools menu in Outlook, click Options. On the General tab, click Calendar Options, and then click Resource Scheduling. You must repeat these steps for all migrated resource accounts. |
| • | Do you have sufficient disk space on the server to perform the migration to its full extent? The Exchange Migration Wizard requires temporary disk space for its migration files. Also, Exchange 2003 stores migrated messages in two locations: databases and corresponding transaction log files. You should reserve at least three times as much disk space for the migration than is required for the actual amount of data that you plan to move. Disk space requirements are greater than for the legacy system, because the migration tools are not capable of handling single-instance storage. Single-instance storage is a feature that saves disk space and accelerates message delivery. A single message instance addressed to five recipients is stored only once with five pointers to the object for each individual recipient. However, migration tools, like users, see the object as an individual message item. The item is extracted five times, once for each individual mailbox. As a result, the item is copied five times to the Exchange store. |
| • | Do you have the required access permissions to migrate all data on behalf of your users? The account that you use to access the source messaging system (that is, the migration account) must have sufficient access rights to extract data from all mailboxes. This might require more than just administrator rights on a post office. For example, in Novell GroupWise, you must grant the migration account Novell GroupWise proxy rights for all mailboxes. |
| • | Do your users store encrypted messages in their server-based mailboxes? Decryption is required to convert messages into Exchange formats, but only the correct user can perform decryption. Instruct your users to download all encrypted messages to their clients, and point out that after migration, message encryption can be performed in Outlook using standard X.509 version 3-based encryption technology. |
| • | Does the Exchange Migration Wizard support the existing messaging system? The Exchange Migration Wizard is the primary Exchange 2003 migration tool and should be used, if possible. If your system is not supported, however, consider moving all data from the server to the users' workstations or use a non-Microsoft migration tool. |
| • | Is it possible to consolidate messaging resources before migration? The fewer the post offices or mail hosts that you must manage, the easier the migration. However, consolidating legacy messaging systems in their existing environments might be as complex as migrating each system individually. Consolidating messaging resources during the migration might be a more suitable approach. For example, you can migrate multiple post offices to the same Exchange 2003 server. |
| • | Should all items or only the most recent items be migrated? You can set a date range in the Exchange Migration Wizard that specifies the age of messages that you want to retain. Many companies use this opportunity to eliminate legacy e-mail, which saves disk space on the server and reduces migration time. Nevertheless, it is advisable to establish a policy regarding data that will not be migrated and to inform users so that they can print legacy messages, private address lists, and other information, such as message processing rules, or store the data in personal message archives. |
| • | Will you migrate data over the computer network? If it is not possible to copy entire post offices or other message repositories to the local Exchange server before migration, verify that the net-available bandwidth in your computer network can handle the workload. Ensure that source and target systems are in the same LAN. Avoid data migration over WAN connections, if possible, and perform maintenance and consistency checks before the migration. |
If your users maintain their e-mail messages, contacts, and calendar information locally, instead of on the server, you have the following four migration choices:
| • | Allow users to move their local data back to the server before migration Moving data back to the server might not be advantageous. It increases network traffic, consumes disk space on the server, and generally makes the work of the messaging administrator more difficult. Some messaging systems, such as POP3 hosts, do not support this option. |
| • | Have users work with Outlook in the legacy messaging environment Working with Outlook in the legacy environment allows users to download all data into personal folder stores if local disk drives have sufficient storage capacity. This reduces the amount of data that you must move using the Exchange Migration Wizard, and it avoids permission-related issues or issues with encrypted messages. The users can continue to use these repositories in the Exchange 2003 organization. |
| • | Require that users migrate client-based data themselves Asking users to perform the data migration themselves is an ideal choice from an administrator's perspective, but it might overwhelm the user. This can lead to frustration, increased help desk calls, and decreased productivity. |
| • | Perform the migration manually on each user's computer Having administrators or help desk personnel perform the client-based data transfer together with the users is a practicable solution for many companies. |
Workgroup and workflow applications complicate a migration scenario. In fact, the presence of workgroup and workflow solutions and their data might prevent a single-phase migration. This might force you into a phase of short- or long-term coexistence and interoperability between Exchange 2003 and the legacy messaging system, until critical business applications are reengineered and deployed in the Exchange 2003 organization. The more sophisticated the workgroup solutions, the more complicated the migration and the higher the costs.
When you determine your migration strategy for workgroup and workflow applications, address the following questions:
| • | Are you planning to migrate collaboration applications to Exchange 2003 or other platforms? You have two general options for migrating workgroup and workflow applications: you can port these solutions to Exchange 2003 or to a different platform. It might be a good idea to migrate your workgroup solutions to a system other than Exchange 2003 to eliminate the interoperability requirement in your migration plan. Some applications can be ported to a database management system (DBMS), such as Microsoft SQL Server™, in combination with a Web server, such as Internet Information Services (IIS) and the Microsoft .NET platform. The technologies in the Office system, such as Microsoft Windows SharePoint® Services, can also be used to develop and implement collaboration applications for task, contact, and calendar sharing. Additionally, Microsoft Office SharePoint Portal Server 2003 can be the basis for document management solutions. To learn more about SharePoint products and technologies, go to the SharePoint Web site (http://www.microsoft.com/sharepoint). |
| • | Do critical workgroup applications
exist that require extensive programming to port them to the
new environment? If this is the case, identify options
to migrate the applications or develop a coexistence
strategy based on a multiphase migration.
Note : If you cannot migrate essential workgroup and workflow applications in a timely manner, you cannot perform a single-phase migration. |
| • | Do you need to port public discussion forums to Exchange 2003? If so, identify one person to become the owner of all public folders that you create for discussion forums in Exchange 2003. You must also identify user default and specific permissions to the public folders, because permissions settings are not migrated. You must manually correct the security settings afterward using Exchange System Manager. If existing discussion forums rely on custom forms for data input and display, use Outlook Forms Designer to implement a corresponding Outlook form and associate this form with the corresponding public folder. |
In a multiphase migration, you use many of the same migration procedures as you do in a single-phase migration. The difference is that you perform these procedures many times. Consequently, many of the strategic questions that you must answer when planning a single-phase migration are also relevant in a multiphase scenario. However, there are several additional issues resulting from the requirement for interoperability that you must address before you migrate users. To ensure a successful migration in multiple phases, you must:
| 1. | Preserve message paths to maintain uninterrupted message transfer During the migration, users must be able to exchange e-mail with all recipients in the company and with Internet recipients. You must ensure that the messages are transferred to the correct destinations, no matter where the mailboxes of your users reside. |
| 2. | Synchronize directory information to maintain consistent and current address book information When they send e-mail messages, users must be able to choose a recipient from an address list and know that the message will be delivered to the appropriate user. As a result of this requirement, you must maintain accurate user and distribution list information in both messaging directories while you migrate the mailboxes to Exchange 2003. |
| 3. | Synchronize calendar information to provide all users with current free/busy information Many companies use the calendaring component in the legacy messaging system as the primary means for scheduling meetings. You must retain this functionality during the migration to Exchange 2003. You must ensure that users can see when other users are available for meetings, and that meeting requests are transferred between the systems. |
Use the flowchart shown in Figure 1.5 as a guide to determine an appropriate sequence of steps in a multiphase migration.
Figure 1.5 Generic multiphase migration approach
Before you migrate any user mailboxes to the Exchange 2003 organization, you must implement a message transfer topology that ensures that messages from internal and external users are delivered correctly. After you have implemented the topology, create test mailboxes or migrate a few test accounts to Exchange 2003 to confirm that message routing works as expected.
When you connect Exchange 2003 to an existing messaging infrastructure and preserve message paths, you must find answers to the following questions:
| 1. | How will you maintain message transfer? You
have two options for configuring message routing between the
messaging systems:
|
||||
| 2. | How will you support communication with external
users? The second task in maintaining message routing
is to ensure that there is no disruption in the delivery of
Internet e-mail. As you migrate the existing messaging
system to Exchange 2003, you will also migrate the Internet
e-mail functionality. You must change the routing to deliver
messages from external sources to the mailboxes on
Exchange 2003. You have several options to address external
communication in a migration scenario:
|
