Migrating from MS Mail 3.2/SMTP to MS Exchange Server

One leading reason many companies are considering migrating to Microsoft Exchange Server (Exchange) is its extensive enterprise email capabilities. Microsoft and many Solution Providers are betting that you, too, will soon choose Exchange, and they're plying you with migration guides and educational seminars. This documentation, however, has failed so far to provide a smooth, reversible method of migrating from a Microsoft (MS) Mail 3.2 system with an SMTP gateway to an Exchange server system.

Based on my experiences at Advanced Paradigms, Inc., I have assembled a much needed trial kit for migration to Exchange. The kit should help you attain the most important goal in your migration: transparency to mail users inside and outside the organization. In particular, once your MS Mail 3.2/Exchange hybrid system is in place, a user inside the organization should be able to check the Global Address List (GAL) and send mail to a fellow user on the list--without caring or even knowing if that user is on the current MS Mail 3.2 system or a new Exchange server system. In addition, users outside the organization should always be able to address inside users as [email protected]. Besides providing smooth, transparent migration, the trial kit has another advantage: You can go back to the status quo almost instantaneously at any stage.

MS Mail and the Internet
To get the best results from the kit, you first must understand three things about how your MS Mail 3.2 system works with the Internet: the setup of your SMTP gateway, the flow of mail via the Internet from one user to another, and the role of the Domain Name Server (DNS).

To understand how your SMTP gateway was set up, first examine your network configuration. Your configuration is likely to match one of the scenarios in table 1. Underlying all these scenarios, of course, is a common network architecture, shown in figure 1. I have tested the tool kit with a fairly simple network configuration (scenario 1 in table 1) and can best describe the tool kit's implementation under that configuration. But you can easily adapt the tool kit to other configurations.

With a simple network configuration, understanding your SMTP gateway's setup is a matter of examining two records that the Mail Administrator originally created: the maildatasmtplocal.cfg record and the

maildatasmtpaddr_map.cfg record. The local.cfg record points to the IP address of the mail daemon (typically a Sendmail host) of your contracted Internet Service Provider (ISP). At our site, for example, local.cfg contained the entries shown in figure 2, record 1. Our SMTP gateway is the host smtpgate.paradigms.com (204.241.136.6), and it routes all its outbound SMTP mail to a Sendmail host (38.8.4.2) at our ISP, Performance Systems International (PSI).

The addr_map.cfg record specifies the mappings of the Internet addresses for the postoffice. At our site, addr_map.cfg contained the entry shown in figure 2, record 2. This record lets the SMTP gateway route inbound mail addressed to [email protected] to that user's inside address, communicat2maxuser. This record also lets the gateway sign outbound mail from communicat2maxuser as coming from [email protected].

To understand the flow of mail through the gateway, work through mappings. For example, let's say user Spyros on our system sends a message to a colleague, [email protected], via the Internet. Spyros's MS Mail client saves the message in the mbg directory of his postoffice, the SMTP gateway's inbox. At this point, the message is in MS Mail 3.2's proprietary format and has the communicat2maxspyros signature. When the SMTP gateway polls its inbox, it reads and encapsulates the message in a standard SMTP message format, addressing the result to [email protected]. The SMTP gateway then reads addr_map.cfg, finds that communicat2max should be translated to paradigms.com, and signs the outgoing message as coming from [email protected]. Finally, the gateway forwards the message to PSI's Sendmail host.

If Chris replies to the message, the reverse happens. When a message addressed to [email protected] hits our SMTP gateway, the gateway looks again at addr_map.cfg and sees that paradigms.com is really a destination MS Mail 3.2 knows as communicat2max. The gateway then reformats the message for MS Mail, addresses it to communicat2maxspyros, and writes it to Spyros's inbox in maildatambg. Now Spyros can see the message in his MS Mail client.

Your application of the trial kit must fully account for such mapping within your network configuration. But how does the message from [email protected] find its way back to our gateway? To answer this question, you must understand the role of the Domain Name Server (DNS), which you see in figure 3.

When Chris sends a message over the Internet to [email protected], Chris's mail system (on Forthnet) has to locate the mail host for paradigms.com. The system assigns the question to a Domain Name Server on its own network (139.91.1.17). Forthnet's DNS determines that PSI's host (192.33.4.10) is running a DNS for paradigms.com. When Forthnet's DNS asks, "who handles mail for paradigms.com," PSI's DNS searches for a mail exchanger (MX) database record for paradigms.com and comes up with our host, smtpgate.paradigms.com. The Berkeley Internet Naming Daemon (BIND)- compliant record in PSI's DNS configuration file will look like the entry in figure 2, record 3.

When Forthnet then asks PSI's DNS "who is smtpgate.paradigms.com?" PSI's DNS looks for an address ("A") record for smtpgate.paradigms.com and returns the IP address 204.241.136.6. The BIND-compliant record in PSI's DNS is similar to figure 2, record 4. After Forthnet forwards Chris's message for [email protected] to our SMTP gateway, the gateway's screen shows the contact from Forthnet (see figure 4, listing 1).

Your application of the trial kit must mimic the work DNS performs in your network configuration. In a multiple-postoffice configuration (scenario 2, table 1), you must consider that the database on your ISP's host contains MX records for each of your postoffices and that your SMTP gateway's addr_map.cfg file, obviously, has one entry per postoffice (see figure 2, record 5). For a multiple-postoffice configuration containing a Local Smart Host (scenario 3, table 1), you must also consider that your ISP's database contains an MX record pointing to your local Sendmail host and MX records for your postoffices. And you must remember that your Sendmail host probably re-addresses and routes mail to your SMTP gateway.

Migration Strategy for SMTP Users
To help you achieve the truly transparent migration, the trial kit lets you set up a pilot project first and test your configuration before going live. One obvious prerequisite is to install Exchange. Afterward, create an organization name, a site name, and a connector postoffice name. For our mail system, we created an organization, API (Advanced Paradigms, Inc.), and a site, Alexandria, with a connector postoffice, apicomm.

During the pilot project, you will have an Exchange server, a test MS Mail 3.2 postoffice, an SMTP/POP3 server and DNS, and clients on all three mail systems. Figure 5 shows a pilot configuration that lets you set up and test the Exchange server, the Internet Mail connector, the MS Mail connector, and the addressing schema. Once you determine that all components are working correctly, you can go live within five minutes--and go back to your previous configuration in less than five more minutes if you determine that something has gone wrong!

The procedure to test the configuration and move into production is as follows.

Phase I ­ Model the Internet. By setting up an SMTP/POP3 server and a DNS, you have a model of the Internet against which to test connectivity to the Exchange server and MS Mail 3.2 postoffice.

Phase II ­ Model the local systems. You then set up an Exchange server and a test MS Mail 3.2 postoffice and configure the Exchange Internet Connector and MS Mail connectors. This setup lets you test all aspects of the connectivity with fictitious domain names and addresses.

Phase III ­ Configure downstream recipients. This phase proves the model's feasibility, demonstrating that the Internet users can send mail to a recipient without knowing whether the recipient is on the Exchange server or the MS Mail 3.2 postoffice.

Phase IV ­ Reconfigure address spaces and the connectors. This phase begins the process of moving the model toward a production system. Here you shut down the test postoffice and the Internet model.

Phase V ­ Go live. Finally, you reconfigure the last Exchange Server parameters and shut down the SMTP gateway.

Phase I Model the Internet
The goal of the first phase is to model the Internet and, more specifically, to let you test the external world's ability to send mail to users of your hybrid Exchange/MS Mail 3.2 system. The phase involves setting up an SMTP/POP3 server and DNS on a system attached to your local network and configured with TCP/IP as its sole network protocol.

Fortunately, you can model the Internet entirely with an NT Server by using the beta DNS that you can download from rhino.microsoft.com and using a mail server called NTMAIL that you can download from Internet Shopper at http://www.net-shopper.co.uk. Make sure you have Microsoft DNS Server beta version 1069-0615 or above and NTMAIL version 4.00.4980 or above (and that you send in your NTMAIL license fee).

To set up the DNS for our pilot, we built an NT Server--on the same TCP/IP subnet as our organization--with a NetBIOS name, \tadpole, and a host name, tadpole.aegean.com (IP address 204.241.136.245). On that server, we installed and configured the DNS software by exactly following the readme.txt file instructions with the downloaded source files. In the winnt35system32driversetc directory, we created DNS files aegean.dom, api.dom, and arpa-204.rev (based on place.dom and arpa-127.rev). You can see the respective file entries in figure 2, records 6, 7, and 8. We then edited the existing boot file to include the entries shown in figure 2, record 9 and stopped and restarted the DNS service.

Once you configure and start the DNS, you need to test it. A good starting point is to download from the Internet a version of NSLOOKUP, for example from ftp.nau.edu. Install and configure NSLOOKUP, and set it to use your DNS server. Your test should check the MX records for aegean.com, mxs.api.com, and mail32.api.com. The exact procedure will depend on which NSLOOKUP you download, but the results will look similar to figure 4, listing 2.

Our testing confirmed that all queries for mail to [email protected] would get directed to the host tadpole.aegean.com (our future SMTP/POP3 server) and all queries for mail to [email protected] or [email protected] would get directed to the host athena.api.com (our future Exchange server). Telling NSLOOKUP to search for the "A" records of tadpole.aegean.com and athena.api.com yielded 204.241.136.245 and 204.241.136.9, respectively. If your testing works, your TCP/IP clients will point to your DNS server, and you will be able to ping the mail servers by name after you configure NT on those systems.

Once you have a working DNS, you must set up the NTMAIL SMTP/POP3 server from Internet Shopper. Again, install and configure the software exactly following the instructions in the readme.txt file with the downloaded source files.

You have to do only two things after you set up the SMTP/POP3 server: Change the domain name and add a couple of users. To change the domain name, go to the Control Panel and launch the NTMAIL applet (note the quaint British Postal Service icon). Select the Incoming tab, and add a domain name in the Default Domain Name field. We chose aegean.com for our test Internet domain (see screen 1). This name was an arbitrary domain name for housing external users who would be communicating with users on our Exchange server and Mail 3.2 postoffice.

To add users, select the Users tab and add a couple of users' names. We added spyros and jillr so that the Internet users known as [email protected] and [email protected] could email to users of our internal network.

To test the Internet mail system, use the Exchange client to build a Windows 95 box, configured with only the Internet service from the Windows 95 Plus Pack. Configure the Exchange POP3 client to point to tadpole.aegean.com as the mail server, and log into the [email protected] mailbox. Finally, test the mail server by composing and sending mail to yourself. If this test works correctly, you now have a model of the Internet.

Phase II Model the local systems
Once you have a working "Internet," you must set up a subsystem that models the local mail system you want to use. In Phase II, then, you prepare a test MS Mail 3.2 postoffice and an Exchange server and configure the appropriate connectors.

First, set up the postoffice and server using all the default configurations. We used testnettestpo as the MS Mail 3.2 postoffice parameters and APIAlexandria as the Organization and Site for the Exchange server (apicomm was the address space for the connector postoffice).

Next, set up a basic MS Mail 3.2 connector (for example, by following the instructions in Lab 9 of the Exchange course 536, Fundamentals of Microsoft Exchange Server). In the Create Connection dialog, enter the path to the test MS Mail 3.2 postoffice, choose OK, and then verify the network and postoffice names. We created the postoffice path \hermesmaildata and verified that the network and postoffice names were testnet and testpo.

Finally, set up a basic Internet connector (again, for example, by following instructions in Lab 11 of the Exchange course). On the Connections tab, select Use DNS rather than Forward All Messages to One Host (see screen 2).

Make sure that the TCP/IP configuration of the Exchange server uses the test DNS (in our case, at 204.241.136.245), not your real DNS. Test the MS Mail connector by sending mail between two Windows 95 clients. We sent one configured with only the MS Mail service and pointed to the testnettestpo postoffice (\hermesmaildata) and another configured with only the Exchange service and pointed to the Exchange server (\athena). Test the Internet connector again using two Windows 95 clients; one should be configured with only the Exchange service, and the other should be the Windows 95 client configured in Phase I. Assuming these tests work, you now have a model of a hybrid MS Mail 3.2/Exchange network, with the Exchange server recipients able to communicate with your model Internet.

Phase III Configure downstream recipients
Phase III lets MS Mail 3.2 users communicate with your model Internet while hiding their configuration details from the "Internet" users. Three steps will get you there.

First, you must set up your MS Mail 3.2 postofffice so that users can send mail from a POP3 client on the SMTP/POP3 server to a client on the MS Mail postoffice and back. To begin, configure your test MS Mail 3.2 postoffice (in our case, testnettestpo) as a downstream postoffice to the Internet connector on the Exchange server. Next, install the Access component of the MS Mail SMTP gateway on the MS Mail 3.2 postoffice, pointing to the connector postoffice (in our case, apicomm) on the Exchange server. Finally, test the system's connectivity with the Windows 95 clients you have already installed. Our tests confirmed connectivity between [email protected] (on the SMTP/POP3 host), [email protected] (on the Exchange server), and [email protected] or testnettestpouser3 (on the MS Mail 3.2 postoffice).

Second, you must hide the local configuration details from Internet users by ensuring that all users are addressed the same way, regardless of whether they are recipients on the Exchange server or the Mail 3.2 postoffice. We accomplished this by changing the address space of the Exchange server Alexandria site to @api.com, instead of mxs.api.com (see screen 3).

To proceed from this point, you have two choices. The simpler choice is to change the address space of the custom recipient. We changed [email protected] to [email protected]. The second alternative, which illustrates some added functionality of Exchange, is to add a hidden mailbox on the Exchange server. In our case, we called the mailbox user3 and specified testnettestpouser3 as an alternative delivery recipient. Both these methods allow, for example, [email protected] on our Internet SMTP host to send mail to [email protected]. If user3 has an address of api/comm and no alternative delivery recipient, user3 is on the Exchange server. If user3 has an address of testnet/testpo or has an alternative delivery recipient to testnet/testpo/user3, then user3 is on MS Mail 3.2. In either case, user3 gets the mail, and user1 has no clue where user3 resides. Note that we have eliminated the need for a UNIX Sendmail host to handle aliases and alternative addressing, as discussed in scenario 3 in table 1. We now have achieved the goal of transparent migration with our Exchange server system model.

Phase IV Reconfigure address spaces and the connectors
Your next goal is to move the model over to a production system. This phase requires four steps.

1) Shut down the model Internet SMTP/POP3 host, and put the correct DNS address in the TCP/IP configuration of the Exchange server.

2) Shut down the test MS Mail 3.2 postoffice, and put the correct MS Mail 3.2 postoffice information in the MS Mail connector.

3) Add accounts for all your MS Mail 3.2 users on the Exchange server, specifying alternative delivery addresses for users who are not yet migrating.

4) Correct the address space parameters in the Exchange server (e.g., in our case, from api.com to paradigms.com.)

Once you complete these steps, you will have a working internal mail system, with some users on Exchange Server and some on MS Mail 3.2. Internally, everyone can send mail to everyone else. Exchange users can send outbound Internet mail through the Internet connector, and MS Mail 3.2 users can send and receive Internet mail through the SMTP gateway.

Phase V Go live
At this stage, you have one remaining issue--the ISP is forwarding all your incoming mail to the old SMTP gateway rather than to the new Exchange connector. To change this, you must configure the real Mail 3.2 postoffice as a downstream postoffice to the Exchange Server, rather than a gateway postoffice; you must get the ISP to deliver mail to the Exchange server, rather than the SMTP gateway; and you must shut down the old SMTP gateway

The first step is simple: Just reinstall the Access Component of the DOS SMTP Gateway. (You can reinstall the Gateway Component later if you want to change back.)

The final step in the migration is ordinarily to advise the ISP to change your MX record in the DNS to point to the Exchange server rather than the SMTP gateway. In practice, however, getting your ISP to change the MX record is risky. Typically, ISPs reboot their systems once a day, usually at 3 a.m. After a reboot, all new DNS entries take effect, and your new mail traffic patterns are established. If it works, great. If it does not, you have to hope you can tweak some parameter locally and rectify the situation. If your tweaking fails, you must call the ISP and have them reset the DNS MX record to your old SMTP gateway. Unfortunately, that change will take effect the next morning, and you will have lost a whole day's worth of mail (and probably your job).

There is a less risky, slightly offbeat solution to this problem. Instead of asking your ISP to change the MX record from your SMTP gateway to your Exchange server, just change the IP address and host name of your Exchange server to match that of the old SMTP gateway; then turn off the old gateway. If the switch fails, you can return to your old configuration by turning off the Exchange server and booting the old gateway--immediately, rather than 24 hours later.

Testing the Waters
This trial kit leaves you with a hybrid MS Mail 3.2/Exchange server implementation. You can christen the new system by migrating just a few users to Exchange and letting them test the waters. As your confidence in the new system grows, you can move more users, one-by-one or in groups. If you set up Directory Synchronization with the MS Mail 3.2 postoffices, neither your users nor the outside world will ever need to know whether a mail recipient is on the old or the new system. Your main challenge will now be migrating your users from the MS Mail 3.2 client to the Exchange client--and you know how much fun it is dealing with end-users!