I just took a job managing about 40 Exchange Server 5.5 systems and recently noticed that all the servers abruptly began logging many instances of event ID 9322 and event ID 9318 at about the same time. Everything seems to be working, but I'm concerned about the sustained volume of these errors. Do you have any idea what could be causing this activity?
Exchange 5.5 servers within a site communicate exclusively via X.400 over Remote Procedure Call (RPC), which is handled by the Message Transfer Agent (MTA) service. When Server A has an RPC message to pass to Server B, Server A contacts Server B and passes it a port number. Server B then uses the specified port number to bind to Server A. If that bindback operation fails, you'll see the errors you describe. The problem can occur for several reasons:
- If a firewall or filter blocks RPC traffic from Server A to Server B, Server A will log event ID 9318. If the firewall permits outbound traffic but prevents return traffic, Server A will log event ID 9318 and Server B will log event ID 9322 (the event message text actually says An MtaBindBack over RPC has failed). To fix the problem in this case, make sure that nothing is blocking the RPC endmapper (TCP port 135) or the port used for the bindback (you can set that port to be static).
- If you've installed an Exchange Server 2003 or Exchange 2000 Server system into an Exchange 5.5 site and the new server has the wrong password specified for its Exchange 5.5 site service account, you'll see the errors. To resolve them, make sure that the service account password is correct.
- If you've installed a post–Service Pack 3 (SP3) build of the Exchange 5.5 MTA—including, of course, the MTA that comes with Exchange 5.5 SP4—and the MTA on either server can't resolve the name on the other server, you might see these errors. The original version of the Exchange 5.5 MTA initiates the bindback by using an IP address and port number, whereas build 2651.75 and later of the MTA initiate the bindback by using the other server's Fully Qualified Domain Name (FQDN). If the MTA can't resolve the FQDN (or if the resolved address is wrong), the server attempting the bindback will log an error. If you're using HOSTS files for name resolution, they must specify the complete FQDN for each server; if you aren't using HOSTS files, you still must make sure that name resolution works. The Microsoft article "XCON: Post-Service Pack 3 MTA Bindback String Changes" (http://support.microsoft.com/?kbid=279537) discusses this behavior.
You mention that all the errors started at more or less the same time. Therefore, I suspect that the third possibility is the problem in your environment.
