Check the Client's Configuration
Microsoft has two implementations of RPC over HTTP—Version 1 and Version 2—that have different capabilities. The RPC over HTTP functionality implemented with Outlook 2003 uses Version 2, which requires that the client use Secure Sockets Layer (SSL) communication and that the RPC proxy server authenticate the connection. Thus, you need to check the configuration of the client MAPI profile to make sure that it's configured to use SSL communication and it accurately identifies the RPC proxy server.
To check these configurations, open Outlook 2003. On the Tools menu, select E-mail Accounts. After you make sure the View or change existing e-mail accounts option is selected, click Next. Select the appropriate account, then click Change, More Settings. In the Microsoft Exchange Server dialog box that appears, select the Connection tab and make sure the Connect to my Exchange mailbox using HTTP check box is selected.
Next, click Exchange Proxy Settings to open the dialog box that Figure 1 shows. Make sure the Mutually authenticate the session when connecting with SSL check box is selected. When this check box is selected, you must add the prefix msstd: to the RPC proxy server's name in the Principal name for proxy server field.
Note that the first point of contact for the Outlook client might be a local HTTP proxy server, such as Microsoft Internet Security and Acceleration (ISA) Server 2000. If so, make sure that this server (and not the RPC proxy server) is accurately identified in the Exchange Proxy Settings dialog box. In addition, you need to verify that the local HTTP proxy server is correctly directing connections to the RPC proxy server. In the case of ISA Server 2000, you can check the connections by inspecting its log files.
Below the Principal name for proxy server field, note the On fast networks, connect using HTTP first, then connect using TCP/IP check box and the On slow networks, connect using HTTP first, then connect using TCP/IP check box. By default, these check boxes are selected to provide the failover discussed earlier. Slow connections are those connections with a link speed of 115Kbps or slower.
Besides checking the configurations in the client MAPI profile, you need to verify that the Outlook 2003 client can indeed connect to the RPC proxy server using SSL communication. You can make this verification by opening Microsoft Internet Explorer (IE) and connecting to https://RpcProxyServer
/RPC, where RpcProxyServer is your RPC proxy server's name. Receiving the error message HTTP Error 403.2 Forbidden: read access is denied means you made a successful connection to the RPC Virtual Directory in Microsoft IIS on the RPC proxy server. (The error message displays because, although the client has the permission necessary to connect to the RPC Virtual Directory, it doesn't have the permission necessary to read that directory.)
Check the Servers' Configuration
In "Exchange 2003 RPC over HTTP Access," I describe the fundamentals of server configuration for RPC over HTTP access, so I won't repeat that information here. Instead, let's look at the biggest server-side culprits that prevent RPC over HTTP connectivity from working correctly:
- Incorrectly configured ValidPorts entry. On the RPC proxy server, the ValidPorts entry in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\RpcProxy subkey must identify all the Exchange servers, DCs, and GC servers with which the RPC proxy server communicates. If you used the RPCHTTP_Setup.vbs script, which is available from Microsoft Product Support Services (PSS), to set up your RPC over HTTP connections, all the host names and ports should be correct. However, if you didn't use RPCHTTP_Setup.vbs, you need to check the host names and ports. In addition, make sure that the RPC proxy server can resolve all the host names specified in the ValidPorts entry and make sure the certificate presented by the RPC proxy server is valid.
- Incorrectly configured back-end Exchange server. The back-end Exchange server's required registry settings are set automatically during the Exchange 2003 installation, so these settings shouldn't be the cause of any configuration problems. However, you need to make sure that the back-end Exchange server's port settings are in agreement with the port settings in the RPC proxy server's ValidPorts entry. In addition, be aware that Exchange 2003 SP1 introduces a new server property that lets you configure an Exchange server as an RPC proxy server. This multipurpose server is called an RPC-HTTP front-end server. Thus, if you have a separate RPC proxy server, you need to make sure that the RPC-HTTP back-end server option (and not the RPC-HTTP front-end server option) is selected. You can access this new property through Exchange System Manager (ESM). Simply right-click the Exchange server, select Properties, and click the RPC-HTTP tab.
- Incorrectly configured DCs or GC servers. If the RPC proxy server communicates with any DCs or GC servers, the DCs' or GC servers' registries must be manually updated to add the NSPI Interface Protocol Sequences entry under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters subkey. This addition is a likely candidate for configuration errors, so you need to make sure it's accurate on each DC or GC server. In addition, you must make sure that the GC servers' port settings are valid and in agreement with the port settings in the RPC proxy server's ValidPorts entry.
If you're experiencing connection problems and you found that all the servers' configurations are correct, try rebooting the servers. Although rebooting might sound trite, I have observed situations in which it solved the problem.
Check for Connectivity
You need to make sure that communication is possible between the RPC proxy server, the back-end Exchange server, and the GC servers. The most powerful tool available for troubleshooting RPC over HTTP connections is the RPC Ping utility, which is available from the Microsoft Windows Server 2003 Resource Kit. Outlook 2003 also provides RPC tracing functionality to help identify connectivity problems.
RPC Ping. RPC Ping is a sophisticated tool that has a myriad of switches and qualifiers that you can use to validate whether RPCs can reach the specified destination (e.g., a server) over the specified HTTP connection. You can find a lot of useful information about RPC Ping in the Microsoft article "How to Use the RPC Ping Utility to Troubleshoot Connectivity Issues with the Exchange Over the Internet Feature in Outlook 2003" (http://support.microsoft.com/?kbid=831051).
You can use RPC Ping to conduct several tests. First, you want to use it to confirm that the Outlook client can make an RPC over HTTP connection to the RPC proxy server. To do so, use the command
rpcping -t ncacn_http
-s ExchangeServer
-o RpcProxy=ProxyServer
-P "username,domain,*"
-I "username,domain,*"
-H 1 -u 10 -a connect -F 3
-v 3 -E -R HttpProxy
Prev. page
1
[2]
3
next page 
