In a previous post I discussed how to troubleshoot RPC over HTTP – specifically how to troubleshoot that the ValidPorts registry entry has not been configured correctly. Doing so will allow you to verify that the RPC over HTTP component has been installed on the Exchange Server computer.

In this article I will summarize how to troubleshoot an unsuccessful RPC over HTTP connection, how to verify that the World Wide Web Publishing Service is running on your Exchange Server computer and how to verify that a Secure Sockets Layer (SSL) certificate is installed on the RPC proxy server. Included are the steps to verify that the ports are set correctly on the Exchange Server computer.

To refresh our memory, using RPC over HTTP allows you to leverage your HTTP connections in Exchange Server by enabling clients to talk to the server through remote procedure calls (RPC). These remote procedure calls are sent across the internet through tunnel connections over HTTP between clients and servers, such as Outlook clients and Exchange server, without the need for special software having to be installed. This allows you to bypass your VPN securely and connect directly to the server using Outlook’s OWA (Outlook Web Access).

Remember that RPC over HTTP can enable a connection between Outlook clients and the Exchange server with a lowered network risk. Support for RPC over HTTP is included as a feature in the Microsoft® Exchange Server, Microsoft Office Outlook, and Microsoft Windows Server software. Users will not need a virtual private network (VPN) to allow them to connect to their Exchange mailbox as long as they are using the Microsoft Windows RPC over HTTP feature. From Outlook, clients can connect directly to an Exchange server in a corporate environment from the Internet.

Remote Procedure Calls (RPC) are sent across the internet through tunnel connections over HTTP between clients and servers. Clients, such as Outlook 2007, are able to read and exchange email via RPC calls to the Exchange server.

After you have configured your clients and servers to support RPC over HTTP there will be times when those connections are broken and you will need to troubleshoot the problem(s) and make corrections. There are several areas on the client and server that will need inspection and diagnosis.

Sometimes you will need to troubleshoot an unsuccessful RPC over HTTP connection. You can verify that the World Wide Web Publishing Service is running on your Exchange Server computer by following the diagnostic steps listed below.

Type the following command at a command prompt, and then press ENTER:
net start w3svc

Then verify that you can resolve the name of the back-end Exchange Server computer from the RPC proxy server. Do this to make sure that the RPC proxy server can communicate with the back-end Exchange Server computers by using RPC communications.

Next you will need to verify that a Secure Sockets Layer (SSL) certificate is installed on the RPC proxy server.

To verify that an SSL certificate is installed on the RPC proxy server

1. On the RPC proxy server, start Internet Information Services (IIS) Manager.
2. Expand computername (local computer), where computername is the name of your RPC proxy server.
3. Expand Web Sites, right-click the Web site where the RPC application is located, and then click Properties.
4. Click the Directory Security tab, and then click View Certificate.

Additionally, you can verify that the ports are set correctly on the Exchange Server computer.

Run the RPCDump tool (RPCDump.exe), on the Exchange Server, to view the Exchange Server port information. The RPCDump tool.exe is included in the Windows Server Resource Kit tools. 

Use the RPCDump tool to verify all the following items for the ncacn_http protocol:
- Verify that the information store is listening on port 6001.
- Verify that the Directory service proxy server is listening on port 6004.
- Verify that the Directory Service Referral service is listening on port 6002.

You may also need to verify that the global catalog port is set correctly if the Exchange back-end server is also a global catalog server. Note that this step is only required if you configure RPC over HTTP in a single-server environment or if the Exchange back-end server is also a global catalog server. 

In future posts I will continue to describe other RPC over HTTP problems and methods you can use to troubleshoot the errors.