Windows IT Pro is the leading independent community for IT professionals deploying Microsoft Windows server and client applications and technologies.
  
  
  Advanced Search 


September 2003

Exchange 2003 RPC over HTTP Access

Use Outlook 2003 to get to your Exchange mailbox from any network
RSS
Subscribe to Windows IT Pro | See More Security Articles Here | Reprints | Or get the Monthly Online Pass—only $5.95 a month!

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.

   Previous  1  [2]  3  Next 


Top Viewed ArticlesView all articles
Command Prompt Tricks

One reader shares his tip for setting up the command prompt to reflect a remote path. ...

WinInfo Short Takes: Week of November 9, 2009

An often irreverent look at some of the week's other news, including some more Windows 7 sales momentum, some Sophos stupidity, Microsoft's cloud computing self-loathing, more whining from the browser makers, Zoho's "Fake Office," and much, much more ...

Understanding File-Size Limits on NTFS and FAT

A general confusion about files sizes on FAT seems to stem from FAT32's file-size limit of 4GB and partition-size limit of 2TB. ...


Security Whitepapers Reducing the Costs and Risks of Branch Office Data Protection

Solving Desktop Management Challenges in Healthcare

Solving Desktop Management Challenges in Education

Related Events WinConnections and Microsoft® Exchange Connections

Check out our list of Free Email Newsletters!

Security eBooks Spam Fighting and Email Security for the 21st Century

Understanding and Leveraging Code Signing Technologies

A Guide to Windows Certification and Public Keys

Related Security Resources Introducing Left-Brain.com, the online IT bookstore
Looking for books, CDs, toolkits, eBooks? Prime your mind at Left-Brain.com

Discover Windows IT Pro eLearning Series!
Clear & detailed technical information and helpful how-to's, all in our trademark no-nonsense format


Windows IT Pro Home Register FAQ for Windows WinInfo News
Europe Edition About Us Contact Us/Customer Service Media Kit Affiliates / Licensing  
SQL Server Magazine Office & SharePoint Pro DevProConnections IT Job Hound
Left-Brain.com Technology Resource Directory asp.netPRO ITTV Windows SuperSite 
 
 Windows IT Pro is a Division of Penton Media Inc.
 © 2009 Penton Media, Inc. Terms of Use | Privacy Statement