Exchange MTA in a Mixed-Mode Organization

Article
07/25/2014

The Exchange MTA is a critical component in a mixed-mode organization for backward compatibility with servers running Exchange Server 5.5. Within the local site, Exchange Server 5.5 MTAs communicate directly with each other using remote procedure calls (RPCs), and Exchange Server 2003 must use the same mechanisms. MTAs and RPCs are also used over routing group connectors that have a server running Exchange Server 5.5 as a remote bridgehead (that is, a routing group connector operates as a site connector in Exchange 5.5).

RPC-Based MTA Communication

Communication through RPCs does not require you to configure an OSI transport stack or an X.400 connector. When Exchange components communicate directly with each other, all parameters are known. For example, Exchange Server 2003 MTAs do not require you to configure a connector when communicating with servers running Exchange 5.5 Server in the local routing group. The Exchange MTA also communicates with the Exchange store through XAPI to transfer messages to the SMTP service and MAPI-based connectors that have their message queues in the Exchange store. This communication is based on MAPI, which is an RPC-based API. When you view messages in MTA message queues by using the Queue Viewer snap-in in Exchange System Manager, this communication is also based on RPCs.

The Exchange MTA uses an RPC thread pool to support communication with LAN-MTAs, the Exchange store, and administrative tools. You can control the minimum and maximum number of RPC threads by using the following registry parameters.

Location	`HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\` `MSExchangeMTA\Parameters`
Value	`Min RPC Threads`
Type	`REG_DWORD`
Value Data	`0x4`
Description	Determines the minimum number of RPC threads that the RPC runtime library should create and maintain for the MTA process. The default value is 0x4.

Location	`HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\` `MSExchangeMTA\Parameters`
Value	`Max RPC Calls Outstanding`
Type	`REG_DWORD`
Value Data	`0x32`
Description	Determines the maximum number of RPC threads. This limits the maximum number of RPC calls that are guaranteed to be processed at one time. The default value is 0x32 (50). The recommended value is 0x80 (128) in Exchange Server 5.5 and Exchange Server 2003 co-existence scenarios. The Max RPC Calls Outstanding value should not be zero, and should be larger than Min RPC Threads. If you increase the maximum number of RPC threads, you should also increase the number of gateway in and gateway out threads for each mailbox store in the Exchange store process using the Gateway In Threads and Gateway Out Threads registry parameters under HKEY_LOCAL_MACHINE \System\CurrentControlSet \Services\MSExchangeIS\<server_name>\Private-<database_guid>, as explained earlier in this section.

RPC Performance Impact

You must make sure that there are no RPC communication issues on your bridgehead server. For example, you should not have servers running Exchange Server 5.5 that are down frequently in the routing group of the bridgehead server. Because RPC communication is performed synchronously, the MTA must wait for a timeout to expire before the MTA can service other outbound connections, which take precedence over incoming connections. Thus, RPC communication problems can degrade the performance of the entire MTA, including all X.400 connectors. In contrast, X.400 connectors establish asynchronous connections, which have little to no effect on other connectors.

Note

The MTA uses RPCs to transfer messages in and out of the Exchange store. However, this RPC communication should not encounter any problems during normal server operation and should not affect server performance.

RPC Bindback Error

Establishing an RPC connection is a bind-and-bindback process, in which the local MTA first confirms that it is communicating with the remote MTA (the remote MTA name and password are checked), and then the remote MTA confirms the identity of the local MTA (the local MTA's name and password are sent back and checked). An Exchange MTA logs RPC bindback errors when establishing RPC connections to a remote MTA that cannot resolve the fully qualified domain name (FQDN) of the local MTA. When the remote MTA attempts to bindback with the connection string that it was given, and cannot resolve the FQDN, the bindback fails, and the following error is logged in the event log:

Event ID: 9322

Source: MSExchangeMTA

Description: An interface error has occurred. An MtaBindBack over RPC has failed. Locality Table (LTAB) index: %1, NT/MTA error code:1722. Comms error %3, Bind error %4,Remote Server Name %5, Protocol String IP Address of Server.

When the bindback fails, the binding server does not receive a response from the remote system. Eventually, the RPC run-time library encounters a timeout and logs the following error in the event log:

Event ID: 9318

Source: MSExchangeMTA - Interface

Description: An RPC communications error occurred. Unable to bind over RPC. Locality Table (LTAB) index: 151, NT/MTA error code: 1722. Comms error 1722, Bind error 1722, Remote Server Name SERVERNAME [MAIN BASE 1 500 %10] (14)

To resolve this issue, you must make sure that the two MTAs both can resolve each other's FQDNs to IP addresses.

Gateway Address Routing Table

To perform message routing, servers running Exchange Server 5.5 use Gateway Address Routing Table (GWART), and servers running Exchange Server 2003 use link state information. In a mixed-mode organization, Site Replication Service (SRS) replicates Exchange Server 5.5 directory information with Active Directory. Therefore, servers running Exchange Server 2003 can find all connectors in the configuration directory partition. The routing engine can therefore include connectors installed on Exchange Server 5.5 in the link state table. This gives Exchange Server 2003 users the ability to use connectors that are not available in Exchange Server 2003, such as Connector for Lotus cc:Mail, Connector for Professional Office System (PROFS), or Connector for SNA Distribution System (SNADS).

To enable servers running Exchange Server 5.5 to use connectors on Exchange Server 2003, a GWART is generated that includes all connector information. Exchange Server 5.5 users can then send messages to Internet users through SMTP connectors installed on Exchange Server 2003. This is advantageous because all Exchange users can benefit from the spam and connection filtering capabilities of Exchange Server 2003.

For backward compatibility, an Exchange Server 2003 MTA generates the GWART and communicates with Active Directory through Active Directory Services Interface (ADSI) to write the GWART object. The MTA writes the routing information in binary form to the gatewayRoutingTree attribute and updates the gWARTLastModified attribute of the directory object to indicate when the GWART was last updated. The GWART object resides in the administrative group of the server running Exchange Server. The Site Replication Service (SRS) replicates the GWART object to the Exchange Server 5.5 directory, and Exchange Server 5.5 replicates the GWART to all servers running Exchange Server 5.5, so that these servers can include Exchange Server 2003 connectors in their routing decisions.

You can use the following command line to export all GWART objects from an Exchange organization: ldifde -f c:\GWART.ldf -s localhost -d " CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com" -p subtree -r "(objectClass=siteAddressing)".

The following table describes the important attributes of the GWART directory object.

Important attributes of GWART object

Attribute	Description
objectClass	Identifies the directory object as a GWART object, based on the siteAddressing object class.
gatewayRoutingTree	Contains the routing table in the format required by Exchange Server 5.5 MTAs.
gWARTLastModified	Specifies the date and time when the GWART object was last updated.
ridServer	Points to the server that maintains the GWART for this administrative group.

Message Loops Between Exchange Server 5.5 and Exchange Server 2003

In a mixed-mode Exchange organization, you should not specify servers running Exchange Server 2003 as expansion servers for distribution lists that contain Exchange Server 5.5 users. If an Exchange Server 5.5 user sends a message to such a distribution list, the Exchange Server 5.5 MTA correctly forwards the message to the Exchange Server 2003 expansion server. In Exchange Server 2003, distribution list expansion is the job of the categorizer in the SMTP service. However, the SMTP transport subsystem does not amend the TraceInformation in the P1 message transfer envelope to mark the message as distribution-list-expanded. After the distribution list is expanded, Exchange Server 2003 routes the message back to Exchange Server 5.5 for all Exchange Server 5.5 recipients. If the message now revisits a server running Exchange Server 5.5 that already handled the message, the message is dropped and a non-delivery report is generated. This occurs because a loop is detected. SMTP has no concept of X.400 trace information, and the X.400-based Exchange Server 5.5 MTA must drop the message, because the TraceInformation in the P1 envelope does not indicate that this is a distribution-list-expanded message. To avoid this issue, servers running Exchange Server 5.5 should be used as expansion servers for distribution lists that contain Exchange Server 5.5 users.