Export (0) Print
Expand All

MAPI and RPC over HTTP

 

Topic Last Modified: 2005-05-23

When the Exchange Server transport service is configured in Microsoft Outlook, Outlook uses the MAPI to communicate with the Exchange Information Store service. These MAPI calls are all RPC-based. Although RPC calls work well in a LAN or WAN environment, they are generally discouraged for use over the Internet because of firewall and other security concerns. With earlier versions of Exchange, external Outlook users who wanted MAPI access to Exchange had to first establish VPN connections to their organization's private network.

The RPC Proxy runs on an IIS computer. It accepts RPC requests coming from the Internet, efficiently connects across the Internet to RPC server programs, and runs remote procedure calls without first requiring a VPN connection. It also performs authentication, validation, and access checks on those requests without opening multiple ports on your firewall. This is done with the help of an intermediary referred to as RPC-over-HTTP Proxy, or RPC Proxy.

If the request passes all tests, RPC Proxy forwards the request to the RPC server that performs the actual processing. With RPC over HTTP, the RPC client and server do not communicate directly. Instead, they use RPC Proxy as an intermediary.

RPC over HTTP enables client programs to use the Internet to run procedures that are provided by server programs on distant networks. RPC over HTTP routes its calls through an established HTTP port. Therefore, its calls can cross network firewalls on both the client and server networks. RPC Proxy is located on the RPC server's network. RPC Proxy establishes and maintains a connection to the RPC server. It serves as a proxy, dispatching remote procedure calls to the RPC server and sending the server's replies back across the Internet to the client program.

RPC over HTTP has both server-side and client-side requirements, which are detailed in the following table.

Requirements for implementing RPC over HTTP

Client-side requirements

Microsoft Windows XP Professional with Service Pack 1 or later

Hotfix from Microsoft Knowledge Base 331320

Microsoft Office Outlook 2003

Server-side requirements

Microsoft Windows Server 2003 on Exchange server

Exchange Server 2003 on all front-end and back-end servers

Windows Server 2003 on global catalog servers

Windows Server 2003 on RPC proxy servers

When the client program issues an RPC, using HTTP as the transport, the RPC run-time library on the client contacts RPC Proxy. Depending on whether the RPC client was asked to use HTTP or HTTPS, either TCP port 80 or TCP port 443 is used, respectively. RPC Proxy contacts the RPC server program and establishes a TCP/IP connection. The client and RPC Proxy maintain their HTTP or HTTPS connection across the Internet.

The client's HTTP or HTTPS connection to RPC Proxy can pass through a firewall (subject to appropriate access permissions) if a firewall is present. The server can then run the RPC and use the connection through RPC Proxy to reply to the client.

If either the client or the server disconnects for any reason, RPC Proxy detects that the connection has been severed, and ends the RPC session. As long as the session continues, RPC Proxy maintains its connections to the client and the server. It forwards RPCs from the client to the server, and sends replies from the server to the client.

The RPC client program can route its RPC calls over the Internet by creating a string binding of the following form:

[object_uuid@]ncacn_http:rpc_server[endpoint,HttpProxy=proxy_server:http_port,'rpcproxy'=rpc_proxy:rpc_port]

Where:

  • object_uuid specifies an RPC object universal unique identifier (UUID).

  • ncacn_http selects the protocol sequence specification for RPC over HTTP.

  • rpc_server is the network address of the computer that is running the RPC server process. The server address must be specified in a form visible and understandable by RPC Proxy computer, rather than by the client. Because the client does not connect directly to the server, it does not resolve the name of the server or establish a connection to it. RPC Proxy establishes the connection on the client's behalf. Therefore, rpc_server must be a name recognizable by RPC Proxy.

  • endpoint specifies the TCP/IP port that the RPC server process listens to for RPCs.

  • HttpProxy optionally specifies an HTTP proxy server on the RPC client's network, such as Microsoft Proxy Server. If a proxy server is selected, no port number is specified, the RPC stub uses port 80 by default if SSL is not requested, and port 443 if SSL is specified.

  • RPCProxy specifies the address and port number of the IIS computer that acts as a proxy to the RPC server. You need to specify this only if the RPC server process resides on a different computer than RPC Proxy. If you do not specify a port number, by default the RPC client stub uses port 80 if SSL is not specified and port 443 if SSL (HTTPS) is specified.

Although RPC over HTTP is a Windows Server 2003 feature and not an IIS feature, it is implemented as an Internet Server Application Programming Interface (ISAPI) extension that runs inside a protocol virtual server. The RPC virtual directory is created under Default Web Site when RPC Proxy service is installed. You should use SSL together with Basic Authentication.

While RPC over HTTP is implemented as a protocol virtual server, ExIPC is not involved in the communication process. Outlook clients using RPC over HTTP are treated as conventional MAPI clients, and they communicate with the Microsoft Exchange Information Store service using the MAPI interface to the Exchange information store.

 
Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft