Microsoft Exchange Server Interoperability with Microsoft Mail Server

Presented by: Spyros Sakellariadis
Vice President
Information Technology
Advanced Paradigms, Inc.

Heterogeneous Networks

Microsoft® Mail Server is an excellent local area network (LAN)-based electronic mail system for small to medium-sized organizations. It is reliable, has good throughput, and is easy to install and manage. For smaller organizations, Microsoft Mail can meet all their messaging needs. However, large organizations frequently have requirements in excess of those of smaller organizations, or they have evolved with a number of different messaging products in use in different departments. In these organizations, Microsoft Mail typically is only part of the overall messaging environment. For example, Wang has a heterogeneous environment with several messaging products all interconnected. Figure 1 shows the messaging topology as it currently stands:

ART NOT AVAILABLE

Figure 1 Wang email environment

The messaging systems in use at the different departments include Microsoft Mail 3.x, Microsoft Exchange Server client-server messaging and groupware version 5.0, cc:Mail™, VS mail, and various flavors of UNIX® mail. The main reason for this is historical. As the corporation grew and acquired various other companies, each company came with its own flavor of electronic mail. Currently, mail from one user to another may travel as many as 5,000 miles and go through multiple gateways, translating from one format to another. This is a relatively typical scenario in large corporations, and one in which messaging is usually not very efficient.

In a heterogeneous environment such as the one shown in Figure 1, Microsoft Exchange Server can play several key roles. On the one hand, it can provide the gateways between the various other electronic mail systems (for example, between Microsoft Mail and cc:Mail, or between VS mail and the Internet). On the other hand, it can provide an efficient Message Transfer Agent (MTA) for mail traveling within a single mail system (for example, replacing the Microsoft Mail 3.x MTA). Finally, it can play a useful part in a strategy to consolidate and migrate the LAN-based electronic mail systems. At Wang, it plays all three roles.

MS Mail Environment

An environment with Microsoft Mail as a LAN-based messaging system is characterized by the presence of a number of objects:

• Microsoft Mail postoffices. You will find anything between 100 to 500 or more Microsoft Mail 3.x postoffices in a large messaging environment. The postoffices are typically installed in different locations and on different servers, but you will also find multiple postoffices on a single server, as in the following directories:
  • \\server1\po1data
    
    
  • \\server1\po2data
    
    
  • \\server1\po3data
    
    
  • Error! Reference source not found.

Postoffices will have anywhere from 0 to 500 users, with an average of 250 users, installed on them.

• Microsoft Mail Message Transfer Agent (MTA) or the Multitasking Message Transfer Agent (MMTA). If the sites are running a pure MS-DOS®-based Microsoft Mail 3.2 environment, messages will be transferred between the postoffices by a program called External.exe, the MTA for Microsoft Mail. This is an MS-DOS program, that typically is run on a 80386 system or 80486. If the corporation is able to support OS/2® in their network, they may be using the OS/2-based MMTA, and if the corporation has some Microsoft Windows NT® network operating system servers, they may be using the Windows NT–based MMTA. The two MMTA programs are essentially ports of the MS-DOS-based MTA program so multiple sessions of the MTA can run on a single server for performance purposes.
  
  
• Microsoft Mail gateways. Microsoft Mail gateways are products that translate messages and transfer them between Microsoft Mail and foreign electronic mail systems. Two commonly found gateways are the Simple Mail Transfer Protocol (SMTP), for Internet mail, and X.400 gateways:
  • SMTP-Smtpgate.exe
    
    
  • X.400-X400gate.exe

In Microsoft Mail 3.x, these gateways are also MS-DOS-based programs that run single sessions on 80486 computers.

• Directory Synchronization (Dir. Synch). A process needs to be run so users of the different postoffices can see each other in a Global Address List (GAL). In Microsoft Mail 3.x, the MS-DOS-based program, Dispatch.exe, needs to be set up and administered.

Any Microsoft Mail network must include at least one postoffice. If it includes more than one postoffice, it must have the MTA or MMTA running to deliver interpostoffice mail, and Dir.Synch. running to compile a complete address list. Gateways are only needed if the users on the Microsoft Mail system need to communicate with users on foreign systems such as the Internet or X.400 message systems.

MS Mail Limitations

Microsoft Mail 3.x has a number of limitations. These are primarily due to the inherent limitations of any LAN-based electronic mail system that relies on a Shared File System (SFS). The limitations fall into several distinct categories:

• Scalability and performance. Microsoft Mail works well for small and medium-sized organizations. A single postoffice cannot have more than 500 users, and 250 is the practical limit. This means that a large organization with at least 20,000 employees will need 40 or more postoffices. Even a large department will need to have multiple postoffices. Mail delivery between postoffices is less efficient and slower than mail delivery within a single postoffice, and the throughput of the MTA and MMTA declines as the number of postoffices increases. The more postoffices an organization has, the more that mail delivery problems occur.
  
  
• Features. Microsoft Mail 3.x was developed about ten years ago, and the feature set that is available with a pure 3.x product is limited to the technologies of the day. Products such as Microsoft Windows® 95 operating system, Windows NT 4.0, and Microsoft Office 97 office suite, and technologies such as OLE have significantly raised the bar. Users want to mail documents that are far more complex than the simple text messages from before, and administrators expect far more sophistication in the tools for managing the delivery of mail. Microsoft Exchange Server was developed to provide a messaging environment that filled these needs, and corporations are both migrating to Microsoft Exchange and using Microsoft Exchange as an integral element in a Microsoft Mail network where additional features or power are needed.
  
  
• Security. LAN-based, SFS electronic mail systems are necessarily less secure than client/server-based systems. For example, the only active agent in a single postoffice system is the user agent, the Microsoft Mail desktop client. That means that the client must have the rights to read, write, and delete files on the share that is the postoffice, and any client can effectively destroy a corporation’s electronic mail system by simply pressing DELETE while a pointer is inappropriately positioned. Client/server-based systems, such as Microsoft Exchange Server, solve this problem by giving the user no rights to the disk on the messaging server, but do give the user rights to submit a message to a local service for processing.

Typical MS Mail Network

To discuss how Microsoft Exchange Server can be used in a Microsoft Mail 3.x environment, it helps to start with a typical and pure Microsoft Mail network. Figure 2 shows such a network:

ART NOT AVAILABLE

Figure 2 Basic MS Mail Network

In this example, two networks are connected through a telecommunications link. Each network has several postoffices, with perhaps 200 hundred users per postoffice. Each network has an MTA, delivering mail between users on its postoffices, and to the other network. The Patmos network has a system running Directory Synchronization (Dispatch.exe) for the entire organization, and the Athens network has both an SMTP and a X.400 gateway for mail delivery to the Internet and a public X.25 network. This topology is relatively typical of small to medium-sized companies standardized on Microsoft Mail.

Normal Optimization Tricks

As the organization grows, the mail system tends to get used more heavily, as more messages are flowing from more users. This puts a strain on the pure Microsoft Mail network, and the administrator(s) of the mail system need to increase the throughput of the system. There are many optimization tricks that are well documented in the Microsoft manuals and publications. Some of the more important tricks follow:

• Use DrivesWAN. Normally, the MTA will deliver mail to every postoffice in its delivery area (as specified in External.ini). In a wide area network (WAN) environment, this can lead to inefficient processing of mail because of the way that External.exe, a MS-DOS-based program, works. For example, if the MTA has to deliver mail from postoffice PO1 to postoffice PO2, which are both on the other side of a slow WAN link, the MTA has to first copy the message from PO1 to itself (over the slow link) and then back to PO2 (over the slow link). To improve the delivery process, you can put an MTA on both sides of the slow link so each MTA delivers mail for its local recipients only. That way, mail from PO1 to PO2 will never cross the slow link. To accommodate mail being delivered from postoffices on one side of the link to postoffices on the other side of the link, the MTA can be configured with the DrivesWAN parameter in the External.ini file. Thus, mail can be delivered to a postoffice, but not picked up. That way the local MTA can be responsible for local delivery, and there is no local delivery on the wrong side of the link by an MTA. This problem is entirely eliminated with Microsoft Exchange Server, as explained later.
  
  
• Add MTAs. Since the MTA is an MS-DOS-based process, it has an inherent limited performance. It does not take full advantage of more powerful hardware that can be made available. Consequently, to increase performance, an administrator is required to add more systems running the MS-DOS-based MTA to process more messages in a shorter time period. If the organization is using the Windows NT–based MMTA, the administrator can add more instances of the MTA to increase performance. There are well-documented metrics for how many MTAs benefit organizations based upon the number of postoffices and message traffic. Introducing Microsoft Exchange Server will greatly improve this situation.
  
  
• Reduce hops. One major problem with message delivery in a growing mail network comes from the number of hops that a message must take from the sender’s postoffice to the recipient’s postoffice. Each hop takes time, as it represents writing the message to the disk at the intermediary postoffice. Consequently, an administrator can improve message delivery by reducing the number of hops between postoffices. This will be true even when Microsoft Exchange Server is introduced into the infrastructure.

Performance Limitations

Ultimately, however, performance of the LAN-based electronic mail system is limited. In a large measure, this is due to three factors:

• Throughput of External.exe
  
  
• Throughput of Smtpgate.exe
  
  
• Throughput of X400gate.exe

The throughput of the various MS-DOS-based programs that make up the interpostoffice delivery mechanisms is finite and limited. Since MS-DOS-based programs do not scale particularly well, these problems are not easily addressed within a pure Microsoft Mail 3.x system, and you need to look at replacing the delivery processes with ones that do scale. This is when you use Microsoft Exchange Server. Even if a corporation does not plan to migrate its users to Microsoft Exchange Server, it can replace the mail delivery mechanisms with Microsoft Exchange processes. For example, it can choose to:

• Replace Microsoft Mail External.exe with Microsoft Exchange PCMTA.
  
  
• Replace Microsoft Mail Smtpgate.exe with Microsoft Exchange Internet Mail Service.
  
  
• Replace Microsoft Mail X400gate.exe with Microsoft Exchange X.400 Connector.

This replacement can produce significant performance improvements. The following sections describe each of these in more detail.

Exchange PCMTA

Microsoft Exchange Server can integrate into a Microsoft Mail 3.x system using the Microsoft Mail Connector service. The Microsoft Mail postoffices view the Microsoft Exchange Server as just another Microsoft Mail postoffice, and deliver mail to it. In addition, users on the Microsoft Exchange Server system can send mail to users on the Microsoft Mail postoffices. If you assume there are no users on Microsoft Exchange Server, you still can use a Microsoft Exchange Server with the Microsoft Mail Connector to process messages between users on different Microsoft Mail postoffices. In effect, you replace a hub postoffice in the Microsoft Mail network with Microsoft Exchange Server, and replace the MTA (External.exe) with the Microsoft Exchange Message Transfer Agent.

The Microsoft Exchange MTA has many benefits. It is more efficient and processes more messages than either the MS-DOS-based MTA or the OS/2- and Windows NT–based MMTAs, it is more secure, and it has excellent diagnostics and tracking features. In addition, it can be used without converting even one user to Microsoft Exchange, so that it can be dropped into a Microsoft Mail environment without touching the desktops and without the types of studies or anxiety that accompany full migrations of mail systems. Figure 3 shows the mail system in Figure 2, with Microsoft Exchange Server added to the environment:

ART NOT AVAILABLE

Figure 3 MS Mail with Exchange Server added

In Figure 3, a couple of postoffices have been eliminated, , and the gateways moved onto one of the Microsoft Exchange Servers. The MTA on both networks has been eliminated as well, and the messages are moved through the system by the Microsoft Exchange Server Message Transfer Agent services on the two servers.

Comparison procedures

To estimate the performance improvement to be gained from replacing any of the Microsoft Mail message delivery mechanisms with Microsoft Exchange Server facilities, it is useful to set up a common procedure:

• Establish test configurations
  
  
• Determine testing tools
  
  
• Stress until Significant Degradation of Performance
  
  
• Analyze results

In the first place, you need to determine before and after scenarios to compare. You want to get a realistic comparison of the performance of the Microsoft Mail and the Microsoft Exchange Server tools by measuring their performance under similar conditions and loads. Once you have determined this, you need to decide on which tools to use to stress and measure the system, use the tools, and analyze the results.

Test Configurations

The first MS-DOS-based element to replace is usually the MTA. A simple configuration for testing the value of this replacement can be seen from comparing the performance of the MS-DOS-based MTA as shown in Figure 4 with the Microsoft Exchange MTA as shown in Figure 5:

ART NOT AVAILABLE

Figure 4 Two Post Offices with an MS Mail MTA

ART NOT AVAILABLE

Figure 5 Two Post Offices with an Exchange Server MTA

All the users on the network reside on two postoffices, PO1 and PO2; the only thing to change is whether you are using the MS-DOS-based MTA from Microsoft Mail 3.x, or the Microsoft Exchange Server Microsoft Mail Connector and the Microsoft Exchange Server MTA. In fact this comparison is not completely fair, as the Microsoft Exchange Server here is really another postoffice as well. A fairer comparison would be to use several postoffices of which one was a hub, but that will make the test scenario more complex. This simplified scenario is still adequate to show the performance gain from moving to a Microsoft Exchange Server–based message delivery mechanism.

To analyze the message traffic, you need to produce a certain volume of mail. There are a number of ways of doing this, either by using preexisting tools or by writing your own tool with the application programming interface (API) calls included in the MAPI functionality. You can write a simple MAPI tool with a Visual Basic® programming system application that calls MAPISendDocument() in a loop, which sends a preexisting file to a single recipient on another postoffice. A more sophisticated tool is the Microsoft Exchange Load Simulator, which models a more complex scenario. Once you generate a similar amount and rate of traffic in both models, as shown in Figures 4 and 5, you need to analyze how well the MTAs process the messages. To do this, use the following tools:

• Windows NT Performance Monitor
  
  
• MTA log files
  
  
• Sent.log and Recv.log
  
  
• Windows NT Event Viewer
  
  
• Screen messages

The most important tool for the Microsoft Exchange Server is the Windows NT Performance Monitor. This can show you the rate that messages are being processed by the MTA. To measure a similar rate for the Microsoft Mail MTA, you will need to analyze the log files produced in a given amount of time. The easiest way to compare the performance of the two is to increase the load on each until the MTA ceases to be able to process the messages-that is, until the number of messages waiting to be processed by the MTA is growing faster than the MTA can handle. You will find that the Microsoft Exchange MTA can handle many more messages per minute than the MS-DOS-based MTA. In addition, we can increase the power of the hardware on which the Microsoft Exchange Server is running, and significantly increase the throughput of the Microsoft Exchange MTA.

Exchange Internet Mail and X.400 Mail

Just as you can replace the Microsoft Mail MTA with a Microsoft Exchange Server process, you can replace the MS-DOS-based gateways. In particular, you can replace the Microsoft Mail SMTP gateway (Smtpgate.exe) with the Microsoft Exchange Server Internet Mail Service, and the Microsoft Mail X.400 gateway (X400gate.exe) with the Microsoft Exchange Server X.400 Connector. The performance improvements over the Microsoft Mail gateways can be measured in an analogous method exactly to that shown above, and are dramatic. For example, where an organization might be used to processing about 1,000 messages per day through the Microsoft Mail SMTP gateway, a couple of organizations have reported processing in excess of 100,000 messages per day through a single Microsoft Exchange Server Internet Mail Service.

Resources

• Migrating from MS Mail to Exchange, Spyros Sakellariadis, Windows NT Magazine, April 1996.
  
  
• Implementing DNS in Windows NT 4.0, Spyros Sakellariadis, Windows NT Magazine, August and September 1996
  
  
• Configuring the Exchange Internet Mail Connector, Spyros Sakellariadis, Duke Press, Feb. 1997

In addition to added performance, the Microsoft Exchange connectors provide many features not available in the Microsoft Mail gateways, such as Multipurpose Internet Mail Extensions (MIME) support, diagnostics logging, message tracking, filtering, and so forth. With the release of Microsoft Exchange Server 5.0, there are more connectors, such as the cc:Mail connector, that further enhances a Microsoft Mail network.

In summary, adding Microsoft Exchange Server into a Microsoft Mail network can produce significant performance enhancements through the use of its message delivery mechanisms using the Message Transfer Agent and the Connectors (gateways). In addition to improving performance, adding Microsoft Exchange Server can also give the administrator of the network additional features that were unavailable with the earlier version.

© 1997 Microsoft Corporation. All rights reserved.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.

Microsoft, MS-DOS, Visual Basic, Windows, and Windows NT are registered trademarks of Microsoft Corporation.

Other product or company names mentioned herein may by the trademarks of their respective owners.