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.
Prev. page
1
[2]
3
next page 
