As is true when planning the Microsoft Mail Connector, understanding your Microsoft Mail 3.x infrastructure is crucial to planning the migration to Exchange. Additionally, it is just as critical that you understand the Exchange infrastructure you are migrating to. This includes the technical infrastructure and the readiness of the support infrastructure required for maintaining users on a new messaging system.
When you are ready to migrate, you can use Exchange's many migration features that support multiple scenarios for interconnecting to other mail systems. Tools like the Migration Wizard simplify the migration process and ensure a smooth transition to Exchange.
Three strategies exist for the migration of Microsoft Mail 3.x Post Offices to Exchange Server. You will determine the appropriate strategy for your organization based on the readiness of the organization and its users to migrate mail platforms. Before you learn to identify the factors affecting your readiness to migrate, you need to understand the migration strategies available:
Which strategy is best for your organization depends on the readiness of the organization to migrate messaging platforms.
Many factors determine the readiness of an organization for migration. To determine the level of readiness, I use a checklist made up of business and technical factors that impact the readiness of the migration. The significance of the impact varies among organizations depending on the situations they are in. For example, when Software Spectrum rolled out Outlook 97, user training was a significant factor affecting the migration date because the user community was already accustomed to messaging clients.
Use the following list to gauge your level of migration readiness:
Depending on the size of your organization and your human resources department, you may be able to do a one-step migration. This can happen overnight, on a weekend, or during a company shutdown time. If your organization can't tolerate the downtime or doesn't have the resources to migrate everyone in one weekend, phased migration is the best choice.
Instant migration may be better for your organization if your organization meets the following criteria:
One-step migration takes extra planning in the areas of:
Should you choose to go with a single mail provider, such as the Exchange Server, the single provider option provides for these scenarios:
Update the Global Address List and the directory. Mail sent to the old addresses from the Personal Address Books and personal address lists will be returned as nondeliverable (if you delete the old mailbox), or it will pile up in the old mailbox.
If a multi-phased migration is required, you must add the following items to your list of factors that determine the readiness of the organization to migrate messaging platforms:
Multi-Phase Migration/Partial Post Office Migrating everyone from an existing post office at the same time is not always possible. Some users might be waiting for hardware upgrades. Or the migration might be a pilot (test) or a limited rollout. When migrating partial post offices, consider the following facts:
NOTE: The routing changes are required or allowed during a partial post office migration. Mail must continue to be delivered to the mailboxes remaining on the post office.
As a part of your migration plan, you must know how many mailboxes at a time will be migrated to Exchange servers. As a general rule, migrating the entire post office (every mailbox) is easier to plan for, implement, and maintain than migrating a partial post office. However, migrating a partial post office is sometimes necessary, such as during a pilot or limited roll out when the number of users is small and the issues are easier to solve or work around. The following section explains why this is so.
Multi-Phase Migration/Whole Post Office If you migrate every mailbox on a post office, you can maintain the original Network/Post Office/Mailbox format of Microsoft Mail address for each old mailbox as one of the proxy or e-mail addresses of the new mailbox. This has many advantages:
PC Mail Pass-Through Retaining the original e-mail address provides for pass-through from Microsoft Mail (PC) gateways. The Microsoft Mail Connector Post Office must have an access component for the gateway installed. Because the Microsoft Mail-type addresses for migrated mailboxes have not changed, the mail will be routed from the gateway to the Microsoft Mail Connector and from there to the Exchange mailbox.
Not all of these issues will apply to your installation. For all issues that do apply, you will need to understand how they impact your organization.
Personal Address Book (PAB) entries function similarly to replies. For Microsoft Mail (PC) users, their personal address book addresses continue to work for migrated mailboxes because the addresses are the same.
Migrated Personal Address Book entries will work for Microsoft Mail (PC) mailboxes that have not migrated. This means that if you do not update your Personal Address Book with the new Exchange e-mail addresses, some e-mail will still be directed to Microsoft Mail mailboxes that no longer exist. Mail addressed to mailboxes that have since migrated will be routed to the Microsoft Mail Connector. Because the Microsoft Mail Connector does not have a post office configured with that address, it will return the mail as undeliverable. This undeliverable mail can be re-addressed from the Exchange Server's Global Address List and can be delivered normally.
There is no tool that updates the user's Personal Address Book entries as changes are made in the Exchange Server's global address list. To avoid addressing undeliverable mail, users can remove all personal entries of the type MS from their Personal Address Books after the entries have been migrated to Exchange mailboxes.
The Exchange Windows clients can be used as clients for Microsoft Mail (PC) Post Offices. To do so, you must add the Microsoft Mail service provider to the profile. This can be done before migration. It can also be done before or during phased migration. It is important to move users to the new client while retaining the post office infrastructure.
Even if only the clients are migrated to Exchange, they will enjoy all the benefits listed at the end of the previous section. With this strategy, all users will also have a consistent user interface.
To install Exchange client, users need the Profile Wizard. The Profile Wizard is included with the client setup software. The Profile Wizard pulls default information for connecting to the post office from the MSMAIL.INI file.
TIP: To use the Microsoft Mail Post Office, also called the Microsoft Mail provider, you will need to make the Microsoft Mail (PC) provider the default for the client profile, which you do by using the Setup Editor. The Setup Editor allows complete configuration of the Exchange client prior to installation on the user's PC. This is also true for installing the Exchange provider.
After the client software is installed on the user's PC, the user imports the contents of the Microsoft Mail Message File (MMF) file into the Exchange inbox format. If the MMF file is in the post office, the user should move the MMF file to the local disk or a viewable network share before importing the contents. If the MMF file is left on the post office, the contents will be migrated to Exchange when the mailbox is migrated.
After a user begins using Exchange client, there is no easy way to migrate the messages he or she receives to an MMF or mailbag file. He or she can copy the messages to a shared folder and then retrieve them with the old client, but this does not guarantee privacy of the messages.
Having discussed one method for migration to Exchange, we will now discuss migrating the MMF files from Microsoft Mail into the Exchange format. In addition, we will discuss issues associated with upgrading from Schedule+ version 1.0 clients to Exchange Schedule+ version 7.0 clients.
Exchange client users must migrate their mail message files to a personal folder file. When MMFs are stored on a post office, you can use the MMFClean utility to manage their sizes and the ages of messages (how long a message will be kept on file before it is automatically deleted). Personal folder files should not be stored on the post office.
The MMF Migration tool does not delete the MMF when it creates the personal folder file. It also does not move MMF files locally or delete them after their contents are migrated to personal folder files.
Users who switch to the Exchange client must also switch from Schedule+ 1.0 to Schedule+ 7.5. When they run Schedule+ 7.5 for the first time, it migrates their CAL (Schedule+ 1.0 calendar format) file to an SCD (Schedule+ 7.5 calendar format) file.
Schedule+ 7.5 can read CAL, POF (Schedule+ 1.0 post office free/busy times), and SCD files, but Schedule+ 1.0 can read only CAL and POF files. If your users make heavy use of Schedule+, switch everyone over to the new client at the same time. If some people switch to Schedule+ 7.5, the rest will not be able to view their coworkers' calendars or act as their coworkers' delegate.
Microsoft Mail 3.x groups have many limitations once they span Microsoft Mail 3.x Post Offices. For instance, mail sent from one post office to a mixed-member group on another post office is delivered only to the local members of a group. Exchange distribution lists resolve this problem. If you have established successful integration between Microsoft Mail and Exchange, it is beneficial to consolidate the duplicated Microsoft Mail groups to single distribution lists on Exchange in order to reduce the amount of administration during a phased migration.
The Migration Wizard will migrate (copy) Microsoft Mail 3.x shared folders to Exchange public folders with the appropriate permissions assigned as specified in the wizard. Once the shared folder is migrated, there is no way to automatically replicate the contents of Exchange public folders to Microsoft Mail 3.x shared folders. Depending on the migration strategy and the use of Microsoft Mail 3.x shared folders, this could have a significant impact on the readiness of the organization to migrate.
Schedule+ calendar files migrate with the user's MMF files during a migration using the Migration Wizard. When the calendar file is migrated to the Exchange Server, the calen- dar file password is also migrated. Prior to the migration, remind users not to forget their Schedule+ passwords because they will be required to complete the migration.
A three-phased approach is used to simplify the task of migration. Each phase can consist of numerous individual tasks. On a high level, these three phases will apply to any organization. The following sample walks you through the migration process for an actual organization.
Software Spectrum has its headquarters in Garland, TX, and has other offices in Los Angeles, CA and London, England (see Figure 8.1). The two American offices are connected over a T1 line. The headquarters and the London office are connected over a T3 line network that uses X.400 services.
Software Spectrum's e-mail system consists of 10 Microsoft Mail Post Offices: five in Garland, two in Los Angeles, and three in London. In this example, all the PCs are using the Microsoft Mail service and the Windows 95 operating system. This enables Software Spectrum to use the Exchange client with its existing Microsoft Mail Post Offices.
Headquarters installs a Windows NT-based server with Exchange Server. Then, using the built-in Migration tool, the company migrates its Microsoft Mail Post Offices at headquarters to Exchange.
The Migration tool converts Microsoft Mail messages, Personal Address Book data, attachments, private folders, and meeting requests to the Exchange format and creates new accounts on the Exchange system.
At headquarters, they simultaneously start installing the Exchange Server driver on each of the Windows 95-based workstations to access the Exchange Server. Those still using the Microsoft Mail 3.x service can continue to communicate with other users of Microsoft Mail and Exchange, but they lack the enhanced functionality provided by Exchange. (See Table 8.1 for a comparison of Microsoft Mail client versus Exchange client functionality.)
FIG. 8.1 A sample migration that uses the three-phase method.
Installing Exchange Server consolidates the functions of three machines (the two Microsoft Mail post offices and the X.400 gateway) onto one machine. It also adds single-seat administration, connection monitoring, and performance monitoring. Exchange users can use Microsoft Mail 3.x gateways, and Microsoft Mail users can use the Exchange gateways.
After the Exchange driver is installed on all workstations, users in the Garland office have access to the complete functionality of Exchange, including these features:
Exchange users in Garland can continue to communicate with their counterparts in Los Angeles and London. This enables the company to migrate in stages while still enabling all users to:
Feature | A* | B* | C* |
Rich text support | X | X | X |
Auto reply | X | X | |
Access to public folders | X | ||
Flexible views | X | X | |
Delegate access | X | ||
Remote functionality | X | X | X |
Rich searches | X | X | |
Group scheduling | X | X | X |
Easy-to-use forms | X | X | X |
Central forms registry | X | ||
OLE 2.0 | X | X |
*A--Microsoft Mail 3.x client/Microsoft Mail Post Office *B--Microsoft Exchange client/Microsoft Mail 3.x Post Office *C--Microsoft Exchange client/Microsoft Exchange Server
Next, the company installs Exchange Server in the Los Angeles office and combines existing users of the two Microsoft Mail Post Offices on that server.
The organization still uses Microsoft Mail Post Offices at the remote locations. Using the Exchange Server as an MTA between the Exchange Servers and the Microsoft Mail Post Offices offers these advantages:
Software Spectrum also installs Exchange clients on all PCs at the Los Angeles office to access the Exchange Server. At the end of phase two, all users in Garland and Los Angeles have access to the complete functionality of the Exchange system. They can also continue to exchange messages with users in London via the X.400 connector by way of a "pass-through gateway." The Microsoft Mail Connector manages the directory exchange between Exchange and Microsoft Mail during this coexistence phase.
In the final migration phase, the London office installs Windows NT Server and Exchange on both the server and the workstations. This consolidates the Microsoft Mail 3.x Post Office and the Microsoft Mail gateway onto one server. Now users across the enterprise have full use of Exchange's rich functionality and are able to share information with everyone else in their organization at any time.
The company has realized the cost savings of consolidating the functions of nine machines into three, and it has condensed the administration for all three offices onto one Windows NT-based workstation. They have a consistent enterprise-wide messaging and information-exchange system with the features listed here, and they can install additional Exchange gateways to extend these capabilities beyond the enterprise.
By using the three-phase method, Software Spectrum was able to aggressively migrate the Microsoft Mail community one geographic site at a time to Exchange, while providing coexistence services to continue messaging interoperability.
The following sections cover the main elements of Exchange's Migration package. This package allows you to implement Exchange into environments with legacy mail systems. Its tools assist with the extraction of e-mail addresses from the legacy systems and with importing them into Exchange.
Several tools assist with the migration from Microsoft Mail to Exchange. These tools include the functionality to extract mailbox information from the legacy system. In addition, there is a server component called a Microsoft Mail "server" post office. This post office resides on the Exchange Server and can be accessed only by the Exchange and Microsoft Mail MTAs.
There is a Source Extractor for every system such as Microsoft Mail, PROFS, and the like. The Source Extractor extracts users, inboxes, folders, and address books from the source mail systems.
Components of the Source Extractor tool include the directory agent that facilitates the DIRSYNC process via the Exchange Microsoft Mail Server Post Office. Other components include the free/busy connector, which allows for group scheduling information, and the pass-through connectivity, which interconnects with Exchange. The following two components are also included:
The term Connector has taken the place of the Microsoft Mail Transfer Agent (MMTA) in Microsoft Mail. The Connector is the main link between users of Exchange and Microsoft Mail (PC), as well as Microsoft Mail gateways and Exchange gateways. Three components make up the Microsoft Mail Connector:
These components make up the Mail Connector, which allows Exchange users to transparently send and receive messages and files, meeting requests, and free/busy information with users on Microsoft Mail.
The Directory Exchange Agent (DXA) in Exchange enhances directory synchronization with flexible scheduling, better time zone management, and update scheduling. Its multithreaded design improves throughput. Because the DXA includes multiple server support, the directory synchronization load is distributed across multiple DIRSYNC servers for increased reliability and faster response. This reduces address list maintenance, increases security, and assures that updates occur more promptly.
The Schedule+ Free and Busy Gateway enables users who remain on Schedule+ version 1.0 using Microsoft Mail 3.x servers to see free/busy information in the planner view for users who are on the new release of Schedule+ on the Exchange Server computer, and vice versa. The data from each server platform is replicated across the connector and appears to users on the other platform.
Exchange Server offers group distribution list support and enables Microsoft Mail users to send messages to X.400 and SMTP environments through the Microsoft Mail Connector. Messages sent from the Microsoft Mail 3.x users through the Exchange Server computer can use the Exchange X.400 Connector and the Internet Mail Connector to interchange messages with these environments. Alternatively, Exchange users can send messages through any of the Microsoft Mail gateways by way of the Microsoft Mail Connector.
You can use the Migration Wizard to migrate one or more mailboxes on a Microsoft Mail for PC Networks post office or to PST files. Using the Migration Wizard to move user mail, Personal Address Books, and schedule information to a PST file is new to Exchange 5.5. When each mailbox on the post office is migrated, you have a choice of what information to migrate.
The following is a list of available components to migrate into the Exchange environment:
The list covers the components from the actual mailbox containing data to the Schedule+ file and then the group or shared folders and the Personal Address Book entries on a user's local PC. When migrating to PST files, the group or shared folders cannot be migrated.
NOTE: Make sure there is no mail activity during migration. Any mail activity can cause the senders' and recipients' mailboxes to not be up to date at the time of the migration.
You should take the following precautionary measures before migrating in order to ensure safe migration of data:
To create the user list from a Microsoft Mail (PC) Post Office, complete the following steps:
In addition, you can make changes as needed in the user list file. If you need to change the directory name of a mailbox, do it before the mailbox is created. You can change other fields now in this text file, or you can change them later. To change them now, follow the steps in the next section. To change them later, use the Administrator program to change them one at a time, or use the Directory Import command to change them in a batch mode.
To modify the user list file, complete the following steps:
Field | Contents |
SFS_UserName | The mailbox name or alias of this mailbox in the post office. Do not change this. |
SFS_FullName | The full or display name of this mailbox in the post office. Do not change this. |
MigrateUser | "Y" if the mailbox is to be migrated or "N" if the mailbox should not be migrated. |
Obj-Class | Should be "mailbox." Other valid values are "remote" for custom recipients and "dl" for distribution list. |
Mode | Describes what should be done with this object; "create," "modify," and "delete" are valid options. The default is "create." |
Common-Name | The directory name of the mailbox. This can't be changed later without deleting the mailbox and re-creating it, so change it now to match your naming convention. |
Display-Name | The display or friendly name that appears in the address book. |
Given-Name | The first or given name of the mailbox's user. |
Surname | The surname or last name of the mailbox's user. |
Home-Server | The home server of the mailbox. You can move a mailbox within the site later without difficulty, but you should decide where each group of mailboxes is to be created. |
Comment | The address book comment. It can be used to distinguish between two people with the same or similar names or for notes about contacts for Schedule+ resources. |
Assoc Windows-NT Account* | The mailbox's associated Windows NT account that has user access. On a Schedule+ resource account, this can be a Windows NT group or account that is responsible for managing the resource, or it can be the administrator who is going to sign into the account once to set up forwarding rules and Schedule+ access permissions. |
* You can add additional directory import fields after Assoc Windows-NT Account.
After creating the user list and modifying it, you can migrate mailboxes from the post office to your site. This does not delete the mailboxes or remove mail, it only copies the information to the Exchange Servers where the new mailboxes are created. This is covered in the next section.
To migrate mailboxes from a post office to an Exchange Server with a user list, follow these steps:
Option | Description |
Information to Create Mailboxes | Create mailboxes for the selected users in the user list file. |
Personal E-Mail Messages | Copy messages and folders from the selected user's mailbox and server-based MMF. You can select all messages or set a date range. |
Shared Folders | Copy all shared folders to the public folder server. |
Personal Address Books | Copy PAB entries in the MMFs and put into the selected user's inbox in a special message. |
Schedule Information | Copy calendar files from the CAL directory on the post office to a special message in the selected user's inbox. |
NOTE: You cannot move a mailbox from one directory container to another after the mailbox has been created. This is a limitation of the Exchange Administration program.
Option | Description |
Create Accounts and Random Passwords | Accounts are created with names that match Generatethe alias and random passwords. The passwords are written to the file BIMPORT.PSW in the working directory of the Migration Wizard. For users to log on to Windows NT, distribute these passwords to them. |
Create Accounts and Use Alias as Password | Accounts are created with names and passwords that match the alias. |
Don't Create Windows NT Accounts | No accounts are created, and the mailboxes cannot be used by anyone until an account is assigned later. |
To migrate in one step from a Microsoft Mail (PC) Post Office, follow these steps:
Option | Description |
Information to Create Mailboxes list file. | Creates mailboxes for the selected users in the user |
Personal E-Mail Messages | Copies all messages and folders from the selected user's mailbox and server-based MMF. You can select all or set a date range. |
Shared Folders | Check this box to copy all shared folders to the public folder server of this server. |
Personal Address Books | PAB entries in MMFs are copied and put into the selected user's inbox in a special message. |
Schedule Information | Calendar files are copied from the CAL directory on the post office to a special message in the selected user's inbox. |
NOTE: You cannot move a mailbox from one directory container to another after the mailbox has been created.
Table 8.6 One-Step Migration--Options for Users Without Windows NT Accounts
Option | Description |
Create Accounts and Random Passwords | Accounts are created with names that match the Generate alias and random passwords. The passwords are written to the file BIMPORT.PSW in the working directory of the Migration Wizard. For users to log on to Windows NT, you need to distribute these passwords to them. |
Create Accounts and Use Alias Password | Accounts are created with names and passwords that as match the alias. |
Don't Create Windows NT Accounts | No accounts are created, and the mailboxes can't be used by anyone until an account is assigned later. |
As you learned earlier, in the migration tools section of this chapter, MMFs can be migrated by the user to personal folder files or by the Administrator to the private information store (depending on the location of the MMFs). Furthermore, the Exchange 5.5 Migration Wizard allows the administrator to migrate Microsoft Mail Post Offices to PST files. This is useful when users receive the Exchange or Outlook client prior to connecting to an Exchange Server. Two things to note about MMF migration are network errors and what to do after you use the migration tool.
Network Errors If there is a network failure during MMF migration, the client or Migration Wizard retries the network connection every ten minutes to re-establish a connection. An error message is displayed during this retry time.
Any errors during client MMF migration are logged to a file in the client directory with a file name that's the same as the MMF name and an extension of .LOG. You can view them in Notepad or any other text editor.
To import an MMF file with the Windows NT or Windows 16 client, follow these steps:
After Using the Migration Tool Depending on your migration strategy, you will need to delete the Microsoft Mail (PC) mailboxes or hide the post office. Deleting the mailboxes begins the decommission process for Microsoft Mail. The old mailboxes should not be needed anymore because the mailbox has been migrated to Exchange.[dagger]l