Microsoft KB Archive/279537

= XCON: Post-Service Pack 3 MTA Bindback String Changes =

Article ID: 279537

Article Last Modified on 4/28/2005

-

APPLIES TO


 * Microsoft Exchange Server 5.5 Service Pack 4

-



This article was previously published under Q279537





SYMPTOMS
Two message transfer agents (MTAs) may not be able to bind on multihomed computers with certain post-Exchange Server 5.5 Service Pack 3 builds of the MTA installed on only one Exchange Server 5.5 computer. The following error messages may be logged:

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.

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)



CAUSE
This issue can occur because when two MTAs connect over remote procedure call (RPC), the originating MTA sends an MTA bind to the remote end. This MTA bind contains a bindback endpoint that the remote end uses to initiate the bindback. In earlier builds, this bindback endpoint is an Internet protocol (IP) address and a port number. The remote MTA actually ignores this bindback endpoint and uses the address that the packet came from. In the latest builds, the bindback string contains a name, rather than an IP address. The remote end must be able to successfully resolve this name to an IP address to successfully bindback.

A multihomed computer may reach a state where this name resolution does not work; for example, if a fully qualified domain name (FQDN) of the first bound card is sent but the remote server cannot resolve the FQDN.



RESOLUTION
To resolve this issue, ensure that the two MTAs both communicate over the network interface card (NIC), which is first in the binding order.



WORKAROUND
To work around this issue, add an FQDN entry to the hosts file on the computer that issues the bindback.



MORE INFORMATION
This change in MTA bindback behavior came about because of customer cluster and firewall implementations (for example, when only traffic to the cluster virtual IP address is allowed through a firewall). In this case, Exchange Server needs to send the cluster's IP address and the remote MTA needs to use the information that is passed in the bind, instead of just using the source address (which is the node address).

Another example is a bridgehead server that has two NICs on different subnets. There are mailbox servers on both subnets, so by sending the server name and getting the remote MTA to perform a lookup, the servers always use an IP address that is appropriate.

For additional information about related issues, click the article numbers below to view the articles in the Microsoft Knowledge Base:

279415 XCON: MTA 9321 Error Message Occurs When Attempting to Start the Message Transfer Agent

251318 XCON: Message Transfer Agent Uses Node IP Address Instead of Cluster IP Address

Additional query words: fails multi homed bind back

Keywords: kberrmsg kbprb KB279537

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© Microsoft Corporation. All rights reserved.