KnowledgeBase Archive

An Archive of Early Microsoft KnowledgeBase Articles

View on GitHub

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

Article: Q279537
Product(s): Microsoft Exchange
Version(s): 5.5 SP4
Operating System(s): 
Keyword(s): kberrmsg
Last Modified: 06-AUG-2002

-------------------------------------------------------------------------------
The information in this article applies to:

- Microsoft Exchange Server, version 5.5 SP4 
-------------------------------------------------------------------------------


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 <IP Address of
  Server>.

  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:

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

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


Additional query words: fails multi homed bind back

======================================================================
Keywords          : kberrmsg 
Technology        : kbExchangeSearch kbZNotKeyword2 kbExchange550SP4
Version           : :5.5 SP4
Issue type        : kbprb

=============================================================================

THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.