Last Update: Sep 24, 2024 | Published: Jan 07, 2009
How can I test RPC over HTTP/S on Exchange 2003?
RPC over HTTP/S is a cool method for connecting your Outlook 2003 client to the corporate Exchange Server 2003 from the Internet or WAN, without the need to establish a VPN session to the corporate LAN and/or needing to open many ports on your corporate firewall. The only ports you’ll need to open on your firewall are TCP 80 and, if using SSL, TCP 443.
The process of setting up the RPC over HTTP/S connection is outlined in the Setting up RPC over HTTP/S on a Single Server article.
After configuring RPC over HTTP/S you’ll want to test it in order to make sure your users can connect to your Exchange server. The methods of testing your configuration are outlined below.
The easiest method of quickly testing your newly configured RPC over HTTP/S configuration is by connecting an Outlook 2003 client found on a different computer in your local area network (or LAN) to your Exchange 2003 server.
Such a configuration can be quickly accomplished by simply creating a new Outlook profile on the client test computer, and then running Outlook on that computer.
However, I found out that for some reason, local area connections to the Exchange server tend to use regular RPC connections (i.e. TCP/IP) rather than RPC over HTTP/S, thus you’ll actually use the "regular" method of Outlook-Exchange method of connection, and in fact won’t be testing your newly configured RPC over HTTP/S configuration.
The problem can be easily seen in the following example. Lets assume we have the following configuration:
Operating System | IP addresses | Names | ||
Computer used for LAN Testing:
Windows XP Pro SP2 + Outlook 2003 |
LAN: 192.168.1.101
WAN: n/a |
NetBIOS name:
Jupiter |
FQDN – Internal:
poseidon.dpetri.net (this is just an example, the name is bogus) |
FQDN – External:
n/a |
Computer used for WAN Testing:
Windows XP Pro SP2 + Outlook 2003 |
LAN: n/a
WAN: Provided by ISP |
NetBIOS name:
Apollo |
FQDN – Internal:
hermes.dpetri.net (this is just an example, the name is bogus) |
FQDN – External:
n/a |
Server:
Windows Server 2003 SP1 + Exchange 2003 SP1 + DC, FSMO, GC |
LAN: 192.168.1.100
WAN: Provided by ISP |
NetBIOS name:
Zeus |
FQDN – Internal:
zeus.dpetri.net (this is just an example, the name is bogus) |
FQDN – External:
mail.dpetri.net (this is just an example, the name is bogus) |
We’ve configured RPC over HTTP/S on Zeus according to the Configure RPC over HTTP/S on a Single Server article.
Next, we want to test and see if Zeus is indeed properly configured and if it will allow me to connect via RPC over HTTP/S. So now we need to set up a new Outlook profile on Poseidon and on Hermes. Follow the steps outlined in the Configure Outlook 2003 to use RPC over HTTP/S article.
Finally, you should connect your Outlook 2003 client to your Exchange 2003 server and see if the connection is indeed made by using RPC over HTTP/S and not the "regular" RPC (or TCP/IP) connection.
This is where you might want to manually and temporarily disable the "regular" RPC traffic to your Exchange 2003 server, thus forcing it to use RPC over HTTP/S. I found out that, in some cases, if you leave the Exchange server open to all types of traffic then the Outlook client will still use the "regular" RPC type connection and not switch to RPC over HTTP/S.
Doing it nicely
For example, in the first attempt we’ll see that after checking out the type of connection used by the Outlook client we’ll find that it is using "regular" RPC type connection.
On your client computer – Poseidon in our case, open the Run command from the Start menu and type
outlook.exe /rpcdiag
If you have more than one Outlook profiles, you may be prompted to choose which profile to use. After you choose the profile that’s configured to use RPC over HTTP/S you will be prompted for a username and password (in case you followed my advice in the Configure Outlook 2003 to use RPC over HTTP/S article).
Enter the username in the following format:
domainname’username
Outlook will open and connect to your Exchange server. Another window will also open in the background, and if you focus on it you’ll see information similar to the one seen here:
Note the Connection column. In most cases it will display TCP/IP, even if you chose an RPC over HTTP/S connection type.
Although Outlook has made a connection with the Exchange server, it didn’t do it through RPC over HTTP/S, and therefore we did not succeed in testing our RPC over HTTP/S connection.
BTW, if, instead of TCP/IP you see HTTPS, then your test was successful and you do not need to proceed to the next step.
If nicely didn’t work, then we’ll use force…
In our second attempt we will forcibly prevent the Exchange 2003 server from receiving any type of traffic except TCP 80 and TCP 443, which are the ports used by HTTP and HTTPS respectively.
To do so we will use the TCP/IP Filtering feature in the Advanced properties of the TCP/IP protocol. We can also use the Windows Firewall feature, IPSec service (see Block Web Browsing but Allow Intranet Traffic with IPSec for some examples on this service) of any 3rd-party filtering application. For now I’ll stick to TCP/IP Filtering. I’m not a big fan of this "feature" (which has been left in the Microsoft TCP/IP suit ever since Windows NT), but now we will use it to block all traffic to the server, except for the above ports.
On the Exchange server – Zeus in our case, right-click My Network Places on the desktop and select Properties.
In the Network Connections window, right-click the Local Area Connection icon (you may be using a different name, just click it, duh…) and select Properties.
In the Local Area Connection window, click to select the Internet Protocol (TCP/IP) protocol and click on Properties.
Lamer note: Make sure you do NOT remove the checkmark beside the TCP/IP protocol. Just click once on the protocol name and them click on the Properties button.
In the Internet Protocol (TCP/IP) properties window click on Advanced.
In the Advanced TCP/IP Settings window select TCP/IP Filtering and them click on Properties.
In the TCP/IP Filtering windows, click to select Enable TCP/IP Filtering, then click to select Permit Only in the TCP Ports section, and then click on the Add button under TCP Ports.
In the Add Filter window type 80 and click Ok.
Add port 443 in the same manner.
If you think you’ll keep this configuration for longer than a few minutes, and if you require additional traffic to enter the server, add the specific ports you wish to allow. For example, add TCP 25 for SMTP, TCP 23 for Telnet and so on.
In this example I only needed this setting to test RPC over HTTP/S, so I didn’t bother adding all the other active ports.
When you’ve added at least TCP 80 and TCP 443, click on Ok.
Click Ok all the way out from the TCP/IP properties windows.
Note: You might be prompted to restart the server. I don’t think you must reboot, but before you do try to disable and enable the Local Area Connection NIC. In cases like this, doing so usually saves me a reboot. If you do reboot you will probably run into some issues, as the server has been prevented from accepting other types of TCP traffic, and it will therefore display some errors and will take longer to boot. That is why I strongly suggest you only disable and enable the NIC, and NOT perform a hard reboot of the server.
Now try Outlook again:
On your client computer – Poseidon in our case, open the Run command from the Start menu and type
outlook.exe /rpcdiag
Enter the username and password.
Outlook will open and connect to your Exchange server. Another window will also open in the background.
Note the Connection column. If you followed my instructions to the letter, it should display HTTP, and if it does, your test has been successful.
After the test has been successful I suggest you quickly close Outlook and remove the TCP/IP Filtering. Follow the above steps and simply remove the selection on the Enable TCP/IP Filtering checkbox:
Again, disable and re-enable the NIC, or, if you’re paranoid, reboot.
If your test was successful on the LAN, you can now proceed to the WAN test. If not, please go back and review your settings. Depending on the type of error you get you might need to follow the steps outlined on this article or on the Configure RPC over HTTP/S on a Single Server article.
In order to test your RPC over HTTP/S configuration over the WAN you’ll first need to make sure that the following conditions are met:
You’ve managed to correctly set up and test RPC over HTTP/S on the LAN. Although this is not a must, it will help you in case the WAN test doesn’t work, and point you to the right troubleshooting track (i.e. Firewall issues and so on).
Your Exchange server (the one and only server in our example) is properly configured with an external IP address
or
Your Firewall or NAT device it properly configured to allow HTTP (TCP port 80) and HTTPS (TCP port 443) traffic from the Internet to your Exchange server. Consult your Firewall/NAT manual for instructions on how to do that.
Your server’s external FQDN is properly resolved by external DNS servers to the IP address discussed in the above bullets.
Note that there is not need for the internal FQDN to match the external FQDN of the Exchange server, but we do want to make sure that whenever someone uses the external FQDN they are correctly resolving this name to the IP address of the Exchange server (or Firewall/NAT – in most cases).
In our example, the internal FQDN of the server is zeus.dpetri.net, yet the external FQDN is mail.dpetri.net. The internal FQDN points to 192.168.1.100, yet the external FQDN is resolved by my ISP’s DNS servers to 212.54.212.78 (this is just an example to get the point through, neither the external FQDN nor the sample IP work). Whenever I connect to mail.dpetri.net from a computer on the Internet, my ISP’s DNS resolve the FQDN to the IP address of the corporate Firewall, and the Firewall is responsible for allowing (or blocking) and transferring the specific request to the internal IP address of the server.
When you’re sure you’ve met the above requirements, set up a computer that’s connected to the Internet via a separate connection with an Outlook profile that’s using RPC over HTTP/S (do not use just any computer on your LAN, use one that’s separately connected to the Internet). See Configure Outlook 2003 to use RPC over HTTP/S for more instructions.
Note: When configuring the Outlook profile make sure you use the right server names in the right places:
In the E-Mail Accounts window, under the Microsoft Exchange Server box, type the NetBIOS name (see table) of the Exchange server.
In the Exchange Proxy Settings tab in the Connection Settings box, type the external FQDN (see table) of the Exchange server.
Very important note regarding SSL: When using SSL (and I recommend you do), you must issue a Digital Certificate to your Exchange server. A Digital Certificate needs to be obtained from a CA (Certification Authority). Windows 2000/2003 has a built-in CA that can be installed and used, however, when issuing a Digital Certificate from your internal CA you MUST be 100% sure that the client computers that are going to connect to the server are properly configured to trust this CA. Most operating systems are pre-configured to trust known 3rd-party CAs such as Verisign, Thawte and others. However unless these computers are made members of the Active Directory domain where you’ve installed your CA, they will NOT automatically trust your CA, and thus your connection will fail! In such scenarios you must import the ROOT CA Digital Certificate into the client computers in order to make them trust your CA. When using 3rd-party trusted CAs in most cases you won’t be required to import anything to the client computers, however you will be required to pay a few hundred dollars for such a Digital Certificate. Search Google for cheap SSL certificates. I personally recommend using Godaddy’s SSL certificates, they are trusted by 99% of the Internet browsers and PPCs, and only cost ~ $20 per year, or less.
Further note on SSL: When you purchase/issue your Digital Certificate for the SSL-protected website, you MUST make sure that the COMMON NAME on the certificate is 100% identical to the External FQDN you’ve just typed!
Try to connect with the Exchange server:
On your client computer – Hermes in our case, open the Run command from the Start menu and type
outlook.exe /rpcdiag
Enter the username and password.
Outlook will open and connect to your Exchange server. Another window called Exchange Server Connection Status will also open in the background.
Focus on the Exchange Server Connection Status window. Note the Connection column. If you followed my instructions to the letter, it should display HTTPS, and if it does, your test has been successful.
The Interface column will display the IP address of your computer or your NIC’s name, and should not be related to the Exchange server.
Note that the Server Name column displays the internal FQDN of the Exchange server, and NOT the external FQDN, although the actual connection is done to the external FQDN.
You may find these related articles of interest to you:
Exchange Server 2003 RPC over HTTP Deployment Scenarios
How to configure RPC over HTTP on a single server in Exchange Server 2003 – 833401