Article ID: 266312
Article Last Modified on 10/25/2007
APPLIES TO
- Microsoft Exchange Server 2003 Enterprise Edition
- Microsoft Exchange Server 2003 Standard Edition
- Microsoft Exchange 2000 Server Standard Edition
- Microsoft Exchange Server 5.5 Standard Edition
This article was previously published under Q266312
This article is a consolidation of the following previously available articles: 266330, 821889, 275468, 279537 and 303156
SUMMARY
This article describes how to troubleshoot scenarios in which an event ID 9322 message may be logged in the event log. This event ID message may be logged in the following scenarios in Exchange Server 5.5:
- Servers in a site communicate through a firewall that uses NAT
- A firewall filters incoming and outgoing ports
This article also describes the following methods that you can use to troubleshoot the event ID 9322 message:
- Verify that fully qualified domain name resolution is working
- Verify that there is enough RAM
- Verify the network connection
- Verify that the user accounts are turned on and replicated after you move mailboxes
INTRODUCTION
This article describes how to troubleshoot an event ID 9322 message. This event may be logged when you experience mail flow issues.
MORE INFORMATION
You may experience mail flow issues in Microsoft Exchange Server 5.5, in Microsoft Exchange 2000 Server, and in Microsoft Exchange Server 2003. When you experience this issue, the following event may be logged in the Application log.
Note The description in the event may vary.
Event Type: Warning
Event Source: MSExchangeMTA
Event ID: 9322
Description: An interface error has occurred. An MtaBindBack over RPC has failed. Locality Table (LTAB) index: xx, Windows 2000/MTA error code: 1722. Comms error 1722, Bind error 0, Remote Server Name xxx, Protocol String ncacn_ip_tcp:xxx[1151] [BASE IL INCOMING RPC 25 507] (14)
Event ID: 9322
Description:
An interface error has occurred. An MtaBindBack over RPC has failed. Locality Table (LTAB) index: xx, NT/MTA error code: 9260. Comms error BASE IL, Bind error INCOMING RPC, Remote Server Name xxx, Protocol String xxx [%7 %8 %9 %10] (14)
Additionally, the following events may be logged in the Application log:
Event Type: Error
Event Source: MSExchangeDSAccess
Event ID: 2064
Description: Process WINMGMT.EXE (PID=936). All the remote DS Servers in use are not responding.
Event Type: Error
Event Source: MSExchangeSA
Event ID: 9098
Description: The MAD Monitoring thread was unable to read its configuration from the DS, error '0x80041001'.
Event Type: Error
Event Source: MSExchangeFBPublish
Event ID: 8197
Description: Error initializing session for virtual machine xxx. The error number is 0x8004011d. Make sure Microsoft Exchange Store is running.
Event ID: 9318
Source: MSExchangeMTA - Interface
Description: An RPC communications error occurred. Unable to bind over RPC. Locality Table (LTAB) index: xxx, NT/MTA error code: 1722. Comms error 1722, Bind error 1722, Remote Server Name SERVERNAME [MAIN BASE 1 500 %10] (14)
For more information about the Microsoft Windows message transfer agent (MTA) error code, type Net HelpMsg ErrorCode at a command prompt.
Scenarios in which an event ID 9322 message may be logged in Exchange Server 5.5
The servers in a site communicate through a firewall that uses NAT
Consider the following scenario:
- Two servers that are running Exchange Server 5.5 SP4 are located in the same site.
- Server1 is in an internal network, 172.
x.x.x. Server2 is in external network, 10.x.x.x. The external network is behind a firewall that uses Network Address Translation (NAT). - NAT is used to translate 10.
x.x.xinto an internal IP address, 172.x.x.x.
In this scenario, mail may queue on the computer that is behind the firewall until the external server connects to deliver the messages. Additionally, an event ID 9322 message and an event ID 9318 message that includes error code 1722 are logged in the Application log.
A firewall filters incoming and outgoing ports
You can configure two servers that are running Exchange Server 5.5 that are in different sites to communicate through a firewall. To do this, you have to set the port numbers for RPC Listen operations. However, if the firewall filters incoming and outgoing ports, mail flow issues occur. Additionally, an event ID 9322 message is logged.
This problem occurs because the Exchange Server MTA that is calling the server issues an RPC bind command that contains a TCP port number that should be used in the reply. However, the MTA that receives the call does not use this port number when it replies. The firewall is configured to go through this port number only. Therefore, the reply is never received by the MTA that called. Communication is not established and no mail can be sent or received. For more information about how to configure port numbers used by the TCP/IP stack, click the following article number to view the article in the Microsoft Knowledge Base:
154596 How to configure RPC dynamic port allocation to work with firewalls
To resolve this issue, update to Exchange Server 5.5 Service Pack 2. For more information about how to obtain the latest service pack for Exchange Server version 5.5, click the following article number to view the article in the Microsoft Knowledge Base:
191014 How to obtain the latest Exchange Server 5.5 service pack
How to troubleshoot an event ID 9322 message
Make sure that FQDN resolution is working
If Exchange Server 5.5 Service Pack 3 (SP3) build 2651.75 or later is installed on the server, the MTA requires fully qualified domain name (FQDN) resolution to operate. Exchange uses Domain Name System (DNS) or Hosts files to perform FQDN. However, in earlier builds of the MTA, the bindback endpoint is an IP address and a port number. The remote MTA ignores the bindback endpoint and uses the address from which the packet came.
To verify that FQDN resolution is working:
- Make sure that the DNS server is valid.
- Make sure each Exchange server has a valid host (A) record in either a DNS or a Hosts file together with the FQDN of each Exchange server to which the Exchange server connects.
To perform these tasks, run the ipconfig /all command on your Exchange servers. Perform the following tasks with the command results:
- Make sure that all DNS server settings that are listed in the Exchange server's configuration are correct.
- Make sure that the DNS servers that are listed have forward lookup zones that are configured to have the information that resolves the FQDN of each Exchange server that is in your domain. If not, manually add a host record for each Exchange server together with its associated IP address.
- Remove any entries that are not valid.
- If more than one DNS server is listed in the TCP/IP properties of your Exchange server network settings, make sure that each listed server is correct.
If you are using a multi-homed server, bindback errors may occur if the remote server cannot resolve the FQDN of the multi-homed server. If FQDN resolution of a multi-homed server fails, use either of the following methods:
- Make sure that the MTAs of each server communicate over the network adapter that is first in the binding order.
- Add an FQDN entry to the Hosts file on the computer that issues the bindback.
Note A multi-homed server is a server that has multiple network interfaces such as a network adapter, a MODEM card, or an Integrated Services Digital Network (ISDN) card.
For more information about how to troubleshoot FQDN resolution issues, click the following article numbers to view the articles in the Microsoft Knowledge Base:
200525 Using NSlookup.exe
217014 Description of the Ping and Tracert tools
Following scenarios describe how FQDN resolution issues occur.
Scenario 1: The DNS server is not valid
Consider the following scenario:
- You manually enter the IP address of a test DNS server as the primary DNS server of an Exchange server. This DNS server can resolve the FQDN of Server1.
- Dynamic Host Configuration Protocol (DHCP) assigns a production DNS server as the secondary DNS server. This DNS server is either offline or is unable to resolve the FQDN of Server1 and any domain controllers.
If network problems prevent the test DNS server from responding in a timely manner, the Exchange server queries the secondary server. However, the query does not work. Therefore, you experience mail flow issues and event ID 9322, 2064, 9098 and 8197 messages may be logged in the Application log.
To resolve this issue, set the secondary DNS server IP address to the same address as the primary DNS server.
Scenario 2: A multi-homed server causes bindback errors
Consider the following scenario. You are working in an environment that has two servers. Each server uses multiple network interfaces. Only one network, Network2, is common to the servers. Both servers have different names on each network:
- ServerA:
- ServerA.Network1.
Company_name.com - ServerA.Network2.
Company_name.com - ServerA.Networkn.
Company_name.com
- ServerA.Network1.
- ServerB:
- ServerB.Network1.
Company_name.com - ServerB.Network2.
Company_name.com - ServerB.Networkn.
Company_name.com
- ServerB.Network1.
ServerA binds to ServerB by using the first TCP transport stack that is available. Then, ServerA passes the following associated string as the bind back string:
TCP: ServerA.Net1.Company_name.com
ServerB tries to bind back to ServerA using the following string:
TCP: ServerA.Net1.Company_name.com
ServerB fails. ServerA recognizes the failure and binds to ServerB with the next available transport stack by using the following new string:
TCP: ServerA.Net2.Company_name.com
ServerB tries to bind back to ServerA by using the following new string and succeeds:
TCP: ServerA.Net2.Company_name.com
A standard MTA session occurs, and mail is transferred between the servers. ServerB logs one bindback failure, but mail transfer is not affected. The process is reversed for ServerB. A server continues to try all the available networks until a success on one network or until all connections fail.
For more information about related issues, click the following article numbers to view the articles in the Microsoft Knowledge Base:
279415 MTA 9321 error message occurs when attempting to start the message transfer agent
251318 Message transfer agent uses node IP address instead of cluster IP address
Make sure that the computer has sufficient RAM
If the computer has insufficient available RAM, the MTA does not deliver messages over a dynamic Remote Access Service (RAS) connector, an X.400 connector, or a site connector or during intrasite communication. To determine whether you are experiencing this issue, follow these steps:
- Set the MTA diagnostic logging level to Maximum for Field Engineering and for X.400 Service categories. Then, review the Application log to see whether an event ID 9322 message and an event ID 9318 message that has error code 14 are logged.
- Run the RPC ping command, and then see whether the following message is logged:
To resolve this issue, examine the computer's available RAM by using either Performance Monitor or Task Manager, and then close programs to make more RAM available. If the computer still has insufficient RAM after you restart the computer, you must add more RAM to your computer.
Verify the network connection
You may experience mail flow issues in either of the following scenarios:
- The Exchange server has been moved to a new Ethernet switch port that automatically senses network speed. However, the Exchange server's network adapter is configured to force full-duplex communication at 100-megabit network transfer speeds.
- Both the Ethernet switch port and the Exchange server's network adapter are configured to force 100-MB full-duplex communication. However, the Ethernet switch or the network adapter may have trouble communicating at that rate or by using full-duplex transmissions.
If you are experiencing network connection issues, the Exchange MTA may not be able to send messages to other servers in the same Exchange site. And, an event ID 9322 message that has error code 9260 may be logged Also, event ID 1209, 1198, 1131, 25, 1222, 9277, 5719 and 5716 messages may be logged. Additionally, the MTA experiences RPC errors when it tries to connect to other Exchange servers.
To resolve mail flow issues if you are experiencing network connectivity issues, follow these steps:
- If there is another Exchange server connected to the same model of Ethernet switch that is the same as the server that is experiencing this issue, trade the Exchange server's switch ports. If the server that has the problem can successfully send and receive mail after you trade switch ports, compare the configurations of the two Ethernet switch port for differences.
- If step 1 does not resolve the issue, compare the two Exchange servers' network adapter configurations to see whether there are differences. Also verify that the same version or date of the network card driver is being used on both servers. Change the network card configuration on the server that is experiencing the problem to that the configuration is the same as a configuration on a working Exchange server.
- If you do not have a Exchange server that is the same as a working server to examine for comparisons or if mail flow must be established immediately, connect the server that is experiencing this problem to a half-duplex 10-MB Ethernet switch port or hub to see whether mail flow can be established.
Verify that the user accounts are turned on and are replicated after you move mailboxes
You may experience one or more of the following symptoms if you try to move mailboxes from a server that is running Microsoft Exchange Server 5.5 to a server that is running Exchange 2000 or Exchange Server 2003:
- Public folders that were available before you moved the mailbox are no longer available.
- Users who have permissions to access mailboxes may be denied access.
- You cannot move the mailbox. And, you receive the following error message:
- An event ID 9322 message that has error code 1722 is logged in the Application log.
These issues may occur when one or both of the following conditions are true:
- The user account is not turned on in Active Directory.
- The user account information is not replicated to other domain controllers on the network.
To resolve the issue, turn on the user accounts on the Exchange 2000 or Exchange Server 2003 server, replicate the changes to any other domain controllers in the network, and then move the mailboxes again.
For more information about how to resolve this issue if the disabled user accounts were created by the ADC, click the following article number to view the article in the Microsoft Knowledge Base:
316047 How to enable disabled accounts that the ADC creates
If the disabled accounts are not created by the ADC, follow these steps:
- On the Exchange 2000 or Exchange Server 2003 server, start Active Directory Users and Computers.
- Right-click the users and the groups that you want to enable, click Enable Account, and then exit Active Directory Users and Computers.
- If you have other domain controllers in the network, start Active Directory Sites and Services.
Note If you do not have other domain controllers in the network, go to step 8.
- In the left pane, double-click the domain controller for the site that contains the connection over which you want to replicate the information.
- In the left pane, click NTDS Settings.
- In the right pane, right-click the connection, and then click Replicate Now.
- Click Services, and then right-click Microsoft Exchange Information Store.
- Stop the Information Store service, and then restart the service.
- Move the mailboxes that you want to move to the Exchange 2000 or Exchange Server 2003 server.
For more information about how to move mailboxes from Exchange Server 5.5 to Exchange 2000 or Exchange Server 2003, click the following article number to view the article in the Microsoft Knowledge Base:
326990 Mailboxes moved from Exchange Server 5.5 to Exchange 2000 Server do not work as expected
Additional query words: XADM
Keywords: kbprb KB266312
