8
Moving from Another Mail System
by Dennis Brazil
Moving from another e-mail system is one of the most important tasks you undergo when you're implementing a successful roll-out of Microsoft Exchange. With a proper migration plan and the proper tools, you have more support to help you in winning your proposition to the executive staff to move to Microsoft Exchange as well.
The migration process can be simple as well as complex. The latter is especially true when you consider your current network LAN/WAN infrastructure, the multiple post offices and sites, the multiple flavors of operating systems, maintaining coexistence between systems when migrating a large number of users, and more. Again, whatever the complexity or your current environment, you can successfully migrate to Microsoft Exchange with proper planning and tools. Migration is especially simple when you are only migrating from just one mail server.
In this chapter, you learn about the following:
- How to plan a successful migration
- Existing tools for a successful migration
- Other elements to consider in the migration process
You also consider a specific migration case study: Clarify, Inc.
Planning Considerations and Migration Strategies
When you develop a migration plan to Microsoft Exchange, you need to consider many elements. Before developing a plan, you should have a full map or schema of how your current messaging system looks. A sample map should include all sites in the organization and how they are connected both on the network and application levels, any messaging gateways (such as Internet or Fax gateways), and so on. You also should include an "inventory" of your complete organization structure. This inventory should include your network operating systems (NOSs), a complete list of the different client operating systems involved, the total number of users to migrate, and so on.
A strategy (or plan of attack) should also be part or your plan. It is especially necessary when you're migrating large or complex sites. Although more than one strategy can work for your organization, choose one that not only will suit the organization's needs and current infrastructure but one that also best fits with clients. The satisfaction of the clients will make a difference in the end.
Planning Considerations
When you develop a migration plan, you need to consider the following (where applicable):
- Mailbox naming conventions. When you're migrating users, you might want to change or maintain your standard naming convention for mailbox names and aliases to simplify addressing or otherwise establish standardized naming conventions within your organization. For example, you might decide that all Display Names should be formatted last,first, followed by the department name. If you choose to change your existing naming standard, you might want to perform (what Microsoft calls) a "two-step" migration in the Migration Wizard (see Figure 8.1) for each user or for a group of mailboxes all together. The two-step migration is really three-step migration when you are changing mailbox naming conventions on the fly. The three steps involved are
- Exporting a list of your existing users to an intermediary (text) file
- Modifying the newly created text file to make any naming or address changes
- Importing the modified file into Microsoft Exchange to create the mailboxes within the Microsoft Exchange system
Figure 8.1. Choosing the method of migration in the Microsoft Exchange Migration Wizard
- Distribution lists. Consider whether or not you want to create or migrate distribution lists. You might want to migrate existing distribution lists or create new ones. You might want to re-create distribution lists, for example, when you change mailbox names. Note that if you are performing a multiphase migration (described later in this chapter under "Multiphase Migration"), you should maintain duplicate distribution lists for proper coexistence during the migration period.
- Public folders (shared information). Some messaging systems contain shared information. In Microsoft Exchange, this shared information is stored in public folders. In most cases, you might have to perform the migration process for public folders manually. See Figure 8.2, where this option is selected.
Figure 8.2. Unselecting the Shared Folders migration option in the Migration Wizard. This is unselected during a mailbox migration because the folders will be moved separately using the Migration Wizard.
- Multiple post offices or sites. All sites and post offices must be considered as part of the migration. When multiple sites are involved, the multiphase migration method is recommended unless each site is properly staffed for migrating all sites at once.
- Gateways. You should consider migration of external mail gateways as part of your migration plan. Exchange Server, for example, has optional x.400 and Internet (SMTP) connectors. If equivalent gateways exist on your current messaging system, consider them in your plan. Although a limited number of connectors are developed at this time by Microsoft, a multitude of third-party developers are developing other gateways and connectors for faxing, cc:Mail, MHS, Newsgroups, and so on. You can find a list of third-party software add-ons in Chapter 24, "Third-Party Add-On Products."
- Coexistence. When you're performing a multiphase migration, you should consider coexistence between systems to minimize any downtime for mail delivery. Sample connectors to help you maintain this coexistence are the MS Mail connector, x.400 connector, and Internet Mail connector. See Chapters 7 through 11 in the Microsoft Exchange Administrator's Guide to learn how to take advantage of these connectors before, during, and after migration to Exchange.
- Client software installation and upgrades. You also need to develop a schedule and plan for installing and upgrading client software. You might want to install client software first and then migrate mailboxes, first migrate and copy mailboxes and then migrate the clients, or perform the migration on the server and client in unison.
- User education. Before you perform any migrations, you should inform users of the following:
Method of Migration. You should inform users of the migration method you are using and why. This way, they will understand why a message is possibly not reaching a recipient on a foreign or coexisting system.
Migration Schedule. This schedule should consist of which offices, users, and gateways are migrated and in which order.
List of possible obstacles and how to overcome them. And effective method I used with my users is a FAQ (Frequently Asked Questions) list with answers to each of the questions on the list. You can find a good source of FAQs on Microsoft's KnowledgeBase. You should tailor this list to fit your organization.
- Contingency planning. You must always consider plans for failure when migrating between systems. Your contingency plan should include the following:
Hardware failures. Hardware failures can include a variety of components. Examples are modems, RAM, monitors, keyboards, hard disks, and so on.
Network failures. Most likely, you will be migrating between systems over a local area network (LAN). You might want to coordinate with your network manager to ensure that no network downtime is scheduled at the time of your migration. Also check his or her availability during migration in the event of a network failure.
Power failures. Although Exchange Server utilizes a sophisticated database architecture to prevent database corruption in the event of a power failure, a power failure in the middle of a migration can cause physical disk media failure. The best insurance against power failures are uninterruptable power supplies (UPSs). UPSs maintain power to the system when the lights go out, which can enable a migration or any deliveries to complete. You can then gracefully shut down the server if power is not expected to be restored any time soon.
Resource limitations (both human and hardware). Humans can also create problems during a migration. If you have a migration team in place, one or more of your members can be absent for any given reason. To help alleviate problems in this situation, try to have backup team members available.
Backup and recovery procedures. After you successfully migrate a number of users, an Exchange Server can crash or become unavailable. Provided that you have proper backup and recovery procedures in place for your existing system, you can recover the old mailboxes.
Migration Strategies
The following sections cover the different methods you can use to migrate your users.
Single-Phase Migration "Cut-Over" Method
A single-phase migration consists of migrating all users at once. You should use this migration strategy if you meet any of the following criteria:
- You have enough resources in the given amount of time to migrate all information (possibly over a weekend or holiday).
- You have little or no data to move from an existing messaging system.
- All clients have already been upgraded, and the Exchange Server and connectors are set up and in place. (Only mailboxes are left to be migrated.)
- Coexistence cannot be achieved between the existing messaging system and Microsoft Exchange.
This method is straightforward and easy. Using this method, you can avoid coexistence issues between foreign messaging systems.
Multiphase Migration
A multiphase migration consists of migrating users in phases. This migration is very complex, and much more planning is needed. You should use this method when you meet any of the following criteria:
- You do not have enough resources to migrate all users using the single-phase migration with minimum downtime.
- Not all users or offices are available to be migrated in one phase. You might, for example, have remote users and offices that cannot be migrated simultaneously.
- Coexistence is required. When you perform a multiphase migration, the existing messaging system and Microsoft Exchange must coexist. Coexistence between systems includes the following:
Transparent mailbox directories. Directories on both the existing messaging system and Microsoft Exchange should be synchronized. Depending on your messaging system, you might have directory synchronization between the systems performed automatically or manually updated on a periodic basis.
Updated mailbox routing information. When you have a large messaging system with multiple post offices, you might want to migrate users from one post office at a time. Upon completion of migrating a whole post office, you must update routing information between post offices to ensure proper mail delivery. Routing information also includes routes through gateways (described next).
Gateway pass-through support. Provided that proper connectors are in place for the existing messaging system, Microsoft Exchange users can send and receive mail through the existing system's gateway(s). By using this method, however, you are delaying the inevitable migration of those gateways to Microsoft Exchange. If equivalent gateways exist for Microsoft Exchange, you should point all userseven those still on the existing systemto the gateways or connectors in Microsoft Exchange early on in the migration.
Although you can connect to other systems on the server end, the Microsoft Exchange client also supports more than one transport. Microsoft calls its Exchange client the universal inbox and can be proven so by loading more than one provider on the client end. See Figure 8.3 to see how multiple services are loaded into the client. You can learn more about this process in Chapter 12, "Configuring Microsoft Exchange Clients."
Figure 8.3. Example of multiple services loaded in the Microsoft Exchange client.
If no connectors for your messaging system exist for Exchange, you're not completely out of luck. If your messaging system has x.400 or SMTP gateway support, you can still achieve coexistence between the two systems. You can connect the two systems by taking advantage of Exchange's x.400 or Internet (SMTP) connectors. This method, however, requires one more step to achieve total coexistence: You must update the global address directories manually as you migrate users between systems.
Multiphase Migration Approach: Top-Down or Bottom-Up?
When you're considering multiphase migration for multiple sites, you must also consider the migration approach. Doing so is useful when a large or complex hierarchy exists in your messaging infrastructure. The two approaches are as follow:
- Top-Down approach. Migrating using the top-down approach consists of migrating parent servers first and then migrating the child servers. If you use this approach, the first server or post office to be migrated is the "root" or headquarters post office.
- Bottom-Up approach. This approach is simply the opposite of the top-down approach. You first migrate the child post offices and then work your way up.
No matter which approach you take, coexistence should and must be maintained to minimize end-user confusion.
Mailbox Migration Levels
When you are migrating mailboxes, you have to decide if mailboxes and their contents can be completely migrated and cut over to Microsoft Exchange, if new mailboxes should be manually created, or if users must maintain access to mailboxes on both the existing system and Microsoft Exchange.
- Coexistence. When you are migrating mailboxes, you might need to maintain coexistence of user mailboxes between the existing mail system and Microsoft Exchange. Because the Exchange client can be used as the universal inbox, for example, you could load the Exchange Server, Internet Mail, and the Microsoft Mail providers. This enables the client to access Internet mail (via an SMTP/POP3 server, a Microsoft Mail post office, and Microsoft Exchange Server all at once).
- Mailbox and contents migration. This method of migration is the process of migrating both the mailbox properties as well as it contents (messages, folders, attachments, and so on). You can easily achieve this by using the Migration Wizard. Although the Wizard migrates only cc:Mail and Microsoft Mail automatically, you can perform such a migration from other systems as well as using a more manual method. You can achieve this if you have a source extractor that extracts the mailbox information and contents to a format in which the Migration Wizard can read.
- Mailbox migration only. In this process, you migrate only the existence of the mailbox without its contents such as messages, folders, attachments, and so on.
- Mailbox creation with data migration. For whatever reasons, you might want to create mailboxes manually and then migrate the contents of the existing mailbox to the new mailbox. You might want to use this approach if you are modifying your mailbox naming conventions.
- Mailbox creation without data migration. In this process, you create mailboxes manually and do not migrate mailbox contents. You use this approach when you do not have any migration tools in place for your existing mail system.
- All the above. You can combine any of the preceding methods that best fits your clients' needs.
Tools for a Successful Migration to Exchange
The following sections describe the different Exchange migration tools you can use.
Migration Wizard
The Migration Wizard is a program made to import directory, message, schedule, and shared folder information. Although the Migration Wizard can import all this information, not all this data can be exported from all messaging systems. When starting the Migration Wizard (located on the Exchange Server), you can choose to migrate from three sources: Migration files created by a source extractor, MS Mail for PC Networks, and Lotus cc:Mail. See Figure 8.4 to see what the selection of the migration type looks like in the Migration Wizard.
Figure 8.4. You use the Migration Wizard to choose the type of migration.
- Import Migration files created by a source extractor. Migrates from files created by a source extractor. These files contain data from a foreign messaging system and are in a standard format understood by the Migration Wizard. Source extractors are explained in greater detail later in the chapter.
- Migrate from a Microsoft Mail for PC Networks. Migrates mailboxes, messages, attachments, scheduling data, personal address book (PAB) entries, and shared folders from an MS Mail for PC Networks post office.
- Migrate from a Lotus cc:Mail Server (for database version DB6). Migrates mailboxes, messages, attachments, and public bulletin boards from a Lotus cc:Mail post office.
Scheduling information stored using Lotus Organizer can be imported directly from Schedule+ on the client computer. Figure 8.5 shows most of the import options in Schedule+.
Figure 8.5. Select file type for import into Schedule+.
Source Extractors (for Import By the Migration Wizard)
Microsoft defines source extractors as utility programs that copy mailbox information from an existing system. The source extractor copies messages, attachments, personal address books (PABs), and schedule information from the server. This copied data is output to three separate migration files. In the following sections, you explore further how these files should be formatted for creating custom source extractors for importing to Microsoft Exchange via the Migration Wizard.
Extractors Included with Microsoft Exchange
The following are sources extractors included with Microsoft Exchange:
- Microsoft Mail for AppleTalk Networks (now known as Quarterdeck Mail), version 3.x
- Microsoft Mail for PC Networks, version 3.x (via the Migration Wizard)
- Lotus CC:Mail, database version DB6 (via the Migration Wizard)
- Verimation MEMO MVS version 3.2.1 (or later)
- IBM PROFS/OfficeVision, all versions
- DEC ALL-IN-1, versions 2.3 or later
When you perform the two-step migration with the Migration Wizard, it creates the three required packing list files: XXX.PKL, XXX.PRI, and XXX.SEC. For a description of these files, see "Creating Your Own Source Extractor," later in this chapter.
Although Exchange comes with all the extractors listed here, the most common migrations occur with Microsoft Mail for PC Networks. Also included is a case study, with a case study of Clarify, Inc.
Creating Your Own Source Extractor
You might want to create your own source extractor if none exists for your messaging system. I must warn you, however, that it can be a lengthy and difficult task to undertake. It requires planning, and can potentially require extensive programming and testing, although your current messaging systems might also have utilities to export mailbox information to a file format that can be modified using a tool such as Microsoft Excel and then imported into Microsoft Exchange.
If you are importing mailbox information only to create users without needing to migrate additional objects (such as messages, attachments, personal address books, and so on), then you should use the Directory Import/Export method. See "When to Use the Directory Import Feature" section for more details.
The Migration Wizard requires three files to import data created by a source extractor:
- Packing list file (*.PKL): This code page file contains filenames and other information about the primary and secondary intermediate files.
- Primary intermediate files (*.PRI): These files contain mailbox or custom recipient names (which should be unique), message headers (with pointers to message content and attachments in the secondary intermediate file), and personal address book entries.
- Secondary intermediate files (*.SEC): These files contain the message bodies (of the message headers in the corresponding .PRI file), message attachments, and scheduling data.
All three source extractor files must reside in the same folder or directory.
Upon migration of files from a source extractor, both the schedule and PAB data are transformed into mail messages to the mailbox created by the Migration Wizard. The schedule file is stored into a message as a Schedule+ file to be imported into Schedule+ by the user at a later date, and the PAB entries are stored as a file attachment in a comma-delimited format to be imported into the user's local PAB file.
Figure 8.6. Information to import from a Source Extractor using the Exchange Migration Wizard.
You can find complete specifications for creating a source extractor in the "Migrate" folder in the Exchange Server CD. Other recommended reading is Appendix B of the same "Migrate" folder of the CD, "Creating a Source Extractor."
Exchange Server Administrator (Directory Import and Export)
By performing a directory import, you can add or change the directory objects that consist of the following information in the Exchange Directory:
- Mailbox information (including custom recipients)
- Public distribution lists
- Public folders
Figure 8.7. Example configuration of the Directory Export feature.
When to Use the Directory Import Feature
Using the Directory Import/Export feature is a great way to make system-wide changes to mailbox naming conventions. Before importing mailbox information, you can modify the file to be imported using a plain-text editor (such as Notepad or Write) or even a spreadsheet program such as Microsoft Excel. Using Microsoft Excel is a great way to make mass changes by way of using macros or formulas.
- When converting network account names as the basis for Exchange mailbox names. You can automatically create Exchange mailboxes from existing network accounts in Novell Netware, Windows NT, or Banyan Vines by using tools provided with Exchange. (For more information about extracting account information from other network systems, see the Exchange Administrator's Guide.) Figure 8.8 shows a screen with entries for extracting Netware accounts.
Figure 8.8. Extracting user accounts from a Netware Server using the Exchange Administrator program.
- Auto-creating a batch of custom recipients that contain mailbox addresses for users of external mail systems (such as SMTP or X.400 addresses). In Microsoft Mail, you can set up external addresses (such as SMTP or X.400 gateway addresses) to be included in the Global Address List. These addresses can be exported to a file to be imported as custom recipients.
- Importing information from other databases to auto-fill in extraneous mailbox information. Examples of information you can import include job titles, addresses, phone numbers, and other custom attributes.
Migration Case Study: Clarify, Inc.
Clarify provides the industry's most comprehensive suite of client/server software for enterprise sales and support solutions. Clarify's products integrate the key components of customer interaction: sales and marketing, customer service, problem resolution, field service, logistics, defect tracking, and help desk applications.
Clarify currently has approximately 350 employees throughout the world. Before migrating to Microsoft Exchange, Clarify runs one Microsoft Mail post office for the whole organization. All remote users in remote offices do not have their own post offices yet. Therefore, they currently dial in to the headquarters to send and receive e-mail.
Clarify also sends Internet mail, using the Microsoft SMTP Gateway, forwarding all mail to a "smart host." In return, this smart host acts as a liaison between the Internet and the MS Mail post office.
Because I am currently dealing with just one post office, the migration path will be relatively simple. What follows is a simple sequence of events that occurred to move Clarify to Microsoft Exchange successfully.
- Set up Exchange Server.
- Create sample clients on Exchange Server.
- Test mail delivery between Exchange mailboxes.
- Install MS Mail connector.
- Change the MS Mail post office to be a DirSync Requestor. This enables directories on both systems to be up-to-date.
- Set up the Directory Synchronization Server on Exchange.
- Set up Remote DirSync Requestor on Exchange.
- Perform directory synchronization (ensure that all names from MS Mail were brought over and vice versa).
- Test mail delivery between the MS Mail post office.
- Install the Internet Mail Connector (IMC).
- Test sending mail through the IMC. Note: Only Exchange users are sending Internet mail via the IMC at this time. MS Mail users are still using the SMTP Gateway for MS Mail.
- Migrate over the IS Team for pilot.
- Upon approval of the first pilot, migrate over two more departments (a total of 10 to 20 individuals).
- Convert all users (including MS Mail users) to using the IMC instead of the SMTP Gateway. This step involved setting up the SMTP Gateway access component (not the server component) and pointing it to the "shadow PO" on the Exchange Server.
- Shut down the SMTP Gateway.
- Migrate all users at headquarters to Exchange.
- Send diskettes to all remote users, and migrate on a scheduled basis.
Here are some notes on the migration:
- E-mail account migration. After an account was migrated over to Exchange, the MS Mail account was removed. Using this cut-over method, the user did not have to deal with two e-mail accounts. Although the Exchange client can support more than one information service in its universal inbox, I didn't want the headache of having to have to go back and have all the clients remove the MS Mail post office from their profiles after I shut it down.
- Remote users. Remote users have to re-download the global offline address list periodically because the e-mail addresses are changing as the migration is occurring.
- Replying to migrated users. All users can have trouble "replying" to users who have since migrated. No doubt, you will have users receiving Non-Delivery Reports (NDRs). When you reply to a message from a user who has since migrated, the message replies to the old e-mail address! You must therefore reselect the user's name from the newly updated Global Address List.
- Client migration types. Most all of Clarify's users were already running the Windows 95 version of Exchange client. Migrating these clients was relatively easy, but personal information stores and personal address books had to be re-added into the profiles.
- Schedule and personal information store passwords. After clients were migrated, they tried to load their Schedule+. Lo and behold! Some of them were required to type a password to open up their shared schedule files. Most clients did not remember that they had passwords on these files since their Exchange passwords were cached. The usual password to unlock the file was the previous password set in MS Mail. Tip: Clear out the passwords from the file before migration.
- Directory synchronization. No matter how many post offices you have, the Directory Synchronization Server should always run on Exchange Server. It is easiest to set up and to maintain.
- IMC and a smart host. Because all internet mail is transferred through a UNIX smart host, Clarify must maintain two SMTP addresses for each user: one for receiving from the smart host and one for sending out as the reply-to address. When mail is received for dbrazil@clarify.com, to the smart host, it has a mapping to forward the mail to dbrazil@hqpo. hqpo is the name of the Exchange Server. For Exchange to know what to do with the received e-mail, dbrazil@hqpo must be in the E-mail Addresses tab of the mailbox for dbrazil. If you do not put another e-mail address as dbrazil@clarify.com and set it as the reply-to address, then the reply-to address will be dbrazil@hqpo. Users from another domain on the Internet will not know that dbrazil came from clarify.com. See Figure 8.9.
Figure 8.9. Sample Internet Mail connector configuration to allow mail incoming from a smart host that processes incoming Internet mail.
- Personal address books and personal distribution lists. As users are migrated, personal address books and distribution lists have to be updated by the users. They can re-create the lists by picking from the Global Address List.
- Reselecting a schedule file. When you upgrade a client, the link from schedule file to Schedule+ is lost. To reestablish this link, start the new Schedule+. When you are prompted for a schedule file, choose an existing schedule file.
Figure 8.10. Sample dialog box that shows up when you start Schedule+ after reinstalling the Microsoft Exchange Client.
- Schedule permissions. As accounts are moved to Exchange Server, their links are severed in the Schedule permissions page. You can find this page by choosing Tools | Access Permissions (see Figure 8.11).
Figure 8.11. Setting up the Schedule+ permissions for user access to the user's schedule.
Summary
Even though no two mail systems are configured exactly the same, there is a wealth of information at your disposal. Microsoft also includes various utilities in Microsoft Exchange to help make your job as the administrator easier to migrate from another mail system.
Along with the Exchange Server online documentation, you can also find more information from the following sources: