Migrating Microsoft Mail Gateways to Exchange Server

Migrating from Microsoft Mail (MS Mail) to Microsoft Exchange Server involves several distinct operations. You must move MS Mail mailboxes to Exchange mailboxes; preserve mail contents; handle midmigration, coexistence, and interoperability issues; and replace legacy gateways with Exchange connectors. In this article, I'll focus on the last point, because if you know that your inbound and outbound Internet messaging is secure, you can begin to consider the other issues in user migration.

In my strategy, the first production use of Exchange is as the gateway to external mail systems and as an inter-MS Mail post office Message Transfer Agent (MTA). I'll describe migration tactics and procedures for replacing a third-party Simple Mail Transfer Protocol (SMTP) gateway with the Exchange Internet Mail Service (IMS), and for reconfiguring MS Mail post offices to use Exchange services.

Set Up Gateways First
If you're going to replace your mail system with Exchange Server, you'll want to replace your Internet mail host with Exchange IMS. The IMS offers many advantages over most legacy SMTP gateways, including better control over unsolicited commercial email (UCE), SMTP ETRN-command support for Internet Service Provider (ISP) dequeuing, faster performance, centralized administration of email addresses, tight integration with NT's Event Viewer and Performance Monitor, and detailed message tracking.

Introducing the IMS as the first production Exchange Server component makes both practical and political sense. It's practical when you consider the alternative: migrating users to Exchange and maintaining interoperability with the legacy SMTP gateway. Implementing the IMS early is a good political move, too, because it can provide an immediate benefit that can balance any unpleasantness resulting from a large migration. Even if you have to delay the transition to Exchange because of necessary network upgrades or if users have problems with calendar synchronization between the old and new systems, they'll still thank you for the improved Internet mail services.

Enhance MS Mail Delivery
To direct outbound mail from a post office to Exchange, you must alter the inter-post office configuration so that the Exchange MS Mail Connector MTA delivers mail bound for the Internet. For inbound Internet mail, you need to add addresses to the Exchange server that identify how to route incoming mail to your domain to users on your MS Mail post offices.

Before you start migrating MS Mail users to Exchange for message storage, make these configurations:

Note that this setup involves work on both the Exchange server and the MS Mail post offices. After the migration, the Exchange configuration will provide inter-post office message transfer services and Internet delivery for MS Mail users.

Configure the Exchange MS Mail Connector
To set up the Exchange MS Mail Connector with the Exchange Administrator, you must add connections to the individual MS Mail post offices and create at least one MS Mail Connector MTA instance to service them. A Connector MTA instance is an individual Windows NT service that queues and transfers mail between Exchange and MS Mail.

Defining the MS Mail Connector also creates a shadow post office on the Exchange server—a local post office nearly identical in structure to a native MS Mail post office. When you reconfigure SMTP handling on the MS Mail post offices, these post offices will use this shadow post office as the upstream post office for Internet mail delivery.

For this discussion, assume that you're using Exchange Server to connect eight post offices to the Internet and to one another. The post office servers reside on the same LAN/WAN and are named POSVR01 through POSVR08. You can create one Connector MTA instance to service all eight post offices. If you had a few more post offices, you might distribute the message transfer load across two or more Connector MTAs. In a complex environment, many rules influence the optimal ratio of Connector MTA instances to MS Mail post offices, including the mix of LAN, asynchronous, and X.25 connections. For LAN connections, keep this ratio lower than 1 to 8 to optimize performance.

First, create the post office connections. A post office connection is a defined network path specified with a Uniform Naming Convention (UNC—e.g., \Myserversharenamemsmailpo). You must define a path to each production MS Mail post office. Using Exchange Administrator,

To configure an Exchange MS Mail Connector MTA,

The default Exchange shadow post office and network names are cryptic permutations of the Exchange site name. You can change them to more meaningful names, such as Exchange1/ExchPO1. To change the names,

Connect MS Mail Post Offices to Exchange
After you configure the Exchange MS Mail Connector to connect to MS Mail post offices, you must configure each post office to connect to the Exchange shadow post office. Follow these steps:

Reset the MS Mail SMTP Gateway Access Component
To send Internet mail through the Exchange IMS, you must reinstall the MS Mail SMTP Gateway Access Component on each MS Mail post office. The SMTP Gateway Access Component tells the post office which upstream post office will deliver Internet mail.

When you reinstall this component, specify the Exchange shadow post office (EXCHANGE1EXCHPO1) as the destination for SMTP messages. The Exchange MS Mail Connector will then forward mail from the shadow post office to the Exchange IMS for delivery to the Internet.

If you can preserve the legacy SMTP gateway during migration, it will continue to deliver inbound mail until a Domain Name System (DNS) update alters the destination of mail addressed to a domain. You can set up the system for outbound Internet mail delivery through the new Exchange gateway before you request the DNS update. You can monitor the new gateway (and possibly a new Internet connection) and tune it for efficiency and reliability while it is responsible only for outbound mail. When the new configuration proves reliable for outbound mail, you can issue a DNS update to direct mail to the computer running the Exchange IMS.

This conservative approach isn't essential, and it might even create other problems. For example, each Exchange recipient's reply SMTP email address must be a valid address in the legacy (inbound) Internet mail gateway. Updating the Exchange directory with specific reply addresses is not difficult, but many factors will influence how incrementally you can afford to migrate to the new SMTP gateway.

Configure MS Mail to Route Mail Through Exchange Server
Exchange can also serve as the MTA for mail messages sent between MS Mail post offices. The nefarious DOS External program typically provides this delivery service, so users are likely to notice the improved speed and stability in MS Mail and Internet mail delivery when you replace External.exe with Exchange.

To route inter-post office MS Mail through Exchange, use the MS Mail Administrator program to define all network connections between post offices as indirect via the Exchange Shadow PO. First, attach to a post office server and delete the existing connections to all external post offices, and then re-create the connections. Run admin.exe on the first post office (MailPO1). Select External-Admin, and click Create. Select an external post office (e.g., MailPO2), route type (Indirect), and network name (Exchange1), and enter the post office name ExchPO1.

For each MS Mail server, use admin.exe to remove existing external connections. Start by running admin.exe from a command prompt with M mapped to the post office path on MS Mail server POSRV01. Enter the administrator's mailbox name and password, select the External-Admin menu, and click Delete. Enter MSMNET as the network name and MailPO2 as the post office name. Repeat this process for all other external post offices (MailPO3 through MailPO8).

Next, re-create the inter-post office connections. Run admin.exe on the first post office (MailPO1). Select External-Admin, and then Create. Select an external post office (e.g., MailPO2), route type (Indirect), and network name (Exchange1). Repeat for all other external post offices (MailPO3 through MailPO8). Rerun admin.exe, and repeat the process for all other MS Mail servers and post offices.

General Gateway Considerations
You might need to remove some dependencies between post offices before you change external mail routing. For instance, if you configure an SMTP Gateway Access Component on MailPO2 to send Internet mail via MailPO1, you can't remove the indirect route via MailPO1 until you remove the old SMTP Gateway Access Component on MailPO2. You might have other gateways (e.g., a gateway for Global MHS mail) that impose this sort of dependency, too. Moreover, some gateway setup programs have bugs, which can complicate a gateway conversion. For example, the uninstall process of the AT&T Gateway Access Component (which is an enhanced SMTP Gateway Access Component) fails to remove the component completely.

Two important things to remember: Scour the Microsoft Knowledge Base and other sources to identify known problems with your particular gateway. And estimate the downtime needed for your conversion, and then double it to accommodate any potential glitches.

Configure Exchange for Directory Synchronization
Before an MS Mail user can receive Internet mail via Exchange, a Custom Recipient designating the user's MS Mail and SMTP email addresses must exist in the Exchange Directory. You can use Exchange Administrator to maintain email addresses manually, or you can configure an Exchange server as an MS Mail Dirsync Requestor to simplify address maintenance. (Exchange can replace an existing MS Mail Dirsync Server, but right now, your main task is to populate the Exchange Directory to accommodate MS Mail Connector services.) Look for future articles about Exchange Dirsync services and email address maintenance.

Customize Your Migration
Migrating gateways from MS Mail to Exchange presents both technical and planning challenges. No two networks are alike, so you need to scrutinize migration recipes and customize them to fit the needs of each enterprise. These technical tips and planning suggestions supplement the advice found in guidebooks and the Microsoft Knowledge Base. However, experience proves that you can't have enough information when you're embarking on a system migration such as one from MS Mail to Exchange Server.