The technique used to configure publishing rules for RPC over HTTP(S) are slightly different technique than those used with the OWA, OMA, and ActiveSync publishing rules, but the basic idea is still the same: to provide for reverse-proxied HTTP(S) access through the ISA Server, to secure the traffic sent back to Exchange. Before RPC over HTTP(S) can be secured with ISA Server, it must first be enabled in the Exchange Topology.
Client support of RPC over HTTP requires Outlook 2003 to be running on Windows XP SP2 (or Windows XP SP1 with the KB Article #331320 patch installed) or higher. The KB Article can be found at the following URL:
Installing the RPC over HTTP Proxy
The RPC over HTTP service requires the use of an RPC-HTTP proxy that assists in the management of RPC-HTTP requests to the Exchange mailbox server. This Proxy is normally installed on an Exchange front-end server, but can also be installed on a single all-in-one Exchange server that acts as both the back-end and front-end server, if special Registry changes are made to that server, as described in the following sections.
To install the RPC over HTTP service on the front-end or all-in-one back-end server, perform the following steps:
Configuring RPC over HTTPS on an Exchange Back-End Server
After the networking service for RPC over HTTP has been installed, the Exchange server must be configured to act as an RPC over HTTP back-end server. In the case of the all-in-one Exchange server, where there is no unique front-end server and a single Exchange server acts as the primary mailbox and OWA server for the enterprise, this configuration is performed on the Exchange server where the RPC over HTTP Networking Service was installed, and must be followed by the Registry change outlined in following sections.
In deployment scenarios where there are separate front-end and back-end servers, the back-end server must first be configured as an RPC over HTTP back-end, followed by configuration of the front-end server as an RPC-HTTP front-end. To configure the back-end server for RPC over HTTP, do the following:
The scenarios outlined in this book assume that Exchange Server 2003 Service Pack 1 is installed. SP1 adds a lot of configuration enhancements, including a much more simplified RPC over HTTP configuration. It is not recommended to use RPC over HTTP on pre-SP1 Exchange Server 2003 implementations, and the scenarios presented in this book will not be accurate without SP1 installed.
Configuring RPC over HTTPS on an Exchange Front-End Server
As previously mentioned, deployment scenarios involving separate hardware for Exchange front-end servers and Exchange back-end servers require the front-end server or servers to be configured as RPC over HTTP front-ends. In single all-in-one server deployments, this step can be skipped and the Registry change outlined in the next section of this chapter should instead be run.
That said, the following procedure enables an Exchange Server 2003 SP1 front-end server to act as a proxy for RPC-HTTPS traffic:
Modifying the Registry to Support a Single-Server Exchange RPC over HTTP Topology
As previously mentioned, if there is not a dedicated front-end server in the RPC-HTTP topology, then a special Registry change needs to be performed on the all-in-one Exchange server. To make this change, to the following:
Be sure that the Registry change is made to only back-end servers that do not have any front-end RPC-HTTP servers in the environment. This procedure is meant only for Exchange servers that serve dual roles as both front-end and back-end servers.
Creating the RPC Virtual Directory on the Proper Virtual Server
In certain scenarios, such as when a separate virtual server has been created for nonforms-based authentication traffic, the RPC virtual directory needs to be exported from the default OWA virtual server to the secondary virtual server, such as in the scenarios described in this chapter. To export and import this setting, do the following:
This procedure needs to be followed only if multiple OWA Virtual Servers have been created, and the RPC traffic will be directed at the one that doesn't currently have the \rpc virtual directory.
Securing RPC over HTTPS Servers with an ISA Publishing Rule
Securing an RPC over HTTPS proxy server involves publishing the RPC virtual directory as part of a publishing rule. This is typically done on the rule where OMA and ActiveSync have been set up, unless forms-based authentication is used, and then it is typically enabled on the standard OWA rule.
Once again, it is important to note that RPC over HTTP cannot utilize a Listener on a rule that uses forms-based authentication. Instead, it must utilize a basic authentication-enabled Listener. Consult the previous sections for more information on this.
To modify an existing ISA mail publishing rule to include RPC over HTTPS support, perform the following steps:
For access to an internal RPC over HTTP topology over the Internet, the server's host name must be published via external DNS so that it can be propagated across the Internet and made available for lookups.
Setting Up an Outlook 2003 Profile to Use RPC over HTTP
The final step involved with enabling RPC over HTTP support for clients is to configure the client Outlook 2003 mail profiles to use it as a service. First, ensure that Windows XP Service Pack 2 (or the hotfix for RPC over HTTP previously mentioned) is installed, along with the Outlook 2003 client. After it is verified, a mail profile can be created via the following procedure:
Unfortunately, the profile cannot be set up remotely, or at least not without RPC access to the Exchange server to create the initial connection. The initial creation of the profile itself should be performed on the Internal network, or somewhere with standard RPC access (essentially full network access) to the Exchange server. After it has been set up for the first time and all mail has been synchronized, it can then be sent out into the field indefinitely. The upside to this is that the initial synchronization of the offline folder settings, which can be quite extensive, can be done on a fast local network segment.
Outlook needs to be opened and the mailbox synchronized with the client at this point. After the full mailbox data has been copied locally, the system is free to roam around on the Internet, wherever HTTPS access back to the ISA server is granted.