The combination of Microsoft Outlook 2003, Windows Server 2003, and Microsoft Exchange Server 2003 exposes new functionality that lets an Outlook 2003 client connect to Exchange 2003 over HTTP. The communication doesn't just use HTTP; rather, Outlook puts an HTTP wrapper around remote procedure calls (RPCs) to Exchange 2003, letting you connect a local Outlook 2003 client to a remote Exchange 2003 server anywhere that you can use a browser to surf the Web. This capability is useful given the alternatives: using Outlook Web Access (OWA), which continues to improve but still has limited functionality compared with the full Outlook client, or accessing Outlook through a VPN connection, which network providers often block. To use RPC over HTTP, you need to understand the mechanism involved and the required configuration on both client and server.
Understanding Outlook and Exchange Interaction
All versions of Outlook use Messaging API (MAPI) to interact with any Exchange Server version, and Outlook uses RPCs to execute its MAPI calls. RPCs have no built-in reliability characteristics; instead they depend on an underlying transport protocol, such as TCP/IP, to ensure reliability. When implemented on less-reliable transports such as UDP, an RPC-based application must provide time-out and retransmission functionality.
Outlook-to-Exchange RPC communications begin with an initial handshake between the Outlook client and the Exchange server over a well-known port (e.g., UDP port 135—the RPC Endpoint Mapper port) before establishing a communications channel over a dynamically assigned port that's usually in the 1024 to 1100 range. Although you can use registry settings to control this port assignment, network and firewall administrators don't usually allow RPC communications over public TCP/IP networks. Furthermore, because of the many past security problems with the Windows NT RPC service, most network administrators block ports 135, 137, 139, and 445 to keep outside RPC probes from transiting the firewall. Effectively, these restrictions mean that you can't use Outlook from one company's network to connect over the Internet to an Exchange server in another company's network. Rather than make you negotiate with network and firewall administrators to enable RPC over TCP/IP communications, Microsoft has upgraded Outlook and Exchange RPC communications to piggy-back over the HTTP protocol.
This new functionality means that if you set up an HTTP reverse proxy server, you can use HTTP from within a company's network to communicate externally. Typically, this communication uses the standard HTTP port 80 or some variant (e.g., 8080 or 8088). After you configure a client PC's Microsoft Internet Explorer (IE) with a proxy server, any application can use the HTTP protocol for client/server communication. Note that HTTP Secure (HTTPS) is also usually accessible over port 443.
RPC over HTTP Requirements
RPC over HTTP communication between Outlook and Exchange requires that the client PC run Windows XP Service Pack 1 (SP1) along with the patch described in the Microsoft article "Outlook 11 Performs Slowly or Stops Responding When Connected to Exchange Server 2003 Through HTTP" (http://support.microsoft
.com/?kbid=331320). The client must also run Outlook 2003 (I'm running the beta 2 4920 build).
On the server, you must run Windows 2003 so that you can use Microsoft Internet Information Services (IIS) 6.0 and its Worker Process Isolation Mode. In fact, you must run Windows 2003 on all systems that communicate with the Outlook 2003 client, meaning any Exchange servers, Global Catalog (GC) servers, or domain controller (DC) servers.
RPC over HTTP Architecture
The RPC over HTTP architecture is similar to the front end/back end server model that Microsoft first introduced with Exchange 2000 Server and that OWA, IMAP, and POP3 use. Outlook 2003 connects over HTTP to an RPC proxy server, also referred to as the RPC proxy front-end server. The RPC proxy server acts on behalf of the client to establish RPC connections to the back-end server that hosts the requesting client's mailbox. Figure 1 shows the connections.
Some important things about this architecture are worth noting. First, the RPC proxy need not be an Exchange 2003 system because the proxy server uses no Exchange components in its work. An Internet Server API (ISAPI) filter in IIS 6.0 performs the proxy activity, and therefore the only requirement is that the system run Windows 2003. Second, because the RPC proxy server is merely a function of IIS 6.0, you can colocate it on the Exchange 2003 system. And third, although not recommended because of performance and best-practice reasons, you can colocate the GC server on the Exchange 2003 system as well. So in essence, all the server components that Figure 1 shows can exist on the same server box.
You also need to consider server placement in relation to internal and external firewalls and the resulting demilitarized zone (DMZ). You can place the RPC proxy server in the DMZ and the Exchange and other Active Directory (AD) servers in the internal part of the network, as Figure 2 shows. However, because you need to open more ports on the internal firewall, this setup causes unnecessary risks and isn't usually recommended. The risk is especially real with the dynamically assigned ports that you open to allow RPC communications between the RPC proxy server and Exchange 2003 mailbox server. Theoretically, these ports lie in the 1024 to 65535 range, but the implementation of RPC over HTTP mandates that you define a more narrow range (from port 6001 to port 6004). You define this range through registry settings, which I explain in the next section. In addition to the ports that Figure 2 shows, the RPC proxy server might require port 88 (UDP/TCP) for Kerberos services, port 53 (UDP/TCP) for DNS queries, port 445 for the NetLogon Server Message Block (SMB), and ports for any other protocols you need to manage or monitor services.