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 user@company.com. 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 \maildata\smtp\local.cfg record and the
\maildata\smtp\addr_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 user@paradigms.com to that user's inside address,
communicat\2max\user. This record also lets the gateway sign outbound mail from
communicat\2max\user as coming from user@paradigms.com.
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,
chris@sakes.ath.forthnet.gr, 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
communicat\2max\spyros signature. When the SMTP gateway polls its inbox, it
reads and encapsulates the message in a standard SMTP message format, addressing
the result to chris@sakes.ath.fortnet.gr. The SMTP gateway then reads
addr_map.cfg, finds that communicat\2max should be translated to paradigms.com,
and signs the outgoing message as coming from spyros@paradigms.com. 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 spyros@paradigms.com 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 communicat\2max. The gateway then reformats the message for MS Mail,
addresses it to communicat\2max\spyros, and writes it to Spyros's inbox in
\maildata\mbg. 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
chris@sakes.ath.forthnet.gr 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 spyros@paradigms.com,
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
spyros@paradigms.com 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, api\comm.
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.