Microsoft KB Archive/175496

= XCON: Using RPCPING To Troubleshoot MTA Connections =

Article ID: 175496

Article Last Modified on 2/26/2007

-

APPLIES TO


 * Microsoft Exchange Server 5.0 Standard Edition
 * Microsoft Exchange Server 5.5 Standard Edition
 * Microsoft Exchange 2000 Server Standard Edition

-



This article was previously published under Q175496



SUMMARY
This article provides a procedure for testing remote procedure call (RPC) communication between two Exchange Server computers. Although similar to Knowledge Base article 167260, "XCLN: How to Use RPCPing to Test RPC Communication," this article provides exact steps for testing RPC communication and suggestions on interpreting the results. These suggestions apply to communication problems with the Site Connector and Dynamic Remote Access Service (RAS) Connector. They also apply to communication between two MTAs within the same site.

These suggestions DO NOT apply to the X.400 Connector, Internet Mail Connector, or cc:Mail Connector. Although this procedure uses RPINGS.EXE and RPINGC32.EXE (which are Intel- based applications), the procedure applies to RPING utilities for Alpha, MIPS, and 16-bit platforms as well. All RPCPING utilities can be found in the \SUPPORT\RPCPING directory on the Exchange Server CD.

NOTE: The information in this article only applies to an Exchange 2000 Server computer that is connecting to Exchange Server 5.0 or 5.5 computers. The information in this article does not apply to Exchange 2000 server to Exchange 2000 server communication.



Procedure to Test Communication
Identify the two Exchange Server computers that you will be troubleshooting. The Exchange Server computer that initiates the communication is called the "calling" server and the Exchange Server computer that receives the call is the "answering" server.

 IMPORTANT: Log on to the computer running Windows NT Server on both the calling and answering servers as the Exchange Service Account. If you are not sure what the Exchange Service Account is, check the Service Account Password tab in the Properties for the Site Configuration object. Run both Rpings.exe and Rpingc32.exe on both the calling server and the answering server. This procedure will test RPC communication both directions; hence the need to have both Rpings.exe and Rpingc32.exe running on both computers. From the calling server, configure Rpingc32.exe to ping the answering server:

 Enter the name of the answering server in the Exchange Server field. Select TCPIP as the Protocol Sequence. If you are not using TCP/IP as the network protocol between servers, then select the appropriate protocol. Select RPING as the Endpoint. Enter 3 for the Number of Pings. (This is an arbitrary number, nothing magical.)</li> Set the Mode to Ping Only.</li> IMPORTANT: Enable "Run With Security"</li></ol> </li>  Click "Start" to run the test

You should receive information similar to the following if the test is successful:

<pre class="fixed_text">  Successful RPC binding using these parameters: network address = SERVER endpoint = 2256 UUID = protocol sequence = ncacn_ip_tcp Ping #1 Succeeded Ping #2 Succeeded Ping #3 Succeeded Server Statistics: #Calls Received at Server = 4 #Calls Initiated by Server = 0 #Packets Received at Server = 4 #Packets Initiated by Server = 4 </li> IMPORTANT: Repeat this process the other direction, from the answering server to the calling server.</li></ol>

Interpreting the Results
If RPC Ping successfully pings the remote server both directions, you may assume that the network and RPC are correctly configured. It also suggests that Windows NT rights are correctly configured, if all testing was done while logged on as the Exchange Service Account. The most likely problem in this case would be a configuration error in Exchange Server. Check the MTA names, passwords, override account information, and so forth. If these appear to be correct, check the directory for consistency and integrity between the two servers.

If RPC Ping fails to ping the remote server, the problem is almost certainly a network problem. Use PING to ping the remote server by name. If pinging by name fails, ping by IP address. If pinging by IP address succeeds, the problem is most likely a hostname resolution problem. If pinging by name succeeds, use the errors received in RPC Ping to search the Windows NT Knowledge Base. Ensure that RPC Locator and RPC Service have both started without error. This can be done by checking Control Panel, Services, and the Event Viewer. You may need to consult with Windows NT support for assistance in troubleshooting RPC configuration problems further.

RPC Communication in Exchange Server
When the Exchange Server MTA needs to open an RPC link with a remote Exchange Server MTA, it will do the following:


 * 1) Establish a reliable connection with the remote server. With TCP/IP as the networking protocol, this involves hostname resolution, TCP handshaking, and passing successfully through any firewalls or routers that may exist between the two servers.
 * 2) Establish an interprocess communication (IPC) link with the remote server. This involves swapping Windows NT credentials (Windows NT domain name, Windows NT username, and password) and validating log ons.
 * 3) Establish an RPC connection between Exchange Server MTAs. This is a bind-and-bindback process wherein the calling MTA first confirms that it is communicating with the intended MTA (the remote MTA name and password are checked), and then the answering MTA confirms that the calling MTA is who it says it is (the calling MTA's name and password are sent back and checked).

As you can see, establishing the connection can fail because of hostname resolution problems, firewall problems, Windows NT security problems, or Exchange Server configuration problems. For additional information about RPC traffic over TCP/IP, please see the following article in the Microsoft Knowledge Base:

159298 Analyzing Exchange RPC Traffic Over TCP/IP

Additional query words: rpc ping rpcping mta

Keywords: kbinfo KB175496

-

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

© Microsoft Corporation. All rights reserved.