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.
A better approach is to colocate the RPC proxy server on the internal part of the network and use a generic HTTP forward proxy in the DMZ, as Figure 3 shows. This configuration has only one connection from the HTTP forward proxy in the DMZ (in this case, a Microsoft Internet Security and Acceleration—ISA—server) to the RPC proxy server in the internal network. This connection can be over basic HTTP (port 80) or can be encrypted with Secure Sockets Layer (SSL—port 443). You can also use Outlook 2003's encrypted RPC over HTTP functionality. With this approach, you have several options for securing communications. The most conventional method is to terminate the SSL connection at the HTTP forward proxy server and make a basic HTTP connection to the RPC proxy. This is a common approach because such HTTP proxy servers are typically equipped with SSL cryptographic accelerator hardware. Alternatively, you can tunnel the inbound SSL connection through the HTTP proxy server and let the RPC proxy server deal with the SSL encryption. Or the HTTP proxy server might terminate the outward-facing SSL session and establish a new SSL session to the RPC proxy server.
Configuring RPC over HTTP on Servers
You need to make several server modifications to implement RPCs over HTTP. First, you must ensure that the server you use as the RPC proxy server has the RPC over HTTP Proxy service installed. To do so, open the Add/Remove Programs Control Panel applet, and click Add/Remove Windows Components. Select the Networking Services check box. Ensure that the RPC over HTTP service check box is selected, as Figure 4 shows, then click OK to install the service.
After installing the RPC over HTTP Proxy service, drill down through the Microsoft Management Console (MMC) IIS Manager snap-in to the Web Sites\Default Web Site\RPC Virtual Directory object and open the object's Properties dialog box as Figure 5 shows. Navigate to the Directory Security tab and choose Authentication and access control, then disable Anonymous access and enable either Integrated Windows Authentication or, if you're using SSL, Basic authentication. If you select Basic authentication, credentials transfer in clear text, but because of SSL the connection will be secure, so this approach is fine.
The next step is to configure the server to act as the RPC proxy. To do so, open a registry editor and navigate to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\RpcProxy registry subkey, then set the ValidPorts value to <servers with which RPC proxy communicates> with a data type of REG_SZ.
When you set the value for the ValidPorts registry subkey, you must specify every server with which the RPC proxy server might communicate, including all Exchange 2003 mailbox servers and any DCs or GCs, and specify port 593 for each server. The RPC over HTTP Endpoint Mapper service uses port 593 for initial connection handshaking. In this value string, you also specify the port range over which you'll let communication take place. Figure 6, page 72, shows an example of this value string for a server called osbex01. Depending on your environment, server placement, and associated name resolution, you might also want to specify the Fully Qualified Domain Name (FQDN) of servers in the ValidPorts registry entry if the short-name formats might not result in correct resolution. If you look at the example that Figure 6 shows, you'll see that in addition to specifying entries for osbex01, I also specify corresponding entries for osbex01.osb.cantaz.net. If your GC server is the same server on which you're running Exchange 2003, you don't need to specify the GC separately from the Exchange system.
Obviously, if you have tens or perhaps hundreds of mailbox servers and GCs, updating the ValidPorts registry value with details about every one would be a huge task. For this reason, expect to see Microsoft supply a utility with Exchange 2003 that will analyze your Exchange environment and automatically update this registry setting.
Restricting RPC Proxy Communications
Setting the port range on the RPC proxy server defines the range of ports across which RPC over HTTP can function. However, you must also explicitly set the ports that each server involved in RPC over HTTP communications will use. (Note that in beta versions of Exchange 2003, you could set the ValidPorts registry key to the default range of 1024-65535, and any back-end servers or GCs would dynamically choose ports within this range over which to operate with no additional configuration. Microsoft removed this capability with Release Candidate 0—RC0.)
The back-end mailbox servers require the most modification. First, you need to define the port over which the back-end server conducts the RPC over HTTP communications with the Exchange Store. To do so, set the value of the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\RPC/HTTP Port registry subkey to 6001 with a REG_DWORD data type.
Next, you configure the back-end server to provide Directory Service (DS) Referral redirection process support by setting the value of the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeSA\Parameters\HTTP Port registry subkey to 6002 with a data type of REG_DWORD. Then, you configure the back-end server to support DS Proxy access. To do so, set the value of the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\RPC/HTTP NSPI Port to 6003 with a REG_DWORD data type. You must make these changes on all Exchange 2003 back-end servers that might communicate with the RPC proxy server.
You also need to configure any DCs or GCs that you've specified in the RPC proxy server's ValidPorts registry key to communicate with the RPC proxy server over the restricted port range. Navigate to the following registry key on the DC or GC server: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\NSPI interface protocol sequences. Set this value to ncacn_http:6004 with a data type of REG_SZ.
Secure Communications
You should conduct RPC over HTTP communications over SSL rather than over a nonsecure connection. In the preferred deployment configuration that Figure 3 depicts, the HTTP forward proxy server (i.e., ISA Server) terminates any SSL-secured client connections and establishes a non-SSL connection to the RPC proxy server. To establish this behavior, you must install a server certificate on the HTTP forward proxy. You can obtain suitable certificates from a commercial Certificate Authority (CA) such as VeriSign or Thawte, or you can use Microsoft Certificate Services to create your own certificates.
The HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\RpcProxy\AllowAnonymous registry subkey governs the RPC proxy server's behavior with respect to non-SSL connections. If this subkey doesn't exist or its value is set to 0, the RPC proxy server rejects all non-SSL connections or nonauthenticated connections. When the HTTP forward proxy terminates the SSL connection, the subsequent connection to the RPC proxy is typically non-SSL, and thus will be rejected. To override this behavior, you can set the subkey to a value of 1, with a REG_DWORD data type. You must restart the IIS service on the RPC proxy server for this change to take effect.
Note that the current Microsoft documentation suggests that you perform this type of override configuration only on nonproduction systems because of security concerns. However, many production environments will require this kind of configuration, with SSL termination taking place at HTTP proxy servers and non-SSL connections reaching the RPC proxy server. You should asses the risk and implement the configuration that's right for your environment.
Client Configuration
You must also make some modifications to the Messaging API (MAPI) profile to let the Outlook 2003 client connect to the server over HTTP. If the user already has a MAPI profile, you access the properties of that MAPI profile by selecting the Control Panel Mail applet and selecting the appropriate profile. Select Change, More Settings, then go to the Connection tab. Select the Connect to my Exchange mailbox using HTTP check box, and click Exchange Proxy Settings to complete the configuration. On the Exchange Proxy Settings dialog box, which Figure 7 shows, enter a URL to direct the client to the RPC proxy server. This URL can also be the value that the HTTP forward proxy server exposes (which will subsequently redirect the packets to the RPC proxy server). If you're using Basic Authentication, the URL prefix automatically changes from "http" to "https" so that only a secure connection can be used. If the option to connect using HTTP is disabled, verify that XP SP1 and the patch specified earlier are installed. Although not strictly necessary, you can select the Mutually authenticate the session when connecting with SSL check box. Doing so lets the RPC proxy server (or HTTP forward proxy server) authenticate the connecting client by using the client's certificate as well as the server certificate. When you select this option, the client must provide the expected server Principal name to the server's Security Support Provider (SSP) module. If you use Microsoft standard syntax, use the "msstd:" prefix followed by the FQDN of the RPC proxy server, as Figure 7 shows.
Finally, you need to select the Connect using HTTP first, then connect using my Local Area Network (LAN) check box if you want to use HTTP for the connection. Generally, Outlook 2003 will attempt to connect to an Exchange server over TCP/IP first. If this connection fails, Outlook attempts to connect over HTTP. Selecting this check box forces Outlook to attempt to connect over HTTP first, thus avoiding any delay because of protocol timeouts.
This discussion about changing the MAPI profile assumes that the profile already exists on the client PC. If you need to create the profile, be aware that the creation process relies on direct RPC access to the Exchange server over TCP/IP. If you must create MAPI profiles for remote users (i.e., you don't have direct TCP/IP access to the Exchange server), you should use a MAPIprofile-generation utility such as profgen.exe, a tool from the Microsoft Exchange Server Resource Kit, or the new profile generators that ship with the Microsoft Office 2003 Resource Kit. Ideally, from a systems management perspective, you should automate all changes to user MAPI profiles; doing so drastically reduces the likelihood of a user making an error.
Some Closing Thoughts
Using RPC over HTTP to connect Outlook 2003 clients to mailbox servers offers a flexible way to let users access their home mail environments without the constraints of either tunneling or a clumsy Web-based client. However, this functionality doesn't work straight out of the box. It requires planning and configuration on the part of messaging systems administrators. You should consider piloting the RPC over HTTP service in a test environment before deploying it throughout your enterprise so that you can assess the effects on your infrastructure.
