The Magic of RPC over HTTP
If you have the latest and greatest from Microsoft—Windows Server 2003, Outlook 2003 and Exchange 2003—your users can get seamless remote access to e-mail.
- By Bill Boswell
- February 01, 2004
Imagine a world where your traveling users can get seamless access to their Exchange e-mail from Outlook without VPNs, browsers or special configuration changes. The users simply make an Internet connection from their hotel room or living room, launch Outlook, and start reading e-mail.
This feat is possible if you have a combination of Outlook 2003 as the
e-mail client, Exchange 2003 as the e-mail server, and Windows Server
2003 as the platform. Yes, yes. I know. Many of you haven’t even started
to migrate off NT 4.0 domains yet, much less thought about deploying Exchange
2003 and a new version of Outlook. But even though it might take the management
frogs a while to hop off the lily pad, it’s good to know what’s in store
once you have the budget and the time to make the transition.
Outlook over the Internet
When an Outlook user opens a mailbox or peruses items in a public folder,
the e-mail requests go to Exchange in the form of Remote Procedure Calls
or RPCs. An RPC is a form of interprocess communication in which two applications
share a bit of memory that they use to pass transactions back and forth
to each other. RPCs aren’t a network wire protocol. If the two applications
involved in an RPC transaction run on different machines, they depend
on the underlying network to ferry the RPC messages back and forth.
RPCs are ideally suited for use in a LAN environment where the machines share a reliable, high-speed data communication path. When used across a WAN, though, they have some distinct disadvantages. RPCs are sensitive to network latencies; they’re fairly chatty; and unless the application developer has specifically chosen to use encryption, the RPC message content is open to inspection. And, thanks to the recent worms that exploit RPC buffer overflow vulnerabilities in Windows RPC, most companies and ISPs routinely block access to standard ports used to establish RPC communications.
Windows 2003 has a feature called RPC over HTTP that alleviates many of these deficiencies. Using RPC over HTTP, an application such as Outlook can embed standard RPC transactions into HTTP messages then encrypt the HTTP stream using SSL/TLS (Secure Socket Layer/Transport Layer Security—TLS is version 3.1 of SSL). Using HTTP as a wire protocol makes this form of RPC more resilient in the face of network latencies, and because ISPs permit traffic over SSL/TLS port 443, this technology avoids the RPC ports normally blocked.
RPC over HTTP is a feature of the operating system, so you’ll need to upgrade the OS on your e-mail servers to Windows 2003. Exchange 2000 doesn’t run on Windows 2003—and doesn’t know how to use RPC over HTTP anyway—so you’ll need to upgrade to Exchange 2003 as well. Outlook talks directly to Global Catalog (GC) servers to obtain address lists, so you’ll need to upgrade your GCs to Windows 2003, too. And you’ll need to run Outlook 2003 on a platform that understands RPC over HTTP, which means either XP SP2 (when it comes out) or XP SP1 with hotfix 331320.
I’ll grant you that this is more work than can be done on a quiet Saturday
afternoon, but all those upgrades will be worthwhile in the long run,
and not just to get RPC over HTTP.
RPC over HTTP
Figure 1 shows a simplified set of transactions that describe how Outlook
2003 communicates with Exchange 2003 via an RPC Proxy server. The proxy
server doesn’t need to be running Exchange because RPC over HTTP is a
feature of the operating system. The RPC Proxy service could actually
be running on the Exchange server itself, but this isn’t a best practice
because you would need to either place the Exchange server in your DMZ
or punch a hole through your firewall directly to the Exchange server.
|Figure 1. How Outlook 2003 communicates with
Exchange 2003 over an RPC Proxy server. (Click image to view larger
The transaction starts when the user launches Outlook after having configured
it to use RPC over HTTP. This results in a stream of HTTP messages containing
Outlook doesn’t transmit a bare HTTP stream due to the possibility of
interception in transit, so it establishes an SSL/TLS session with the
RPC Proxy server and uses the session key obtained as part of the TLS
handshake to encrypt the stream. Think of this as a TLS “tunnel” for the
The RPC Proxy server decrypts the SSL/TLS traffic, yielding a stream
of HTTP messages that contain an RPC payload. These messages specify the
name of the Exchange server as their final destination.
The RPC Proxy server establishes an RPC over HTTP connection with the
Exchange server and uses it to forward the client’s messages. The Exchange
server extracts the RPC instructions from the HTTP data stream and performs
the requested operations.
As you can see from this process description, the term “RPC over HTTP”
is something of a misnomer when it comes to using Outlook 2003 to connect
to Exchange 2003. Outlook 2003 requires the use of SSL/TLS when communicating
with an RPC Proxy server, so the true term should be “RPC through a Secure
You don’t need an in-depth knowledge of RPC technology to deploy or troubleshoot RPC over HTTP, but it helps to know a few key elements of RPC communication.
RPC-Based Service Identifiers. If you picture
the ISO networking model, an RPC-based service sits
at the Application layer. The service registers itself
with the OS using a Universally Unique Identifier, or
UUID. For example, the Exchange Store registers an RPC
interface with a UUID of a4f1db00-ca47-1067-b31f-00dd010662da.
Each interface gets a different UUID, and a particular
service can register several interfaces. Use the Rpcdump
utility in the Windows 2003 Resource Kit to list the
RPC services and their UUIDs.
RPC Client Protocols. Because RPC services
reside at the Application layer, clients and servers
that use RPCs rely on an underlying network transport
protocol. Microsoft calls these RPC client protocols.
Exchange uses five RPC client protocols, each of which
has an identifier called a “protocol sequence.” The
protocol sequence used for RPC over HTTP is called ncacn_http.
RPC Endpoints. When an RPC service launches,
it registers its client protocol (or protocols) along
with an entry point for each protocol. The combination
of client protocol and entry point is called an endpoint.
The nature of the endpoint depends on the client protocol.
It might be a TCP or UDP port. It might be a named pipe.
It might be a process interface that accepts local procedure
calls. The ncacn_http client protocol uses TCP ports
for endpoints. For example, the Exchange Store uses
TCP port 6001.
End Point Mapper. Unlike standard Internet
services such as FTP or DNS, which use specific, well-known
ports for communication, an RPC service can select its
ports dynamically at runtime, choosing among available
ports above 1024. Because of this dynamic port registration,
an RPC client application needs a way to determine the
port number registered by the RPC server service. The
client makes this determination by querying the End
Point Mapper (EPM) service on the target server. The
EPM listens on two ports: TCP port 135 and TCP port
593. A tool in the Windows 2003 Support Tools called
Portqry lists the registered RPC endpoints on a server.
Here’s a partial listing showing an endpoint registration:
C:\>portqry -n w2k3-ex3 -p tcp -e
Querying target system called:
Attempting to resolve name to IP address...
Name resolved to 192.168.0.13
TCP port 135 (epmap service): LISTENING
Querying Endpoint Mapper Database...
Exchange 2003 Server STORE EMSMDB
==== End of RPC Endpoint Mapper query response ====
To support RPC over HTTP, these Exchange
services register an ncacn_http client protocol with
fixed TCP ports so that the RPC Proxy doesn’t
need to communicate with the EPM:
Information Store: port 6001
System Attendant: port 6002
Referral (RFR) service: port 6002
NSPI (Name Server Provider Interface): port
6004 (NSPI provides access to address lists.)
Deploying RPC over HTTP
To deploy RPC over HTTP in production, requires—as you can see in Figure
2—an extensive cast of characters:
RPC over HTTP clients. These clients must be running Outlook 2003 running
on either XP SP2 or XP SP1 with hotfix 331320.
Firewall. This can be any firewall capable of directing SSL/TLS
traffic to a server on the private side.
RPC Proxy server. This is a server running Windows 2003 with
RPC over HTTP installed and enabled.
Exchange 2003 mailbox and public folder servers. These servers
must be running Windows 2003 with RPC over HTTP installed and enabled.
Windows Server 2003 Global Catalog servers. Any GC that might
be referred to an Outlook client by an Exchange server must be running
Windows 2003 and have RPC over HTTP installed and enabled.
|Figure 2. Diagram of a production deployment
of RPC over HTTP to support Outlook 2003 and Exchange 2003. (Click
image to view larger version.)
In addition, the Outlook clients must have some way of resolving the
name of the RPC Proxy server into an IP address. You have a couple of
options in this regard. You can configure a local Hosts file on each client;
but a better solution is to put host records in your public DNS zone that
have the RPC Proxy server’s name and the IP address of the firewall’s
public interface. You don’t need public host records for internal Exchange
servers because the proxy server finds them using internal DNS.
Configure the RPC Proxy Server
Outlook requires the use of SSL/TLS, so the Web services running on the
RPC Proxy server must have an X.509 certificate. You can use a Windows
Certification Authority to issue the certificate or obtain a third-party
certificate. The third-party certificate must be issued by a Certification
Authority trusted by the client.
Figure 3 shows the Authentication configuration window for the RPC virtual
folder on the RPC Proxy server. The virtual folder must reject Anonymous
|Figure 3. The Authentication Methods window for
the RPC virtual folder, showing blocked access for anonymous users.
Figure 4 shows the Secure Communications window for the RPC virtual folder.
The folder must accept only Secure Channel (SSL) connections using 128-bit
encryption. This prevents users from inadvertently supplying credentials
over a non-secure path.
|Figure 4. The Secure Communications window for
the RPC virtual folder, showing the requirement to use SSL and 128-bit
encryption. (Click image to view larger version.)
Because the RPC Proxy server must route incoming messages to the correct
service port on the Exchange and Global Catalog servers, the server’s
Registry must be configured with the server names and ncacn_http port
numbers. Here’s the Registry information:
Key: HKLM | Software | Microsoft | RPC | RPCProxy
Data: **See Below
The format for the ValidPorts entries specify a name and port number
in the format: : ; for example, W2K3-EX1:6001.
An Exchange server listens for ncacn_http requests on ports 593, 6001, 6002
and 6004. Each port requires its own entry, although contiguous ports can be
joined with a dash; for example, W2K3-EX1:6001-6002.
To make things even more complicated, the RPC Proxy service doesn’t
automatically append DNS suffixes onto flat names, so each port must be
entered in ValidPorts twice, once with the server’s flat name and
once with its fully qualified DNS name. Here’s an example for a
single Exchange server:
The entry for a GC would look like this:
If the thought of typing all those
entries for several servers (or several dozen, or several hundred) makes
you want to say, “Not in this lifetime,” don’t give
up hope. Microsoft has a Visual Basic script called Rpchttp_setup.vbs that finds all the Exchange and GCs in your organization and
adds them to the ValidPorts value on a designated RPC Proxy server. Like
so many nifty tools, this one comes from the friendly folks at Microsoft
Product Support Services. The script may be published on Microsoft’s
Web site by the time you read this. If not, contact PSS for a copy.
Configuring NSPI at Global Catalog Servers
Modern Outlook clients such as Outlook 2003 don’t send their address list requests
to Exchange, because they know Exchange doesn’t own the directory service. Instead,
they send their address list requests directly to the Name Service Provider
Interface (NSPI) port on a GC.
service uses a dynamically registered port. Because the RPC Proxy requires
a fixed port, you must configure a Registry entry on each GC to lock the
port at a fixed value. Microsoft recommends using TCP port 6004. Here’s
Key: HKLM | System | CurrentControlSet | Services |
NTDS | Parameters
Value: NSPI Interface Protocol Sequences
Type: Reg_Multi_SZ (multi string)
The Rpchttp_setup.vbs script doesn’t make Registry changes to GCs.
You must do this update separately. If you don’t feel like manually
adding the change to every GC, try using the Reg utility that accompanies
Windows 2003. The following syntax makes the required Registry change
to the specified server (the entire command should be on one line):
reg add \\<server_name>\hklm\system
/v “NSPI Interface Protocol Sequence”
/t REG_MULTI_SZ /d ncacn_http:6004
By putting this command in a batch file and feeding it a list of your
GCs, you can do the updates in a single step.
Configuring Outlook for RPC over HTTP
At last we’ve arrived at the Outlook client itself. Recall that
it must be running on XP SP2, or SP1 with hotfix 331320.
1. From the main menu, select Tools | E-mail Accounts.
This opens the -mail Accounts window.
2. Select the View or Change Existing E-mail Accounts radio button and
3. In the list of e-mail accounts, highlight Microsoft Exchange Server
and click Change.
4. In the Exchange Server Settings window, click More Settings. This opens
the Microsoft Exchange Server window.
5. Select the Connection tab.
6. Check the Connect To My Exchange Mailbox Using HTTP option.
7. Click Exchange Proxy Settings. This opens the Exchange Proxy Settings
8. In the Connection Settings field, enter the fully qualified DNS name
of the RPC proxy server. This can be th ename of the front-end server
or Exchange server. The format for the name you enter here must match
the format of the name in the SSL certificate exactly. If it doesn’t,
the connection will fail with no error messages. For example, the entry
might use a Fully Qualified DNS Name (FQDN) of W2K3-FE1.Company.com. If
the SSL certificate has the name W2K3-FE1, the connection will fail. There
are no error messages, so this type of problem can be tough to troubleshoot.
9. In the Proxy Authentication Settings field, select NTLM Authentication
from the drop-down menu. This gives a seamless experience to the user
by taking the current logon credentials and using them to connect to the
RPC Proxy server. For configurations involving home computers or non-domain
members, use Basic authentication. Using NTLM authentication requires
a Registry change.
Key: HKLM | System | Current
ControlSet | Control | LSA
Data: 3 (REG_DWORD)
Test with Outlook
At this point, you’re ready to launch Outlook and make the connection.
If you get prompted over and over and over again for credentials, check
the server name format on the certificate from the RPC Proxy server. Here’s
a quick way to make this check. Open a browser at the client and enter
the secure path to the RPC virtual folder in IIS. An example of the syntax
If the port on the firewall is configured correctly and the SSL configuration
at the server is correct, you should connect and get a 403.2 error, indicating
Access Denied. That’s because the browser requests Read access to
a folder that only permits Execute. This is exactly what you want to see.
If you get a 404 error, indicating that the client can’t find the
server, then you have a DNS problem. Double-click the little padlock in
the status bar to view the certificate received from the server. Verify
that the server name format matches the format you used when you configured
To make sure you’ve actually made an HTTPS
connection rather than a standard TCP/IP connection, use a nifty new feature
in Outlook 2003. Hold the Ctrl key down, right-click the Outlook icon
in the Notification Area and select Connection Status from the flyout
menu. This opens a Connection Status window, as shown in Figure 5. This
window should show an HTTPS connection for each Mail, Directory and Public
|Figure 5. The Outlook 2003 Connection Status
window, showing HTTPS connections to mailbox servers, public folder
servers, and Global Catalog servers. (Click image to view larger version.)
Ready to Rock and Roll
I have to admit that I was a little skeptical of RPC over HTTP when I
first heard about it, because it sounded like yet another way to multiplex
unmanaged services through Port 80 of a firewall. But the implementation
for Outlook 2003 appears secure. By requiring SSL/TLS connections and
by using an RPC Proxy server in the DMZ to avoid exposing an Exchange
mailbox server, it’s possible to build an infrastructure that provides
a truly useful service to users without compromising security. I highly
recommend trying it out in your lab as you decide how and when you’ll
deploy Exchange 2003 and Outlook 2003.