Lesson 1: Single-Phase Migration Strategies | MCSE Training Kit (Exam 70-225): Microsoft Exchange 2000 Server Design and Deployment (Pro-Certification)

The single-phase migration is quick and easy. The day before the migration, all users are on a foreign messaging system. The next day, or after a weekend, they all are using Exchange 2000 Server, and the old system is decommissioned. Existing user data may or may not be migrated. In fact, some enterprises opt to reduce the cost in man-hours of migration by skipping the transfer of existing messages. This forces users to save memos and other important information on their local computers. However, you don’t have to follow this example. Because it is generally desirable to keep existing messages, a variety of migration tools are available from Microsoft and third-party vendors to conveniently preserve as much data from the old system as possible.

This lesson covers the single-phase migration from foreign messaging networks to Exchange 2000 Server using standard migration tools from Microsoft. You can read about the advantages and disadvantages of this strategy, as well as the tools available in the Exchange 2000 Server product package that allow you to move existing data over to the new messaging environment.

After this lesson, you will be able to

Explain how to use the migration tools included in Exchange 2000 Server to migrate users from foreign messaging systems
Develop a single-phase migration strategy according to the specific needs of your organization

Estimated time to complete this lesson: 60 minutes

Understanding the Single-Phase Migration

Perhaps the greatest advantage of the single-phase migration is its simplicity. You don’t need to take the existing messaging system into consideration when designing the future Exchange 2000 organization. Connectivity to the foreign system or directory synchronization is not required. You can work as if no other platform existed. Another advantage is that single-phase migrations offer quick results. They are most appropriate for small companies with relatively few resources, such as fewer than 500 mailboxes.

The following are the most important advantages of the single-phase migration strategy:

All users are migrated in a single process, which permits very quick results.
It is possible to deploy Microsoft Outlook 2000 on all desktops prior to migration, while retaining the legacy infrastructure. Users can familiarize themselves with the new messaging client. Afterward, only the Messaging Application Programming Interface (MAPI) profiles require reconfigurationto connect to an Exchange 2000 server instead of the former mail system, as explained in Chapter 4, "Assessing the Current Messaging Infrastructure."
There is no need for messaging connectivity or directory synchronization between the foreign system and Exchange 2000 Server.

Unfortunately, the single-phase migration also has disadvantages, some of which follow:

Migrating large numbers of users or large amounts of data can result in an unacceptable downtime period.
The project team must establish the entire Exchange 2000 organization before the users can be migrated. All hardware, as well as server and client software, must be in place prior to migration.
You are unable to control the pace. You cannot migrate divisions or departments individually, for instance.
You have only limited flexibility to address problems. For instance, it is not possible to leave a particular group of users on the old system if the data migration fails.
Single-phase migrations are not applicable in all situations. For example, large organizations with multiple sites or locations are typically unable to replace their entire messaging infrastructure at once.

Migrating Users and Data

It is possible to split the single-phase migration into two parts: directory and user data migration (see Figure 7.1). Directory migration refers to the process of creating recipients in the new environment that match those available in the address lists of the former system. The migration of user data, on the other hand, means copying existing messages, calendars, and other user-related information, such as personal address lists, to the new system.

Directory Migration

Directory migration is always required, because, at a minimum, you need to create new mailbox-enabled accounts for your users in the Active Directory directory service. You might also want to migrate existing distribution lists and foreign recipients to facilitate communication in the Exchange 2000 organization. You can read more about the migration of recipient objects, such as distribution lists, in Lesson 2.

You can migrate directory information in one of the following ways:

Manual migration Use the Active Directory Users and Computers console to create mailbox-enabled user objects and other recipient objects manually (for a reference list of recipient types, see Table 7.1). This strategy works well in very small environments.
Semiautomated migration Export all recipient information from the foreign messaging system in a text file and use this information to create a file in LDAP Data Interchange Format (LDIF) to import the recipients into Active Directory using LDIFDE.EXE, or create a comma-separated values (.csv) file and import the information using CSVDE.EXE. The semiautomated import of recipient information into Active Directory is discussed in Chapter 4, "Assessing the Current Messaging Infrastructure."
Automated migration Using a migration tool, such as the Exchange 2000 Migration Wizard, you can create mailbox-enabled user accounts in Active Directory for existing mailboxes automatically. Unfortunately, the Migration Wizard is unable to migrate server-based distribution groups or external recipient information, leaving you with the task of creating corresponding mail-enabled objects in Active Directory manually (see Table 7.1). However, the Migration Wizard can migrate account information from Internet directories that support the Lightweight Directory Access Protocol (LDAP).

Figure 7.1 - Directory and user data migration

Note

The Migration Wizard can create new user accounts for mailboxes with users outside the Active Directory forest. On the Container For New Windows Accounts wizard page, select the desired organizational unit (OU), and then click Options to specify how passwords should be generated. The 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.

Table 7.1 Recipient Objects in Foreign Messaging Systems and in Exchange 2000 Server

Foreign Messaging System	Exchange 2000 Server	Comments
Mailbox	Mailbox-enabled user account	If your users are already using Microsoft Windows 2000, mailbox-enable the existing accounts. For users that do not exist in the Active Directory forest, create disabled mailbox-enabled accounts and assign the users the Full Mailbox Access and Associated External Account rights, as explained in Chapter 3, "Assessing the Current Network Environment."
External recipient	Mail-enabled user account	Use mail-enabled user accounts if the users are in your Active Directory forest but on a foreign messaging system that is not being migrated.
External recipient	Mail-enabled contact	Use mail-enabled contact objects for users that are not in your Active Directory forest and on a foreign messag- ing system that is not being migrated.
Distribution list	Mail-enabled universal distribution or security group	If possible, configure mail-enabled security groups in a native-mode domain and configure the group membership according to the distribution lists in the foreign 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. The advantages of mail-enabled security groups are discussed in Chapter 6, "Designing an Upgrade Plan to Microsoft Exchange 2000 Server."
Distribution list	Mail-enabled public folder	Under some circumstances, it might make sense to configure mail-enabled public folders for legacy distribution lists. The disadvantages of this approach are discussed in Lesson 2.

Migrating Server-Based User Data

The migration of user data may seem optional, but users are usually insistent that all—or at least the most important—of their existing messages, calendar information, and personal address books (PABs) are preserved. The Migration Wizard can automate the process of moving the data over to the new system with only a few mouse clicks. The Migration Wizard connects to the source mail system, extracts the user data into temporary migration files, and then connects to the target Exchange 2000 server to place the data into the corresponding mailboxes, which the wizard can create automatically for you (see Figure 7.2). You can complete the entire process in one step or in two steps if you want to modify the migration files before the import, for instance, to specify additional recipient information.

It is important to note that the account you specify to access the source messaging system (that is, the migration account) must have sufficient access rights to extract the data from the user mailboxes. This might require more than just administrator rights on a post office. For instance, in Novell GroupWise, you need to grant the migration account GroupWise proxy rights for all mailboxes. A sample PROXY.WCM macro to automate the process of granting proxy rights is available in the \Migrate\Gwise directory on the Exchange 2000 Server CD. In Active Directory and Exchange 2000 Server, you need to be a full administrator to create the target mailboxes and copy the data into them.

Figure 7.2 - The Migration Wizard principle

The Migration Wizard is able to migrate user data from the following messaging systems (see Figure 7.3):

Any system for which a source extractor is available The Migration Wizard comes with a variety of built-in source extractors, but you can also use stand-alone extractors to copy user data and public information into migration files that the Migration Wizard can import into Exchange 2000 Server. Microsoft provides several stand-alone source extractors to create migration files for Microsoft Mail for AppleTalk Networks (now Quarterdeck Mail), IBM Professional Office System (PROFS), Verimation Memo (now NetSys Memo), and DEC ALL-IN-1.
Collabra Share versions 1.x or 2.x Allows you to migrate public forums and documents from Collabra Share into Exchange 2000 public folders.
Internet mail systems that support Internet Message Access Protocol version 4 (IMAP4) Allows you to migrate message items from mailboxes and public repositories of IMAP4-compliant messaging systems.
Lotus cc:Mail with DB6 or DB8 Allows you to migrate messages, message drafts, attachments, folders, personal mail lists, and bulletin boards from Lotus cc:Mail post offices.
Lotus Domino/Notes versions 3.x or 4.x Allows you to migrate messages and calendar information from Lotus Notes 3.x or Lotus Domino 4.x databases. The Migration Wizard can convert Notes doclinks to object linking and embedding (OLE) shortcuts, Rich Text Format (RTF) documents, or Uniform Resource Locators (URLs). A separate utility is available to convert Lotus Notes applications to workgroup solutions for Exchange 2000 and Outlook 2000. The Microsoft Exchange Application Converter for Lotus Notes is in the \Migrate\Asn\Setup\I386 directory on the Exchange 2000 Server CD.
Microsoft Mail for PC Networks version 3.x Allows you to migrate messages, Microsoft Schedule+ information, PABs, and information from shared folders to Exchange 2000 Server. If your users are already working with Outlook 2000 in a Microsoft Mail environment, migration of user data is not required. The data is already stored in a .pst file on the users’ local computers. Outlook 2000 can continue to use .pst files in the Exchange 2000 organization.
Novell GroupWise 4.x and 5.x Allows you to migrate messages and calendar information from Novell GroupWise post offices. Novell GroupWise is often used in conjunction with Collabra Share, which the Migration Wizard also supports (as previously mentioned).

Figure 7.3 - The Exchange 2000 Migration Wizard

Note

The Migration Wizard may require additional software to be fully functional, such as the Lotus cc:Mail EXPORT.EXE utility, Lotus Notes client R4.52, or a Novell GroupWise client installed on the local machine. Verify in a test lab that the migration procedures work before you launch the production rollout. For more information about the Migration Wizard, consult the Exchange 2000 Server product documentation and the Migration Wizard help file.

Migrating Client-Based User Data

The Migration Wizard is a very powerful and flexible utility that facilitates the migration of users and data; however, this wizard is unable to handle data that is on the client computers. For instance, Lotus cc:Mail users who saved their e-mail messages in personal archives must migrate the data themselves. The same is true for Lotus Organizer calendars.

You have two choices: You can either ask your users to move their data back into the post offices (or mail servers) prior to the migration, perform the migration manually on each user’s computer, or encourage users to migrate the client-based data themselves. Users have a variety of options at hand to accomplish this. For instance, Outlook 2000 is able to import data from a range of sources, including Lotus cc:Mail archives, Lotus Organizer calendars, personal store (.pst) files, databases, and so on (see Figure 7.4). From the File menu, users need to select the Import And Export command. This feature may require additional software on the client computer, such as the program files of Lotus Organizer. For this reason, do not remove the client programs from your users’ PCs until they have migrated their data. You can also use other programs, such as Microsoft Outlook Express, as migration tools.

Figure 7.4 - Importing data into Outlook 2000 and Exchange 2000

Barriers to Migration

Despite the variety of methods you can use to migrate your users and their data to Exchange 2000 Server, there are several barriers to migration. For instance, highly sophisticated workgroup and workflow applications can be a problem because they are not easily ported to Exchange 2000 Server. Application converters, such as the Exchange Application Converter for Lotus Notes, and similar tools may be helpful, but they do not work well beyond standard functionality. Migration of workgroup applications is difficult when they rely on features not directly supported in Exchange 2000 Server, such as LotusScript or external data sources. More often than not, you will have to engage in manual applicationreengineering and workgroup programming in Microsoft Visual Basic. This may represent a substantial issue in the migration process.

Prior to migration, you should create an inventory of existing workgroup and workflow applications, as discussed in Chapter 4, "Assessing the Current Messaging Infrastructure." Evaluate carefully whether these applications are needed in the future messaging environment. Try to port vital applications to Exchange 2000 Server in a test lab. If it is not possible to convert critical solutions with reasonable effort or in a short period of time, consider a multiphase migration and plan for long-term coexistence. Multiphase migration strategies are discussed in Lesson 2.

Encrypted messages that must be decrypted for the purposes of migration pose another problem. Exchange 2000 Server supports advanced security mechanisms based on dual-key encryption technology, but existing security keys, such as those used in Lotus Notes, cannot be migrated. Bear in mind that it is not possible to decrypt old messages with security keys issued in the Exchange 2000 organization. You can read more about the design of a public-key infrastructure (PKI) for Exchange 2000 Server in Chapter 9, "Implementing Security for Hosted Services."

Migrating Special Accounts

Some messaging systems, such as Microsoft Mail 3.5 with Schedule+ 7.0, support special accounts for resource scheduling. Resource accounts may be used for meeting rooms, company cars, and other equipment. The principle is simple: A resource account represents a particular resource and the account’s calendar is used to book the equipment, similar to a meeting. A user who wants to use a particular resource sends a meeting request to the corresponding resource account. According to specified criteria (such as no overlapping meetings) the request is accepted automatically and the meeting or equipment is booked or the request is denied.

Using the Migration Wizard, you can move resource accounts and their calendar data to Exchange 2000 Server. However, this does not imply that the configuration is retained. The wizard has no way to distinguish users from resource mailboxes, for instance. Hence, you need to adjust the configuration manually. You need to grant the user responsible for the equipment Full Mailbox Access rights to the mailbox-enabled resource account in Active Directory, and you need to connect to the resource mailbox in Outlook 2000 to reconfigure it as a resource account. From the Tools menu, select Options. In the General tab, click Calendar Options and then click Resource Scheduling. You need to repeat these steps for all migrated resource accounts.

Developing Single-Phase Migration Strategies

Possibly the biggest challenge in any single-phase migration is end-user training. You may technically be able to move 500 users to Exchange 2000 at once, but itremains questionable whether your users will be able to work with the new client software (Outlook 2000) right away. It is advantageous to train your users on Outlook 2000 before the actual migration takes place. Users who are familiar with the features of Outlook 2000 and already use this client for messaging will find a migration to Exchange 2000 very straightforward. Outlook 2000—as a MAPI-based application—is very flexible and capable of communicating with a variety of messaging systems through appropriate transport drivers, as explained in Chapter 4, "Assessing the Current Messaging Infrastructure."

Another important question concerns whether it is feasible to consolidate messaging resources in the existing environment. For instance, the Migration Wizard works best when the old mail system resides on the same server. Therefore, if possible, move the existing post offices to the Exchange 2000 server for the purposes of a fast migration. Keep in mind, however, that this approach requires additional disk space on the server. If you perform a migration over the network, choose a time when network utilization is minimal, because the migration may negatively affect overall network performance. In any case, you should perform maintenance routines on the mail system that you intend to migrate to avoid problems resulting from corrupted data.

The questions in Table 7.2 help you develop an appropriate single-phase migration strategy for your messaging system.

Table 7.2 Design Questions for Single-Phase Migration Strategies

Questions	Comments
Is it possible to deploy Outlook 2000 prior to the migration?	If your answer is yes, deploy Outlook 2000 and provide end-user training before the production rollout commences.
Do critical workgroup applications exist that require special programming to port them to Exchange 2000 Server?	If this is the case, identify options to migrate the applications or develop a coexistence strategy based on a multiphase migration.
Is it possible to consolidate messaging resources prior to the migration?	The fewer systems there are, the easier the migration. However, consolidation can be as complex as migrating each system individually. Depending on the situation this might be advantageous. Ask your users to move their data into their post offices or mail servers prior to the migration and make sure that all resources are available locally or in the local area network (LAN). Avoid data migration over wide area network (WAN) connections if possible, and perform maintenance and consistency checks prior to the migration.
Does the Exchange 2000 Migration Wizard support the existing messaging system?	As explained earlier, the Migration Wizard facilitates the migration and should be used, if possible. If your system is not supported, consider the development of a custom source extractor, or use another available migration tool. The Migration Wizard help file contains information on how to build a source extractor to create migration files that the wizard can then import into Exchange 2000 Server. Powerful migration tools are also available from third-party vendors.
Do you have sufficient disk space on the server to perform the migration to its full extent?	Keep in mind that the Migration Wizard requires temporary disk space for its migration files, and Exchange 2000 Server stores migrated messages in two locations: databases and corresponding transaction log files. Furthermore, the Migration Wizard is not capable of handling single-instance storage features. That means that a single message instance addressed to five recipients will be copied five times into the Exchange 2000 store. At the minimum, provide three times as much disk space on the Exchange server than the amount of data you plan to migrate. Exchange 2000 databases, transaction logs, and the single instance storage feature are covered in Chapter 10, "Designing Fault Tolerance and System Resilience for Microsoft Exchange 2000 Server."
Do you intend to implement a different naming or address standard in the Exchange 2000 organization?	It is possible to change the standards for directory names, user names, e-mail aliases, and so on. The Migration Wizard allows you to extract directory information in a .csv-based user list file, which you can then modify to implement changes. When you migrate the users in a second step, you can specify the customized user list file to apply the changes to the mailboxes in Exchange 2000 Server. It is also possible to change directory information after the migration using the LDIFDE or CSVDE utilities.
Do you plan to limit the amount of data to be migrated to Exchange 2000 Server?	The Migration Wizard allows you to specify a date range for those messages that should be moved into Exchange 2000 mailboxes. This allows you to clean out old e-mail, reduce migration time, and preserve disk space on the server. However, you should establish a policy for data not being migrated and inform your users of it in advance to give them a chance to print out old messages, private address lists, and other information, such as message processing rules, or to store the data in personal message archives.
Do you plan to port public forums to Exchange 2000 Server?	If so, identify one person to become the owner of all public folders that the Migration Wizard will create. You also have to identify the default permissions that the users will be granted to the public folders, because permission settings are not migrated. You may then need to manually correct the settings afterward.
Do you need to migrate data that is on the users’ client computers?	If so, establish a policy for this data and identify options for migration. For instance, you can ask your users to move the data back into the post offices prior to migration, place the archives on a network share and allow an administrator to perform the client-based migration on their behalf, or let them use a client-based migration tool, such as the Import And Export feature of Outlook 2000 individually. To avoid excessive data transfer over slow connections, remote users can use the Migration Wizard to migrate their data into local .pst files instead of server-based mailboxes.

Note

If possible, avoid changing the display names of your users. The Migration Wizard retains the display name of message originators and recipients in migrated messages. When you change the display names, sender information in migrated messages will be outdated. Replies to migrated messages will then not work without removing the address information from the To line first and specifying the recipients manually.

Developing a Single-Phase Migration Strategy for the Baldwin Museum of Science

The Baldwin Museum of Science was established in 1946 as a private nonprofit organization to help the public understand relationships between science and society. The museum promotes education about all areas of science including astronomy, technology, ecology, natural sciences, and so forth. Visitors have the opportunity to experience science and technology firsthand by experimenting with equipment.

"We are not the largest of our kind," says Shelly Szymanski, Head of Information Technology, "but our permanent and temporary exhibits attract more than 250,000 visitors each year. For a small museum of 420 employees like ours, this is a remarkable success story. Perhaps this is one of the reasons why we received significant donations last year. We finally have the funds to modernize our office infrastructure. Among other things, we already modernized our network infrastructure. We are now on Windows 2000 Server and Active Directory. To make best use of the new technology, we plan to migrate to Exchange 2000 Server as well."

Shelly Szymanski developed the following migration strategy for the Baldwin Museum of Science:

Our current messaging infrastructure consists of two Lotus Domino servers R4.5, which our 420 employees use for messaging and workgroup computing. The small size of our environment allows us to migrate to Exchange 2000 Server in a single step.
We are currently using the Lotus Notes R4.52 client. Our users are unfamiliar with Outlook 2000. We don’t intend to deploy a MAPI transport driver for Lotus Notes, but we intend to familiarize our users with the new messaging client prior to migration. Over the course of two months, we will deploy a test installation of one Exchange 2000 Server with two mailboxes. Users can then use Outlook 2000 to connect to these mailboxes and test the client functionality. In addition, we will train all our users on Outlook 2000 within these two months.
We have developed several simple workgroup solutions based on custom forms. During our two-month trial period, we need to check whether it is possible to convert these applications to Exchange 2000-based solutions. The Exchange Application Converter for Lotus Notes should help us to port these applications.
We are currently using one complex Lotus Notes solution for our user help desk. This is a professional workgroup application, but the vendor already announced availability of a compatible Exchange 2000 version that provides the same functionality. We need to purchase this system and implement it during our trial period to see whether it provides full functionality.
Our current Lotus Notes environment consists of two Domino servers: one running on an IBM AS/400 and one on a Windows 2000 server. We will not consolidate the resources prior to migration. It may be slow, but we will migrate our users over the network, which shouldn’t be a problem. However, we will check the health of our Domino servers repeatedly during the Exchange 2000 trial period and explicitly before we migrate the user data.
We will use the Exchange 2000 Migration Wizard to migrate the user data. The users are responsible for all data that is on client PCs. We will not address any issues related to local message copies.
All our users are in NAMES.NSF, which the Migration Wizard is supposed to handle without problems. To make sure we don’t encounter any problems during the production rollout, we will test the migration during the trial period in a dedicated test lab and check Microsoft’s technical documentation about any possible issues.
We intend to migrate personal messages and calendar information. Lotus Notes doclinks may represent an issue. We will convert any doclinks to RTF attachments because we will not retain our current messaging environment under any circumstances.
The trial period commences in the second quarter of this year. The production rollout will happen on a weekend two months later.

Activity: Developing a Single-Phase Migration Strategy

In this activity, you will develop a migration strategy for a fictitious company that plans to implement Exchange 2000 Server. The company is Coho Vineyard & Winery, which was introduced in Chapter 4.

Tip

You can use Figure B.20 in Appendix B as a guideline to accomplish this activity.

Scenario: Coho Vineyard & Winery

Coho Vineyard & Winery currently uses Alt-N Technologies MDaemon PRO for Windows as their enterprise messaging system, which is a Windows-based messaging system that supports the Post Office Protocol 3 (POP3) and IMAP4. Coho Vineyard & Winery plans to migrate their 250 users to Exchange 2000 Server to implement sophisticated workgroup and workflow solutions. All 250 users work with the same messaging server. It is possible to export recipient information from MDaemon PRO into a text file. For additional information about Coho Vineyard & Winery, see the various activities in Chapter 4, "Assessing the Current Messaging Infrastructure."

It is your task to identify Coho Vineyard & Winery’s options for a single-phase migration.

Currently, Paul West, Information Technology Administrator at Coho Vineyard & Winery, is considering a migration to Exchange 2000 Server in multiple stages. What is the most significant disadvantage of this approach in comparison to the single-phase migration?
Is it possible to migrate Coho Vineyard & Winery’s 250 users in one step?
What would you recommend to facilitate the migration of user data?
Do you need to use the Migration Wizard to migrate the users?
Which is the best approach to transfer the recipient information from MDaemon PRO to Active Directory?

Lesson Summary

The single-phase migration is a very straightforward approach that offers quick results with minimal administrative overhead. It is an ideal way to migrate to Exchange 2000 Server if the number of users and the amount of data in the existing messaging environment is sufficiently small. Unfortunately, this approach does not scale well to hundreds of thousands of users.

The basis of a convenient migration is the Exchange 2000 Migration Wizard, although other migration tools may also be used. The Migration Wizard facilitates the creation of mailboxes for migrated users. It is possible to create user accounts in Active Directory as well. Distribution lists and external recipients, however, must be migrated manually or in a semiautomated way using LDIFDE or CSVDE. The Migration Wizard, nevertheless, is a valuable tool, especially if you need to migrate server-based user data. Client-based user data can be ported using Outlook 2000, for instance. You need to clarify the methods to handle user data in your migration strategy.

Your migration strategy should also address several issues related to preparing the production rollout. At a minimum, you should provide your users with training on the new client software. Ideally, you can deploy Outlook 2000 before the migration date. You may also want to perform maintenance routines on the existing systems prior to migration to minimize the risk of problems due to corrupted data. Make sure the server to which you plan to migrate the data has sufficient hard disk space available. To mitigate the risks involved in single-phase migrations, you should test the entire migration in a lab and possibly in a pilot project. Make sure that the important data and workgroup applications can be ported to Exchange 2000 Server.