If you’ve wanted to get more use out of your HTTP connections in Exchange Server then you’ve probably been thinking about how to bypass your VPN. You could securely do this and connect directly to the server using Outlook’s OWA (Outlook Web Access).

RPC over HTTP can enable a connection between Outlook clients and the Exchange server without the need for special software. And with a lowered network risk it is a viable alternative to VPN.
 
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.

Remote Procedure Call (RPC) is a protocol that allows an application or computer program to issue a request for a service that is running on another computer on the network. RPC effectively allows an application or part of an application to execute on another computer anywhere on the network. One of the benefits of Remote Procedure Calls are that an application’s workload can be load balanced across the network. The service or server that responds to the RPC handles the incoming request as if it were made locally. The program or application making the request is the client in this model. The client waits until the request has been handled before proceeding with further execution thus making this a synchronous operation.

Any remote server that is running Internet Information Services (IIS) and has been configured to respond to remote procedure calls will support HTTP connections from clients requesting service. The servers may be on different networks than the clients or the servers and clients may be behind firewalls but they will still be able to establish communication across the internet.

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. Troubleshooting those areas can include:

• Verifying the RPC proxy server certificate and authentication methods.
• Verifying a successful connection to the RPC proxy server by using a Secure Sockets Layer (SSL) connection.
• Verifying the Office Outlook client configuration.

The most obvious step in the troubleshooting process is to first verify that RPC over HTTP components are installed on your Exchange Server computer.

You need to check that the ValidPorts registry entry is configured correctly and that the RPC over HTTP component has been installed on the Exchange Server computer.

You can also view the application log in Event Viewer. If the Rpcproxy.dll file does not load when a client tries to access the RPC proxy server then the ValidPorts registry entry has not been configured correctly. You will see the following event logged to indicate that the Rpcproxy.dll file did not load successfully:

Event Source: RPC Proxy
Event Category: Startup
Event ID: 2
Date: date
Time: time
Type: Error
User: N/A
Computer: computername
Description: The following ValidPorts registry key could not be parsed.
computername: 100′5000. The RPC Proxy cannot load. The ValidPorts registry key might have been configured incorrectly.
User Action: Verify that the ValidPorts registry value is set correctly. If the value is not correct, edit the registry key to reflect the correct value.

This problem only occurs if the Data value for the ValidPorts registry entry has been incorrectly formatted. For example, this problem occurs if the value contains incorrect characters or punctuation. If you have configured incorrect server names you will not see the error event logged in the application log. And you will only see this event logged the first time that you connect to the RPC HTTP server after you have restarted the World Wide Web Publishing service.

In future posts I will continue to describe other RPC over HTTP problems and methods you can use to troubleshoot the errors to keep your systems healthy and your users happy.