by Robert Henriksen
Users will be delighted at the new client capabilities in Exchange, but connectors are one of the main areas that are going to make the administrator's heart go pitter-pat. Under Microsoft Mail, the gateway products could be the source of a lot of heartburn. It's difficult to emphasize just how much better life is now with Exchange, so I'm just going to dive in.
Exchange ships with three connectors, the new term for what was called gateways in Microsoft Mail. Like everything else in Exchange Server, they are implemented as services. You're far more likely to use the MSMail and Internet Mail Connectors than the X.400 Connector, so I'm going to focus the majority of space on them.
It is strongly advisable to run Exchange and your existing MSMail postoffice(s) concurrently during your configuration/testing and migration period, instead of performing a crash conversion. To do this, you must first install and configure the MSMail Connector to get message transfer (MTA) running between Exchange and your existing Microsoft Mail postoffices. Then enable directory synchronization between Exchange and the Mail postoffice(s), as covered in Chapter 16, "Directory Synchronization with Microsoft Mail.". In the setup examples to follow, I'm assuming you have a fairly straightforward environmenta few MSMail postoffices all on a single LAN/WAN, no X.25 or dial-up async connections between postoffices.
The Internet Mail connector is a very robust product as wellalbeit with a couple of missing links, which I'll review. The single most common source of problems in implementing the Internet Mail Connector is overconfiguration. It takes only a few settings to get it up and running, and I'll show you when to leave well enough alone.
The X.400 Connector isn't likely to see a tremendous amount of use in smaller installations. I give a real-world perspective on just what X.400 is, and where you might find it applicable.
Finally, it is possible to connect an Exchange Server with the following:
These are all currently available via legacy gateway productsmessaging gateways that were created for use with Microsoft Mail 3.x. You can employ them in an Exchange Server environment by first configuring Exchange-to-Microsoft Mail connectivity, and then from Microsoft Mail to the third-party mail system via one of these legacy gateway products. There are third-party Exchange Connectors being written for a variety of the just-mentioned mail systems, so you should definitely look into their availability if you need these connections. Using the Microsoft Mail-era gateways would be reintroducing a lesser grade of software, and a weak link in the chain.
The following companies have either announced or are shipping companion products for Exchange Server:
Wireless Connections
|
Ardis
|
Inmarsat
| |
Integra
| |
Ericsson
| |
Fax
|
OmTool
|
FacSys
| |
Fenestrae
| |
Active Voice (include voicemail)
| |
Family of products
|
C2C |
I suggest taking advantage of the MTA included in Exchange's MSMail Connector, and retiring the Microsoft Mail EXTERNAL program. The reporting, logging, and monitoring functions in Exchange are far superior to MSMail, and can also be completely administered remotely. You don't have to make an either/or decision; it is possible to mix and match which postoffices are serviced by Exchange's MTA and External. If you already have a complex network of postoffices linked with one or more instances of External, you can leave that running and gradually phase the Exchange MTA into the mix. In smaller environments, it's safe to configure the MSMail Connector MTA to take overit's simple to toggle back to the External MTA if the need arises. Like the Internet Mail connector, you can get yourself into trouble by tweaking more settings in the MSMail Connector than you need to.
MSMail Connector actually consists of three components, as shown in Figure 13.1.
Figure 13.1. Two different services handle, store, and forward at the Exchange server when sending mail between Exchange and MSMail.
The MSMail Connector Interchange Service performs the conversion from the native Exchange message format to MSMail's message format. It then places the outbound message into the Connector Postoffice \\exchange_server\maildat$. At this point, the transfer from the Connector Postoffice to the target Microsoft Mail postoffice can be performed by either Exchange's MSMail Connector MTA or a traditional Mail External program. The Interchange Service could have been written to perform both the translation and the MTA, but then you would have been locked into using Exchange's MTA. Using an intermediate PO gives you the flexibility to use the older External program if desired.
Note that the Connector Postoffice is strictly used for MTA; it does not contain any mail accounts of its own. Also, if you use one of the Microsoft Mail gateway products in conjunction with Exchange, you will need to install the gateway access component on the Connector Postoffice for the Exchange users to access the Mail 3.x gateway.
You can structure your MTA one of three ways:
Use Exchange's MSMail Connector MTA to route messages with a single PO (instead of MSMail's External program). This is recommended for single postoffices. (See Figure 13.2.)
Make Exchange's MSMail Connector MTA the hub for all the postoffices, as shown in Figure 13.3 (recommended for multiple postoffices).
Define all but one postoffice to Exchange as "downstream," and allow the existing External program(s) to handle distribution of mail within the MSMail network (see Figure 13.4). This latter option is advisable if you have a large, far-flung MSMail network with a variety of WAN links, async dial-up, and so on.
If you are rolling out an Exchange server at each physical site, you can use Exchange site connectors as your backbone between different groups of MSMail postoffices.
If you ran the standard Exchange installation, your Site\Connections container should show the MSMail Connector object inside of it. If you don't see it, rerun the Exchange setup program off the CD-ROM, select Add/Remove Components, click the Details button for Exchange Server, and check the MSMail Connector option.
Double-click on the MSMail Connector in the Connections container to view its Properties dialog box, as shown in Figure 13.5.
Figure 13.5. The Interchange Page of the MSMail Connector Properties.
The MSMail Connector Properties dialog box will default to displaying the Interchange Page, and insist you enter an Administrator's Mailbox before moving on. I suggest using your own mailbox for all these various Exchange components, until you have everything up and running smoothly. You can always go back and delegate responsibility (and the receipt of error messages) to someone else later.
Another way to handle assignment of administrative duties is to create a Mailbox called PostMaster. Give yourself permissions on this mailbox, in addition to your usual mailbox. Then configure the Exchange Server service properties in your profile to open this second mailbox in addition to your own. That way, you can still monitor any error/status messages, and originate messages as coming from PostMaster. You can also give several network-support people access to the PostMaster mailbox, for redundancy.
Maximize MS Mail 3.x Compatibility determines how OLE objects are handled. Because MSMail 3.x clients can handle only OLE 1.0 objects, you'll need to activate this flag for the connector to convert OLE 2.0 objects within messages down to 1.0 format for MSMail recipients. Note that this will roughly double the size of the message, as both versions of the object will be included.
Enable Message Tracking is well worth activating. This data is written to log files in the \exchsrvr\tracking.log directory, as opposed to the Event Viewer's Application Log. Each day's data is a separate file, named with the format YYYYMMDD.log. You can select the number of days' worth of logs to retain in the property page Admin\Site\Configuration\Server\servername\System Attendant. By the time you learn there's a missing message, it's too late to go back and turn on message tracking. For this reason, and because you can limit the quantity of logging data retained, I recommend activating this featurethere's no downside.
The Local Postoffice page (see Figure 13.6) gives you the properties of the MSMailConnector Postoffice. You'll need to know this postoffice's name when configuring directory synchronization with MSMail postoffices. The Regenerate button is used if, for some reason, you wanted to change the name of the Connector Postoffice. All the existing Exchange mailboxes would have to be updated with the new MSMail address to reflect the postoffice name change. Unless you have some compelling reason to tinker here, I'd leave things well enough alone. In my site, the existing postoffices were named LAW/Faculty and LAW/Students. The Connector Postoffice's default name of UH/Central (Exchange organization/site) in no way caused problems in MTA between these two different network names.
Figure 13.6. The Exchange Connector Postoffice properties.
The Connections page is used to specify which postoffices, and hence which MSMail addresses, the Exchange MTA can reach. After you've added the various postoffice names here, you'll then configure the Connector MTA to service some or all of them. You should initially see an empty Connections list except for the MSMail Connector Postoffice (see Figure 13.7).
Figure 13.7. The Connections page, used to specify the MSMail postoffices to be serviced by the MSMail Connector.
Click the Create button in the Connections page to add an entry for your first MSMail postoffice. You'll be shown the Create Connection property page, shown in Figure 13.8. This is a confusing area; in the Create Connection dialog box you don't enter information directly into the provided fields.
Figure 13.8. Creating a connection from Exchange Connector to the MSMail postoffice.
Use the Change button to display Figure 13.9, enter a UNC path to the postoffice, and click OK.
Figure 13.9. Entering the UNC path to the postoffice.
Exchange will extract the network and postoffice name for you, as shown in Figure 13.10. If you are defining a postoffice that is connecting over an Async connection, select the connection parameter Async. This dialog box will expand to display the necessary modem-configuration options. Ignore the Upload Routing button for now and click OK.
Figure 13.10. The network and postoffice names are extracted by Exchange automatically.
You should now see an entry for your first postoffice, similar to that shown in Figure 13.11.
Figure 13.11. The completed connection entry for a Microsoft Mail postoffice, as described in Figure 13.2.
To configure Exchange to service multiple postoffices, a la configuration option B (from Figure 13.3), click the Create button again, and repeat the preceding process for the next postoffice. Repeat as many times as necessary, until you wind up with something like Figure 13.12. The single indent for all the postoffice names indicates the desired hub configurationall the postoffices are serviced by the Exchange message transfer agent.
Figure 13.12. The Exchange Hub MTA routing, as described in Figure 13.3.
To configure Exchange for configuration option C, you'll first create a single entry in the Connections page for the postoffice that'll service as the gateway into the Microsoft Mail network. Open this postoffice connection back up with the Modify button, click upload routing, and then click OK. You'll see something similar to Figure 13.13. All the other postoffices currently being serviced by your existing Microsoft Mail network should appear indented below the primary postoffice.
In Figure 13.13, an MTA (either MSMail's External or the Exchange MSMail Connector MTA) will handle message transfer between the Exchange site and Law/Faculty. Messages destined for Law/Students and UH/Central will then be transferred from Law/Faculty to the appropriate downstream postoffice by an instance of MSMail External.
Figure 13.13. The downstream MTA routing, as described in Figure 13.4.
Defining the downstream postoffices for Exchange ensures that Exchange knows that it can send mail to all the MSMail users...but doesn't automatically provide an MTA! In option C, be sure to include the Exchange Connector PO (\\server\maildat$) in the external.ini for your instance of External. This will ensure that downstream MSMail users can successfully send to Exchange mailboxes.
Next you'll create one or more message transfer agents (MTAs) to service the postoffices defined under Connections, and specify which (or all) of these MSMail postoffices each MTA will be responsible for handling. If all your postoffices are a single LAN, simply configure them all under a single MTA. In the Connector MTAs property page (see Figure 13.14), click the New button to create an MTA.
Figure 13.14. MSMail Connector MTA property page.
You'll see Figure 13.15. Enter a name for the MTA. A naming scheme of "MTA - name" is useful because it leaves no confusion about its function when seen in the Control Panel | Services list, and it places it directly below all the Microsoft Exchange entries in the Services list.
Figure 13.15. Defining a new Connector MTA.
Leave the message Logging and Polling Frequency as is for now, and click OK to return to the Connector MTAs page (see Figure 13.14).
An Exchange MSMail Connector MTA can handle asynchronous connections between it and an instance of External at a remote site. When you select LAN and Async from the MTA properties page in Figure 13.15, the dialog box will expand to include the COM port selection. The modem must be dedicated to the Async MTA; it cannot be shared with Remote Access Service.
Here's where you'll specify the postoffices serviced by this MTA. Click the List button to see Figure 13.16. Highlight the desired postoffices, and use the Add>> button to transfer them to the Serviced LAN Postoffices list. Click OK when finished, and you should see a Connector MTAs property page similar to Figure 13.17.
Figure 13.16. Selecting postoffices for the MSMail Connector MTA.
Figure 13.17. MSMail Connector MTA configuration for MTA hub-style configuration, per Figure 13.3.
At this point, you can close the MS Mail Connector Properties dialog box; you've finished the configuration on Exchange Server. You'll need to manually start the MSMail Connector Interchange service in the Control Panel before MTA will begin. You should also ensure this service is set for Automatic startup.
Finally, configure your MSMail postoffices to recognize the existence of the Exchange Connector Postoffice. This procedure is explained in the MSMail 3.5 Administrator's Guide, Chapter 7 ("External Postoffice Administrative Tasks"). Assuming all of your postoffices are on the same LAN (no modem links or X.25), refer to the section "Adding Direct Route Postoffices."
I'm going to use the sample account Admin on postoffice LAW\Faculty for this description. To run this test, make sure that
Figure 13.18. Shorten the polling frequency of the MTA during testing.
Because each mail server doesn't yet have directory information about the other(s), you have to manually address the test message. It's simplest to do this from Exchange, and then reply to that test message from Microsoft Mail.
Open your Exchange mailbox and compose a new message. Click the To: button to get the Exchange directory dialog box, and select the New button (see Figure 13.19). Select the type Microsoft Mail Address, and "In this message only," and then click OK.
Figure 13.19. Addressing e-mail to a foreign address.
Fill in the display name with whatever you like; then the appropriate network name, postoffice name, and account name as shown in Figure 13.20. In my example, it's LAW/Faculty/Admin. OK your way back to the message and send it. When the test message arrives in the Microsoft Mail Admin mailbox, simply use the Reply function to create an appropriately addressed test message for the Mail-to-Exchange side of the link.
Figure 13.20. Manually entering a Microsoft Mail address.
The Internet Mail Connector is the replacement for Microsoft's SMTP Gateway. It is a quantum leap beyond the old gateway in reliability and ease of configuration. Noteworthy new features include:
A couple of current limitations include the following:
The Exchange MTA uses the MTS-In and MTS-Out folders in the Exchange Information store as the store-and-forward location for Internet mail. The IMC service polls the MTS-Out folder for mail, and transfers it into the \Exchsrvr\IMCData\Out directory in preparation for handling. The IMC then converts the message format to SMTP, encodes any attachments, and attempts to send it (see Figure 13.21). If the transmission fails, the message is returned to sender with an NDR (Non-Delivery Report). You have extensive control over configuration of delivery retries and message time-out intervals.
When a remote host attempts to connect to the Exchange IMC to send a message, the IMC first checks against the blacklist of host names. If the sending computer isn't on the blacklist, the connection and subsequent message is accepted by the IMC and placed into the \Exchsrvr\IMCData\In directory. The IMC then checks for a match between the message's addressee and the Exchange GAL. If a match is found, the message is converted into the Exchange message format and dropped into the MTS-In folder for handling by the Exchange MTA (see Figure 13.21).
Figure 13.21. The structure of IMC message handling.
The most common source of problems with the IMC is overconfiguration. To get yourself up and running, set just the following parameters:
The administrator's mailbox should be your own account to start with. You can always go back and change it later on the fly. Mail sent to PostMaster@yourserver.domain will be placed in this IMC admin's mailbox. (See Figure 13.22.)
Figure 13.22. Several of the primary settings for the Internet Mail Connector.
UUENCODE is a safe choice for encoding attachments contained in outbound messages. This is another parameter you can easily change later; for the best of both worlds, you can set one as the default encoding scheme and then specify exceptions by domain name.
As with the MSMail Connector, message tracking is well worth turning on.
Select the Notifications button from Figure 13.22. The notifications available, shown in Figure 13.23, are a big improvement over the MSMail SMTP Gateway. I recommend selecting Always send notifications, unless you find the volume of notices to be unmanageable. When you are finished, click OK to return to the Internet Mail property page.
Figure 13.23. Non-delivery reports (NDRs) can be delivered for a wide array of conditions.
Select the Interoperability button in Figure 13.22. The default Interoperability settings, shown in Figure 13.24, are the best bet. Disabling Out of Office Replies and Disable Automatic Replies to the Internet prevents your users from making a nuisance of themselves in the listservs they're subscribed to, and saves you from irritated e-mail from the other newsgroups' subscribers. Click OK to return to the Internet Mail property page when done.
Figure 13.24. You have central control over some otherwise potentially troublesome user capabilities.
Specifying an address space is an area in which Exchange Server shows some of its 1.0 release rough edges. Ideally, it should default to at least the minimal entry of *@*, but instead it ships with no entries at all. Go to the Address Space property page of the IMC and click the New Internet button (see Figures 13.25 through 13.28). Enter *@* and a cost of 1 in the General page; leave the Routing Address blank.
Figure 13.25. Defining the default address space for the Internet Mail Connector. One of five mandatory parameters.
Figure 13.26. *@* and * both work equally well here.
Figure 13.27. These parameters can safely be left blank.
Figure 13.28. The resulting Address Space property page.
The most elemental configuration decision is whether to pass all outbound mail to a relay mail host, or to use DNS to resolve outbound addresses and transfer the outbound mail directly to the remote mail system. The benefits of using a relay host include the following:
Conversely, the benefits to using DNS are
My preference is to go with the relay host; you can always go back and change to DNS, or set up exceptions to the relay host on a domain-by-domain basis. This is also the location to specify a "blacklist" of hosts (computer names) that you will refuse connections from. See Figure 13.29.
Figure 13.29. Selecting DNS or a relay host. A combination of both can be used.
Finally, be sure that the IP address and name of your Exchange Server are properly entered into the DNS server for your network. This is not something you configure within Exchange. If you don't handle your organization's DNS services, contact the appropriate administrator. You can test this by entering ping servername.company.com at a command prompt.
You are far more likely to use the MSMail and Internet Mail Connector than X.400. X.400's most common applications are for large, multinational corporate e-mail systems, particularly in a heterogeneous environment of PCs, minicomputers, and mainframes; corresponding with U.S. Government systems; and in the European Community.
X.400 was developed to solve a problem which the Internet (or more accurately, the Internet and the SMTP mail format) has since solvedlinking proprietary e-mail systems. Development on the X.400 standard began back in the early '80s, long before the Internet had emerged from its closed NSF and educational environment. X.400 and SMTP can be fairly described as another Beta vs. VHS standards tussle. X.400 is inarguably the more feature-rich, but the ubiquity of the Internet and simplicity of SMTP addressing has made it the huge favorite for the majority of e-mail.
X.400's sophistication in handling multilingual environments, support for return receipts, and other features has earned it a place in large multinational corporations. The mix of languages in the European Community has also meant a somewhat greater acceptance of X.400 there than in America. The U.S. Government also requires X.400 compatibility for use in its installations. This government requirement alone guarantees the continued inclusion of X.400 capabilities into messaging products for years to come, no matter how little mainstream use of the standard exists compared to SMTP.
The biggest handicap of X.400 is the cumbersome addressing scheme. Compare the SMTP address
Rhenriksen@uh.edu
to:
c=US;a=;p=UH;o=Central;ou=OquinnLawLibrary;ou=MIS;s=Henriksen;g=Robert
It gets much worse when there are often, by necessity, additional components in the address to handle company divisions, branches, departments, offices, and so on. When X.400 was first released in 1984, there was no directory standard specified to ease some of the pain of working with these addresses. The X.500 directory specification was released in 1988, but is sufficiently cumbersome itself that it has failed to erase the stigma that has held X.400 back from widespread deployment.
A very useful characterization of X.400 is that it is a set of tools, not a product. It was never intended that the guts of X.400 addressing be exposed to the end user; instead, they form the underlying foundation of new mail systems. In the rush to market in the mid-'80s, however, the new X.400-based products were immature and failed to hide the addressing scheme from the users. The ugliness of raw X.400 has been the standard's bane ever since.
Where you might find yourself using the X.400 Connector might be in performing an import of a large client's e-mail directory as Custom Recipients into a separate recipient container for your Exchange site. Ideally, you should then be able to exclude that separate recipient container from integration into your Exchange Global Address List. Unfortunately, that's not the case in this release of Exchange Server. So you could have a GAL of 10,300 entries: 300 mailboxes for your users, and an additional 10,000 custom recipients. A workaround for this would be to implement the X.400 connectivity for your site, and then your users would manually add individual X.400 entries into their personal address books for those contacts they need in the remote organizations.
Going into detail on the use of the X.400 Connector is beyond the scope of this book, given its limited application. You can find more information on the standard in your Exchange documentation and at
http://www.microsoft.com/exchange/x400.htm
In this chapter, you learned the capabilities (and limitations) of the three Exchange connectors; the basic configuration of the MSMail Connector and IMC; and an overview of the X.400 Connector. Although Exchange's connectors do not allow the kind of ultimate flexibility that UNIX and other third-party mail products can offer, they are tightly focused products that offer robust functionality, excellent reporting and management features, ease of use, and a healthy assortment of configuration options.
You should definitely look at the Exchange Server Resource Kit for a number of valuable extensions to the management/configuration controls provided in the base product. The code is available for download from http://www.microsoft.com/exchange, is included with TechNet, and the full kit with documentation can be purchased from Microsoft Sales, 800/426-9400.
Administrators of existing Microsoft Mail installations will find little or no risk in immediately taking advantage of Exchange's MSMail Connector, and quantum improvements in performance and reliability. Exchange's Internet Mail Connector will make it feasible (both financially and technically) to connect your LAN to the Internet mail system, if you were not already connected.