If you missed the first part in this artilce series please read Troubleshooting RPC over HTTPS (Part 1).
RPC over HTTPS is one of the most useful features of Exchange 2003 and Outlook 2003 and one of the most frustrating. In part one of this article we looked at troubleshooting client and firewall related issues. Part two will look into problems that occur with SSL certificates, RPC proxy and Exchange server configurations.
Introduction
RPC over HTTPS is not overly difficult to implement, however there are a few places where things can go wrong. In order to troubleshoot RPC over HTTPS issues there are a few steps to take to solve the most common issues.
- Verify the Outlook 2003 configuration (part 1)
- Verify the firewall configuration (part 1)
- Verify the SSL certificate authority trust
- Verify the RPC Proxy configuration
Verifying the SSL Certificate and Trusts
In my experience, the number one cause of problems with RPC over HTTPS is caused by errors with the SSL certificate. In order for RPC over HTTPS to connect, you MUST have a valid SSL certificate from a trusted certification authority (CA).
To verify you have a valid SSL certificate installed, open up the IIS Manager MMC and drill down to Servername | Web Sites | Default Web Site. Open up the properties page of the Default Web Site and switch to the Directory Security tab. If you have a certificate installed, the View Certificate button will not be grayed out (if it is you need to install a certificate), press it and view the certificate. In this example (see Figure 1) the SSL certificate is not from a trusted CA and will not work for RPC over HTTPS connections unless the CA is added as a trusted root authority.
Figure 1: SSL Certificate Error
If you are not using a third party certificate, for example if you used an in house CA to create a self singed certificate, you will need to add the CA to the list of trusted CA’s on the server and all clients.
The last thing to verify is that you can connect to the RPC Proxy via an SSL connection. Depending on which service pack level the base OS is on, you can test the connection by opening up Internet Explorer and pointing the browser to:
Windows Server 2003 RTM and SP1 – https://fully.qualified.domain.name/RPC
Windows Server 2003 SP1 – https://fully.qualified.domain.name/RPC/rpcproxy.dll
With pre-SP1 servers, if IIS is functioning properly, and the SSL certificate and CA are valid, you should receive an error message, HTTP Error 403.2 – Forbidden: Read access is denied. This means that it is working. If you are running Windows Server 2003 with SP1 and used the first URL listed above, you will be prompted for credentials three times after which the following error is displayed, HTTP Error 401.3 – Unauthorized: Access is denied due to an ACL set on the requested resource. With Windows Server 2003 SP1, if you used the second URL listed above, you will get a blank page with the SSL lock in the bottom right corner. Again, this means that IIS is functioning properly.
If during any of these tests you received an SSL security warning (see Figure 2) you must clear up the source of this error, such as an untrusted CA, expired SSL certificate, non-matching names, etc. before RPC over HTTPS connections will function.
Figure 2: SSL Security Alert
Outlook will not display any SSL errors or warnings. If the certificate is not valid for any reason the connection will fail. Self-signed certificates are the biggest culprits here and I strongly recommend buying a SSL certificated from a trusted third party vendor.
Verify the Server Configuration
If everything looks good on the client side, the next step is to validate the configuration of the Exchange server and the RPC proxy server. Let’s start with the Exchange back-end server, before proceeding to the Exchange front-end/RPC proxy server.
The Exchange back-end server has little configuration required for RPC over HTTPS, but in situations where RPC over HTTPS is configured on a single server, there are some additional settings you need to configure. The first thing to check is that the World Wide Web Publishing Service (W3SVC) is running. This is simple enough to test by logging into Outlook Web Access.
Once you have verified that, we need to ensure that the ports are configured properly. Microsoft supplies a tool with the Windows Server 2003 Resource Kit called RPCDump, which we can use to test this. RPCDump is a great tool for testing RPC related network issues. Run the command RPCDump.exe /v on the Exchange back-end server and look at the ncacn_http protocol settings, you can see some of them in Figure 3, and ensure they are listening on the proper port number.
- Information Store is listening on port 6001
- Directory Services Referral is listening on port 6002
- Directory Services proxy server is listening on port 6004
Figure 3: RPCDump Output
If you are running RPC over HTTPS with a single Exchange server, you also need to configure a specific port for Global Catalog access. If you haven’t configured this port, you do so with a registry edit. Open up the registry for editing and drill down to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Create a new Multi-string value called NSPI interface protocol sequences and set the value to ncacn_http:6004. You will need to restart the computer for this change to take effect. You should then run RPCDump again to verify the setting has taken hold.
On the RPC proxy server (or the Exchange server in single server deployments) we need to verify that the RPCProxy.dll is loading. Open up Event Viewer and filter the events looking for the following event:
Event Source: RPC Proxy
Event Category: Startup
Event ID: 2
Date: 4/25/06
Time: 7:12:47 AM
User: N/A
Computer: EX02-FE
Description: The following ValidPorts could not be parsed. 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.
If you find this error, you have a mis-configured ValidPorts registry entry such as the wrong server name or mistyped port numbers. A common cause is typing a semi-colon instead of a colon!
The last thing we need to verify on the RPC proxy server is the authentication method. Another common issue is that users are constantly asked to supply their credentials. This will occur when the RPC Proxy server is configured to use Integrated Authentication, which does not work over HTTP proxy connections. Even if you have Basic Authentication configured along side Integrated Authentication, the later has priority and will cause this issue to occur.
Open up the Internet Information Services (IIS) Manager MMC and drill down to Servername | Web Sites | Default Web Site | RPC. Open up the properties page for RPC and select the Directory Security tab; under Authentication and access control press Edit. Verify that Enable anonymous access is not selected and that the only authentication method chosen in Basic Authentication (see Figure 4).
Figure 4: Authentication Settings
Conclusion
RPC over HTTPS is a great feature that can simply e-mail accessibility for your remote users. As with anything, there are issues that can arise and hopefully these articles help you resolve these issues in a timely manner.
If you missed the first part in this artilce series please read Troubleshooting RPC over HTTPS (Part 1).
Configuring ISA Server 2000 to Support Outlook 2003 RPC over HTTP
http://www.msexchange.org/articles/rpchttppart1.html
http://www.isaserver.org/articles/rpchttppart2.html
http://www.isaserver.org/tutorials/rpchttppart3.html
Configuring Exchange 2003 and Outlook 2003
http://www.msexchange.org/tutorials/outlookrpchttp.html
http://www.msexchange.org/tutorials/Outlook_2003_Connect_Exchange_2003.html
Windows Server 2003 Resource Kit Tools
http://www.microsoft.com/downloads/details.aspx?FamilyID=9d467a69-57ff-4ae7-96ee-b18c4790cffd&DisplayLang=en
