Exchange Server 2003 lets you use Messaging API (MAPI) Remote Procedure Call over HTTP (RPC over HTTP—commonly referred to as Outlook over HTTP) to connect Microsoft Office Outlook 2003 to an Exchange server. When Microsoft released Exchange 2003, users lauded this functionality because they could finally connect Outlook to Exchange over more or less any network. However, the feature's administration capabilities were weak. The initial configuration was both tedious and error-prone; many registry keys required configuration on RPC proxy servers, domain controllers (DCs), and Global Catalog (GC) servers. Furthermore, ongoing administration was cumbersome, especially when you added or removed Exchange servers. (For information about general requirements and which registry keys you need to configure for RPC over HTTP before you install Exchange 2003 Service Pack 1—SP1, see the Windows IT Pro article "Exchange 2003 RPC over HTTP," September 2003, InstantDoc ID 39770. For information about troubleshooting RPC over HTTP configurations, see "Troubleshooting RPC over HTTP Connections," August 2004, InstantDoc ID 42877.)
Exchange 2003 SP1 alleviates these problems. You can now use the so-called managed RPC over HTTP topology to implement RPC over HTTP, and ongoing environmental changes, such as adding or removing servers, are automatically reflected in the configuration. These new features make RPC over HTTP more useful than ever.
RPC over HTTP Architecture Changes
Before Microsoft released Exchange 2003 SP1, the term RPC proxy server referred to a Windows Server 2003 server with RPC over HTTP installed (typically via the Control Panel Add or Remove Programs applet's Add/ Remove Windows Components option). The RPC proxy server didn't need to—and generally didn't—run Exchange 2003. An Outlook 2003 client made a connection to the RPC proxy server (often through a firewall), and the RPC proxy server contacted a DC or GC server, authenticated the user's connection request, then made a proxy connection from the Outlook 2003 client to the appropriate Exchange 2003 mailbox server, where subsequent Exchange authentication took place. Assuming that the authentications were successful, all further communication between Outlook and Exchange for the duration of the session took place via the RPC proxy server. With the initial connection request, the Exchange 2003 mailbox server issued a Global Address List (GAL) referral for the GC server to the Outlook 2003 client. Because Outlook couldn't connect to the GC server directly, the RPC proxy server also made a proxy connection on behalf of the Outlook client, as Figure 1 shows.
In that mode of operation, you had to specifically define the GC servers that the RPC proxy server would use to provide RPC over HTTPbased GAL access. To do so, you had to modify the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\RpcProxy\Valid Ports registry subkey on the RPC proxy server with connection and port details for specific GC servers. You then had to create the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\NSPI Interface Protocol Sequences registry subkey for the GC servers and modify its value to accept RPC over HTTP connections from the RPC proxy server.
With Exchange 2003 SP1's managed RPC over HTTP topology, you no longer have to set these subkeys, as long as you meet some prerequisites. For a supported configuration, you have to co-locate the Windows 2003 RPC over HTTP proxy component on your Exchange 2003 front-end servers. The RPC proxy server that Figure 1 shows then changes from a server that runs only Windows 2003 to a server that runs Windows 2003 and Exchange 2003, as Figure 2 shows.
In the managed RPC over HTTP topology, the Exchange 2003 front-end server (which performs the RPC proxy server function) doesn't hold any GC server configuration information in the ValidPorts subkey. When the Exchange 2003 front-end RPC proxy server makes an Outlook proxy connection to the Exchange 2003 mailbox server, one of two events will occur, depending on the mailbox server's version of Exchange 2003.
One, if the mailbox server is running Exchange 2003 SP1, the server detects that the Outlook client connection is using RPC over HTTP because the connection request comes from Microsoft IIS on the front-end server to the ncacn_http endpoint on the mailbox server. In this case, the mailbox server instructs the Outlook client to use the Directory Service (DS) proxy server on the mailbox server, which accesses the GC server on Outlook's behalf rather than referring Outlook directly to a GC server. This new functionality in Exchange 2003 SP1 reprioritizes how RPC over HTTP clients are assigned a GC server.
Two, if the mailbox server is running Exchange 2003 and hasn't yet been upgraded to SP1, the server initially attempts to refer the Outlook client directly to a GC server, as usual. The Outlook client dutifully attempts to reach the GC server via the RPC proxy service on the Ex-change 2003 front-end server, but because the front-end server doesn't have any configuration information to allow an RPC over HTTP connection to any GCs, the connection attempt fails. The Outlook client again requests a connection to a GC server from the mailbox server, but because the mailbox server recognizes that the first referral attempt failed, it instead offers the DS proxy mechanism and provides access to a GC server.
Although both mechanisms achieve the desired result, the second mechanism incurs some extra delay as the timeout for the initial referral takes place. As a best practice, Exchange 2003 front-end, mailbox, and back-end servers should all run SP1.
The Managed RPC over HTTP Topology
To use SP1's automatic RPC over HTTP configuration capabilities, you need to run SP1 only on the Exchange 2003 front-end server. Running SP1 on the mailbox or back-end server is optional (but note my earlier comment about the failover from referral to proxy mechanisms with non-SP1 back-end systems).
Figure 3 shows the new RPC-HTTP tab. To access this tab from the Exchange server Properties dialog box, you also must use Exchange System Manager (ESM) from an Exchange 2003 SP1 server or workstation that's running the Exchange 2003 SP1 administration tools.
The first configuration step is selecting each back-end server in the organization that you want to participate in the managed RPC over HTTP topology and selecting the RPC-HTTP back-end server property for that server. When you do so, you set the 0x20000000 bit on the Heuristics attribute of this Exchange 2003 mailbox server in Active Directory (AD). In addition, you need to set the mailbox server's ServerRole attribute to 0 because the server is a back-end server. You need to perform this task for every mailbox server that you want to participate in the managed RPC over HTTP topology.
After you configure all the required back-end servers, configure the front-end servers to participate in the managed RPC over HTTP topology. Use ESM to select the server that you want to act as your Exchange front-end server and to perform the RPC proxy function. This server must run Exchange 2003 SP1 and must have been previously configured as a conventional front-end server or the front-end server option will appear shaded on the RPC-HTTP tab, as Figure 3 shows. On the RPC-HTTP tab, select RPC-HTTP front-end server and repeat these steps for all the front-end servers that you want to act as RPC proxy servers. Performing this task makes the same changes to the Heuristics attribute on the front-end server, but the front-end server's ServerRole attribute will have a value of 1.
When you've set the appropriate AD attributes on the front-end and back-end servers, the managed RPC over HTTP topology is essentially in place. Exchange 2003 SP1 includes an updated System Attendant function. On front-end servers that are part of the managed RPC over HTTP topology, the System Attendant scans AD every 15 minutes to locate Exchange 2003 back-end servers whose Heuristics values are configured to make them part of the managed topology. On the front-end server, the System Attendant updates the ValidPorts subkey for each participating back-end server that it discovers. The beauty of this approach is apparent when you add new Exchange 2003 back-end servers to the environment. As long as you configure them to participate in the managed RPC over HTTP topology by selecting the appropriate radio button, the front-end servers automatically detect the back-end servers and keep the configuration up-to-date. Similarly, if you add new front-end servers to your environment and configure them to participate in the managed topology, they automatically detect all relevant back-end servers.
Upgrading an Existing RPC over HTTP Configuration
If you already use RPC over HTTP in Exchange 2003 and use an Exchange 2003 front-end server as an RPC proxy server, your configuration won't change when you upgrade front-end or back-end servers to SP1. The managed RPC over HTTP topology is enabled only when you select and configure servers by using the RPC-HTTP properties, as Figure 3 shows.
If you want to enable the managed RPC over HTTP topology, first configure all back-end servers, then wait for the changes to the AD Heuristics attributes to replicate. This process could take 15 minutes or several hours, depending on your AD environment's complexity and topology. Only after the changes are replicated should you configure Exchange 2003 SP1 front-end servers to act as RPC over HTTP front-end servers. When you do so, any existing values that you might have manually configured in the ValidPorts subkey on your front-end server will be overwritten with the automatically determined values. The original ValidPorts value will be written to a file in the \system32 directory on the front-end server's system drive, and you'll see the message that Figure 4shows.
The managed RPC over HTTP topology requires that you configure back-end servers first, allow time for AD replication, and only then configure front-end servers. If you deviate from this sequence, you run the risk of the front-end servers searching AD for back-end servers, finding none, and effectively setting a null ValidPorts value, thus disrupting service. Furthermore, any manual changes you make to the ValidPorts subkey on a managed-topology front-end server have an average lifespan of 7.5 minutes; the next time the System Attendant runs, your changes will be overwritten.
Automating the Initial Configuration
If you have a fully functioning RPC over HTTP environment in place before you upgrade to SP1, you can partially automate the managed RPC over HTTP topology configuration. This process is especially useful if you have multiple Exchange 2003 back-end servers and don't cherish the prospect of selecting each server and enabling it for the managed topology. You can write your own script to set the appropriate bit mask for the Heuristics attribute, then simply enable the front-end servers, which will detect the newly configured back-end servers.
Alternatively, you can download the unofficial Microsoft Exchange 2003 SP1 RPC-HTTP Topology Manager script from http://www.got dotnet.com/community/workspaces/workspace.aspx?id=4a0c34b7-d3dd-4789-91b7-6880ecc5f910. This useful script runs in three modes:
- Registry mode, in which the script reads the existing back-end servers that are already configured in the front-end server's ValidPorts subkey, then sets the Heuristics attribute on the back-end servers so that they're immediately discovered when the front-end server is enabled.
- Server List mode, in which the script reads a user-supplied text file to determine which servers to add or remove from the managed RPC over HTTP topology.
- Scan mode, in which the script searches AD to determine all the front-end and back-end servers whose Heuristics attributes are configured in the managed RPC over HTTP topology configuration.
Compelling Reasons for Implementation
Exchange 2003's RPC over HTTP functionality is undoubtedly a great asset. From an administrator's perspective, the SP1 managed RPC over HTTP topology improvements make the implementation of this access technology more compelling than ever. The price is small; at the most, you'll need some additional hardware and licenses if you don't already have suitable Exchange 2003 front-end servers. If you've been holding off deploying RPC over HTTP until Microsoft shook out the technology's bugs and polished its operation, now's the time to put it to work.
