Implementing Messaging Connectivity

After you gain a general understanding of Exchange 2003 interoperability options, you can prepare to implement seamless connectivity. One important consideration is which connector to deploy. The flowchart shown in Figure 1 can be used as a guide for finding the right connector.

Figure 1   Determining Exchange 2003 to non-Exchange connectivity options

Consider the following recommendations:

1. If you can deploy a direct gateway connector to the legacy messaging system, you might want to use this direct connector so that you can implement automated, scheduled directory synchronization.

2. If a direct gateway connector is not available, but the legacy messaging system supports SMTP, use an SMTP connector to connect the messaging systems. Implementing SMTP connectivity is more straightforward than implementing X.400 connectivity.

3. If the legacy messaging system supports only X.400, use an X.400 connector.

4. If there is no connector, or if the cost of implementing a connectivity solution is prohibitive, perform a single-phase migration, as discussed in Understanding Interoperability and Migration in Exchange Server 2003.

This topic focuses on connector components that are available in Exchange Server 2003, specifically the SMTP connector and the X.400 connector. In theory, you need only a single server running Exchange 2003 to deploy either of these connectors. However, running the SMTP connector or the X.400 connector on an Exchange server that hosts mailboxes is not recommended. You should have at least one Exchange 2003 server that includes your Exchange mailboxes and a separate Exchange 2003 server that includes the SMTP connector or the X.400 connector.

For the purposes of this section, it is assumed that you have a single non-Exchange messaging host. However, the information provided here can be applied to larger or more complex deployments. In larger deployments, the non-Exchange messaging system that you connect to acts as the bridgehead for other messaging systems in the legacy infrastructure.

Figure 2 shows the most basic Windows and Exchange 2003 configuration that you should consider for configuring and testing interoperability with a non-Exchange messaging system.

Figure 2   Basic Windows and Exchange environment

Implementing SMTP Connectivity

You must complete the following steps to configure an SMTP connector to a non-Exchange messaging system:

1. Ensure that prerequisites are met   Before you configure an SMTP connector on a bridgehead server running Exchange 2003, you must ensure that the Exchange 2003 server can resolve the name of the remote SMTP host to an IP address and can open a TCP/IP connection to TCP port 25, which is the standard port for SMTP. It might be necessary to verify the internal DNS configuration so that the Exchange bridgehead server and the remote SMTP host can locate each other. An alternative is to specify the remote SMTP host in the SMTP connector configuration directly and provide similar configuration settings in the remote messaging system, so that messages can be transferred in both directions without DNS lookups.

2. Prepare the existing messaging environment   To support proper message routing between Exchange 2003 and the legacy messaging system, the two environments cannot share the same SMTP domain name. For example, if the users in the legacy environment have an SMTP domain named fabrikam.com, users in the Exchange 2003 organization cannot also have fabrikam.com as their SMTP domain name. SMTP message routing does not work if the two SMTP domain names are the same, because the systems cannot distinguish non-Exchange from Exchange users. One option is to change the SMTP domain name so that users in the legacy messaging environment belong to an SMTP domain named legacy.fabrikam.com and the users in the Exchange 2003 organization belong to an SMTP domain named exchange.fabrikam.com. An alias file on a central smart host can then be used to map external user addresses in the form of user@fabrikam.com to the internal addresses user@legacy.fabrikam.com or user@exchange.fabrikam.com. This configuration is shown in Figure 3. Additional options for preserving the public SMTP addresses of your users in a multiphase migration are discussed in Understanding Interoperability and Migration in Exchange Server 2003.

   Figure 3   Splitting an SMTP domain into subdomains

   

3. **Prepare the Exchange 2003 environment   **If the Exchange 2003 organization already exists, you might need to change the SMTP domain name of your Exchange users as well. You do this by changing the default recipient policy in Exchange System Manager. Recipient policy objects reside in the Recipient Policies container under the Recipients node. Display the properties for the Default Policy object, switch to the E-Mail Addresses (Policy) tab, and then change the SMTP address reference. For example, specify @exchange.fabrikam.com instead of @fabrikam.com. Remember that you must implement a solution to preserve the existing e-mail addresses of your users so that e-mail communication with external environments, such as customers and business partners, is not disrupted. Do not change the domain name until you have decided how to resolve this issue.

   It is possible to adjust the SMTP addresses in a recipient policy even further. For example, you can change the user name portion, which by default refers to the name of the user account. For a list of placeholders that you can use in address generation rules to customize SMTP address generation, see Table 3 in Performing a Single Phase Migration. For example, you can set the address format to %g@exchange.fabrikam.com. As a result, a user whose display name is Ted Bremer receives an SMTP address of Ted@exchange.fabrikam.com.

4. **Configure the SMTP connector and Internet message formats   **The SMTP connector is configured using Exchange System Manager. The location of the connector in Exchange System Manager depends on whether you have enabled viewing for routing or administrative groups. Figure 4 shows the location of the connector when viewing for both routing and administrative groups is enabled.

   Figure 4   Location of connector instances in Exchange System Manager

   

   At a minimum, you must specify whether the SMTP connector instance should use DNS to determine the remote SMTP host through MX records, or provide the host name or IP address of the remote SMTP host directly on the General tab. You also must specify the local bridgehead servers that will use this connector instance to transfer messages. It is possible to specify multiple remote and local bridgehead servers. You must also define an address space for the connector on the Address Space tab to identify the SMTP domain to which this connector instance connects (for example, legacy.fabrikam.com). The remaining connector parameters do not usually apply when you use an SMTP connector to connect to a non-Exchange SMTP host in the internal TCP/IP network.

   Because you are connecting to a non-Exchange messaging environment in which the capabilities of the messaging clients are well known, you might also want to configure an explicit SMTP policy for the SMTP domain that refers to the legacy messaging system. SMTP policies are configured in the Internet Message Formats container under Global Settings in Exchange System Manager. For an example of how to configure an SMTP policy for a non-Exchange messaging environment with users using Outlook in an IMAP4 configuration, see How to Configure an SMTP Connector When Migrating from a Non-Exchange Messaging System to Exchange Server 2003.

5. Test e-mail connectivity   To ensure that message routing works, send test messages from the non-Exchange messaging system to Exchange 2003 and then reply to these messages to ensure that message transfer also works in the opposite direction.

   Note

   Always test newly configured Exchange connectors in both directions.

Implementing X.400 Connectivity

You must complete the following steps to configure an X.400 connector to a remote MTA:

1. Ensure that prerequisites are met   Configuring an X.400 connector is a complex task, especially when you are connecting to a non-Exchange X.400 system. You must specify all configuration settings carefully and ensure that they match the configuration of the remote system. You must obtain all of this information from the administrator of the remote X.400 MTA prior to configuring a connector instance, and you must provide the remote administrator with information about the local configuration. X.400 connectivity requires that both sides specify, among other things, MTA names and passwords. If this information does not match the configuration of the remote X.400 system, connection requests will be refused, and messages will not be transferred. You can find the local MTA information in Exchange System Manager, in the properties of the X.400 object located in the Protocols container under your bridgehead server.

2. Prepare the Exchange MTA   You must install a transport stack in Exchange System Manager for the X.400 connector instance to use. Two transport stacks are available: the TCP/IP transport stack and the X.25 transport stack. The transport stack configuration concerns the configuration of the remote MTA. It defines the address information for the remote system, such as the remote host name or IP address for a TCP/IP X.400 connector, or the X.121 address for an X.25 X.400 connector. You must also specify SSAP, PSAP, and TSAP if the remote MTA (S Selector, P Selector, and T Selector) uses this address information. Ask the remote administrator for this information. You must also inform the remote administrator about the transport stack configuration of your Exchange MTA. If the remote administrator requires you to use specific local Open System Interconnection (OSI) address information when you connect to the remote MTA, you can specify this information on a per-connector basis on the Override tab of the X.400 connector.

3. Configure the X.400 connector instance   After you have added the transport stack, you are ready to configure the X.400 connector object in Exchange System Manager. As with the SMTP connector object, the location of the connector object in Exchange System Manager depends on whether you enable viewing for routing or administrative groups. Figure 4 shows the location of the connector when viewing for both routing and administrative groups is enabled. In addition to specifying the remote MTA name and password on the General tab, specifying the host name or IP address on the Stack tab, overriding the local MTA name and password, as well as local OSI address information and other protocol parameters on the Override tab, and specifying a correct X.400 address space on the Address Space tab, you must adjust the Exchange MTA conformance features on the Advanced tab when connecting to a non-Exchange remote MTA. Important settings are the X.400 conformance year and body parts. The MTA conformance year, for example, must match the conformance year of the remote MTA, because significant differences exist between the 1984 and 1988 X.400 standards. If the MTA conformance year of the local MTA does not match the conformance year of the remote MTA, the local MTA overtaxes the remote MTA and communication problems occur. Ensure that the Allow Exchange Contents check box is not selected, because Exchange message content is not X.400 conforming. The remote MTA will refuse messages that violate the X.400 standard. You can send Exchange message content only when connecting to a remote Exchange MTA in another routing group of the same Exchange organization.

4. Test e-mail connectivity   To ensure that the message routing works, send test messages from the non-Exchange messaging system to Exchange 2003 and then reply to these messages to ensure that message transfer also works in the opposite direction. To find your X.400 address, start Active Directory Users and Computers and display the E-Mail Addresses tab for your user account. As mentioned earlier, you must test newly configured Exchange connectors in both directions. This is especially important for X.400 connectivity where incorrect configuration settings often affect one side only.

   Note

   Exchange 2003 assigns the administrative management domain portion in X.400 addresses a single space character (" ") by default. You must specify this space in the address information when sending test messages. X.400 addresses without administrative management domain information violate the X.400 standard.

Implementing Multiple Connector Instances

You can configure multiple SMTP or X.400 connector instances to the same target system for load balancing and fault tolerance. Configuring multiple SMTP connectors might not be necessary, because a single connector instance can use multiple remote and local SMTP bridgehead servers. However, to achieve load balancing and fault tolerance over X.400, multiple connectors must be deployed, because a single X.400 connector can only be used to connect one Exchange MTA to one remote X.400 MTA.

When you assign a particular connector instance an address space, you also assign this address space a cost value. If multiple routes are available and each has a different cost value, the connection with the lowest overall cost value is chosen. If more than one link has the same cost, Exchange 2003 chooses connectors installed on the local computer over connectors installed on remote Exchange servers. When there is more than one potential local connector, random load balancing is performed. Random load balancing is also performed when multiple bridgehead servers are specified in a single SMTP connector instance. For more information about address spaces and load balancing, see the Exchange Server 2003 Transport and Routing Guide (https://go.microsoft.com/fwlink/?LinkId=26041).

If you want to implement a preferred SMTP connection between Exchange 2003 and a remote SMTP host, you must configure multiple SMTP connector instances and then assign all instances the same address space, but different cost values, with the lowest cost value identifying the most preferred connector. Exchange 2003 performs dynamic message routing over less preferred connector instances based on link state information if the preferred connector is unavailable.

Inbound to Exchange 2003, multiple message paths can also be provided if you have multiple Exchange servers. If the remote SMTP host uses DNS to locate its communication partners, you can register your Exchange bridgehead SMTP servers in MX records and assign different DNS preference values. The MX record with the lowest value is chosen unless this mail exchanger host is unavailable, in which case the mail exchanger with the next lowest value is chosen.

Figure 5 shows a connector and DNS MX record configuration for an Exchange 2003 organization with two bridgehead servers running separate SMTP connector instances. One bridgehead server is primarily responsible for outbound message transfer, and the remote SMTP host usually chooses the other bridgehead server for inbound messages because its MX record has a lower priority value.

Figure 5   Preferred bridgehead servers for inbound or outbound SMTP message transfer