Skip navigation

Migrating to Microsoft Exchange Server

"Keep a copy of all my inbound and outbound Simple Mail Transfer Protocol (SMTP) mail so that I can comply with industry regulations," the customer requested.

"No problem," I said. "That feature is built into the Exchange Internet Mail Connector."

"But remember," the customer said. "I don't want you to keep copies of any internal SMTP messages that travel between Exchange and my legacy mail system."

BZZZZZZZZZZ! Thanks to my alarm clock, I escaped a dream that replayed the previous day's meeting with a new customer. The customer asked us to assist in a company migration from Novell's GroupWise to Microsoft Exchange Server 4.0. Together we identified three key objectives:

  1. Migrate nearly 650 users gradually, and provide coexistence of the two mail systems.
  2. Provide uninterrupted Internet mail flow for GroupWise and Exchange users and do not modify users' Internet mail addresses ([email protected]).
  3. Archive all external messages, inbound and outbound, to comply with an industry regulation without archiving internal messages between Exchange and GroupWise.

After considering third-party gateway products, we opted for an Exchange-only solution that met the customer's requirements and reduced administrative effort. This article describes the solution and explores its application in other environments.

The Solution
Figure 1, illustrates our initial plan to introduce Exchange into the customer's messaging environment. To meet the first objective, to migrate gradually and have the two mail systems coexist, we changed the function of the client's GroupWise SMTP gateway. Previously, the gateway handled Internet-only messages, but we restricted it to passing all outgoing SMTP messages to Exchange. This change and configuration of the Exchange Internet Mail Connector (IMC) let the two systems communicate without additional gateways.

The second objective, uninterrupted mail flow and maintaining Internet mail addresses, required more consideration. Although we planned to use the Exchange IMC as the conduit to the Internet, recipient addressing was a problem. Because we needed to address GroupWise and Exchange users at the same email domain ( regardless of platform, we had to intelligently route messages addressed to [email protected] to either Exchange or GroupWise, depending on the recipient's migration status. Exchange's Alternate Recipient and Custom Recipient features, which let us redirect incoming messages to user mailboxes on foreign systems, solved the addressing problem and minimized overall administration during the migration.

To achieve the third objective, archiving external communications, we had two options: Develop an application to scan mail headers to distinguish and archive external messages, or create an infrastructure extension to provide service for external messages only. The second option proved cost-effective and easy to support. We added a second Exchange server and IMC to the site and routed all Internet mail through it to fulfill the archiving requirement.

SMTP Configuration and Proposed Mail Routing
Our customer's existing SMTP gateway had provided a messaging link to the Internet for several months. To fulfill the first two necessities, which required connecting the two mail systems, we leveraged the existing gateway as a dedicated path to Exchange. We determined that with the IMC Sample Extension DLL, Exchange can act as a smart mail host, rerouting messages to other SMTP hosts. This solution was the key to GroupWise Internet connectivity.

Next, we created Exchange mailboxes for current email users. We also represented each GroupWise user with an alias (Custom Recipient) in the Exchange directory and hid the aliases from view. Then, we modified delivery properties of each Exchange mailbox to reroute messages to an Alternate Recipient, the GroupWise mailbox alias. Table 1 lists Exchange objects and their properties relevant to our plan. This configuration let us route messages from unattended Exchange mailboxes to corresponding GroupWise mailboxes and eliminated addressing confusion for Exchange users.

To illustrate our proposal, let's briefly follow the route for three types of messages and their replies. First, Internet messages addressed to Exchange users at the domain are delivered to the Exchange server. (Note: To make this approach work, we had to contact the customer's Internet Service Provider--ISP--and request modification of the MX record for the domain. We had the ISP replace the GroupWise SMTP gateway name and address information with that of the Exchange server.) Likewise, Exchange performs a Domain Name System (DNS) lookup to transfer any reply or other outgoing message to Internet mail hosts.

With the second type of message, GroupWise messages to Exchange resemble incoming Internet mail, addressed to [email protected] (Note: The GroupWise directory is populated with aliases, such as [email protected], for each former GroupWise user, to simplify addressing for GroupWise users.) By configuring the GroupWise SMTP gateway to forward all messages to Exchange, messages now arrive in an Exchange recipient's mailbox from a sender in the domain. Replies and other Exchange to GroupWise messages are delivered to the GroupWise SMTP gateway ( because of the address space and message delivery configuration.

Finally, GroupWise communication with the Internet showcases the utility of our design. Incoming Internet mail addressed to [email protected] reaches an Exchange mailbox, and the Alternate Recipient feature reroutes the mail to the appropriate GroupWise mailbox. Replies and other GroupWise mail to Internet users pass through the GroupWise SMTP gateway and are delivered to Exchange. With the IMC Sample Extension DLL in place, if the message does not match the domain criteria, it is then forwarded (via DNS lookup) to the appropriate Internet mail host.

Archiving External Messages
In our new, somewhat elaborate, SMTP environment, the archiving objective becomes simpler. We already proved that with built-in Exchange features, we can distinguish and, more important, reroute SMTP messages based on domain names. Also, we know that message archiving is an optional IMC function. We concluded that an additional IMC, dedicated to processing external messages, was our only requirement.

Figure 2 shows that we added an Exchange server, Extmail, and outlines configuration settings for the Our Firm site: We have two Exchange servers. Intmail is home server to all Exchange mailboxes and Custom Recipients. The Intmail IMC routes messages to the GroupWise SMTP gateway and all other mail to Extmail. The message archival feature of Intmail's IMC is disabled. We added Extmail to the site to send and receive Internet mail. Extmail uses DNS to deliver messages to appropriate Internet mail hosts. We configured Extmail to archive SMTP messages.

Again, let's trace the route of messages and their replies, to examine the design. Assume we've already contacted our client's ISP to add an A record (DNS terminology for the record that contains the IP address and fully qualified domain name of a computer and that is used for name resolution) for Extmail and to modify our MX record directing mail to Extmail.

Mail from an Exchange user, [email protected], addressed to [email protected] leaves the Exchange site via Extmail's IMC, which is configured with a global wildcard address space (*). Extmail uses DNS to find the appropriate mail host for and transfers the message. Extmail receives the reply, addressed to [email protected], and subjects the message to the criteria of imcroute.cfg (the IMC Sample Extension DLL configuration file). If Extmail finds a match, the message is rerouted to the local host and IMC handles it. After archiving the message, Extmail's IMC delivers the message to the recipient's Exchange mailbox. No alternate recipient is specified, so the users receive the message in their inbox.

A GroupWise message to Exchange is different from our previous model. The message, from [email protected] to [email protected], reaches the GroupWise SMTP gateway, which directs the message to Intmail. If the message matches the criteria in imcroute.cfg, the message path is localhost, Intmail's IMC, and the message will be delivered to Exchange (this path includes no message archival). The reply is addressed to [email protected], which is a valid Exchange mailbox, configured to reroute mail to [email protected] Intmail's IMC, configured with address space and message delivery options, transfers this reply to The GroupWise SMTP gateway performs a directory lookup for davej and passes the message to the user's mailbox.

Again, GroupWise messaging with the Internet is the best illustration of our proposal. A message from [email protected] to [email protected] travels through the GroupWise SMTP gateway to Intmail, doesn't match domain criteria in imcroute.cfg, enters Intmail's IMC (isn't archived), is forwarded to Extmail, doesn't match domain criteria in imcroute.cfg, enters Extmail's IMC, and is archived and forwarded to the appropriate mail host for The reply to this message (to [email protected]) follows an equally ambitious route. From the SMTP host to Extmail (found via DNS lookup), the message matches the criteria of imcroute.cfg, is rerouted to localhost, is archived, and is delivered to Exchange by the IMC. Based on the alternate recipient configuration (to [email protected]) of my Exchange mailbox, the message then travels to Intmail's IMC, to the GroupWise SMTP gateway, and to my GroupWise mailbox.

Complex but Effective
Although our messaging project was not simple, Exchange Server answered our toughest challenges. We used NT's NetWare migration tool to create accounts and Exchange's Directory Import feature and Microsoft Access to create mailboxes and Custom Recipients. Within minutes after import file setup and sample runs, we had a complete directory of all user mailboxes, hidden Custom Recipients, and corresponding Windows NT accounts. Later, still using Directory Import and Access, we effortlessly modified each mailbox to include items such as department and distribution list membership.

Although industry regulations for message archival are not commonplace, our solution can be practical in countless other scenarios. For example, although our solution discusses migration from Novell's GroupWise, you can apply this solution in migrations to Exchange from any mail platform that supports SMTP. Also, to comply with the Federal Records Act, many government agencies retain copies of electronic communications involving matters of public record. These organizations can use parts of our solution to archive internal and external mail. In today's world of business partner connectivity and increased online vendor and customer correspondence, Microsoft Exchange has many options to offer. Its flexibility, however, underscores the value of critical thinking before implementation.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.