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.