Inside RPC-over-HTTP

Whenever I see a new gadget or software product, I try to disengage my techno-lust momentarily and ask two questions: Which of the product's features are cool and which are actually useful? Often, the answers don't match up, although in the case of a few products (e.g., TiVo, iPod) they match really well. Exchange Server 2003 has a new feature that's both cool and useful: the ability to tunnel remote procedure calls (RPC) over standard HTTP connections. I've written briefly about this subject before, but I want to delve a little more into RPC-over-HTTP so that you can see how it can benefit your Exchange deployment.

Exchange and Outlook have always worked together using the Messaging API (MAPI) protocol. Over time, Microsoft has added support for IMAP and POP connections so that you can use Outlook in IMAP mode with an IMAP-enabled Exchange server. The problem with doing so is that you lose a lot of MAPI-based functionality, including follow-up flags, delegate access, voting buttons, and message recall. (Well, OK, maybe no one actually misses that last one.) MAPI traffic is covered over the Windows RPC ports (TCP port 135 is the RPC locator service; ports 137, 139, and 445 are used for other traffic). For security reasons, most sites have closed these ports on their firewalls, so Outlook, by itself, can't connect using MAPI.

Until Exchange 2003, the most prevalent solution was to provide a VPN service so that users can connect directly to the internal LAN. This solution, of course, requires you to set up and maintain a VPN, and it requires users to connect to the VPN every time they want to check email. Exchange 2003's RPC-over-HTTP feature does away with this requirement by letting RPC traffic nestle inside HTTP packets that are carried across port 80 or port 443. The latter port uses Secure Sockets Layer (SSL), which you should always use for external-to-internal Web traffic, particularly traffic that involves Outlook Web Access (OWA).

Another solution, of course, is to use RPC-over-HTTP to connect your Outlook 2003 clients to your Exchange 2003 server. This approach gives your clients full MAPI functionality without requiring them to use a VPN (thus improving client performance and network usage) and without requiring you to put RPC traffic directly on the Internet--advantages even when the client is behind a firewall. The best part is that Outlook supports automatic transition between plain RPC and RPC-over-HTTP. Laptop users can launch Outlook at work, pick up email, take the laptop home, plug it in, and get new email without tweaking any settings.

How does this magic work? Well, obviously you need Outlook 2003 and Exchange 2003. However, there's another requirement. Exchange's RPC support actually comes from Windows. In this case, that relationship means that you need to run Exchange 2003 on Windows Server 2003 to get RPC-over-HTTP support. In fact, you also need Windows 2003 on the Global Catalog (GC) servers that your Exchange servers use because the client will forward directory requests to those GC servers.

When an Outlook 2003 client attempts to connect to an Exchange server using RPC-over-HTTP, the client will first encounter a firewall, which should pass port 443 traffic. (Don't use RPC tunneling over port 80--doing so is a security nightmare.) The RPC packets will arrive at the target host, which must proxy them to the Exchange server. The proxying requires an additional software component; you can follow Microsoft's recommendation an use Internet Security and Acceleration (ISA) Server or you can send packets directly to a Microsoft IIS 6.0 or Exchange 2003 front-end server. In the latter case, you should use the RPC-over-HTTP Proxy service, which you install by using the Windows Components Wizard.

There are some other installation steps that I won't go into because the Exchange 2003 release notes and reference manuals document them. I will give you a handy tip, though. The Web release of the Exchange 2003 toolset includes an automatic setup script called RPCHTTP_Setup.vbs. By running this script on your Exchange 2003 servers and Windows 2003 GC servers, you can quickly set up RPC-over-HTTP on the server side. The client side doesn't need much special setup, although in my experience the easiest approach is to have clients make their initial connection (with the accompanying deep sync that creates local copies of the user's email data) on the LAN. Use RPC-over-HTTP with cached mode whenever possible.

RPC-over-HTTP has some interesting implications for site and server consolidation, too, which I briefly mentioned in the April 18 UPDATE. Even if you aren't interested in consolidating, you--and your users--will probably find plenty of advantages to RPC-over-HTTP.