Recommendations for Deploying RPC over HTTP Communications

  • Article

 

In this topic, we discuss best practices to follow when deploying RPC over HTTP communications in Exchange Server 2003 Service Pack 1 (SP1).

Best Practices to Follow When Deploying RPC over HTTP

We recommend the following when you use Exchange with RPC over HTTP:

  • Use basic authentication over Secure Sockets Layer (SSL).

    We recommend that you enable and require the use of SSL on the RPC proxy server for all client-to-server communications. The HTTP session should always be established over Secure Sockets Layer (SSL) (port 443). For information about RPC over HTTP authentication using SSL, see RPC over HTTP Authentication and Security.

    Note

    Although RPC over HTTP does not require SSL, you must modify the registry to enable RPC over HTTP if you do not want to use SSL. We recommend that you enable and require SSL for your RPC over HTTP communications. For more information, see Microsoft Knowledge Base article 833003, "Description of the RPC over HTTP feature and the AllowAnonymous registry entry in Windows Server 2003," and How to Configure the RPC Proxy Server to Allow for SSL Offloading on a Separate Server.

  • Use an advanced firewall server on the perimeter network.

    We recommend that you use a dedicated firewall server to help enhance the security of your Exchange computer. Microsoft Internet Security and Acceleration (ISA) Server 2000 is an example of a dedicated firewall server product. For additional information, see Positioning Your RPC Proxy Server and Firewalls in a Corporate Environment.

  • Obtain a certificate from a third-party certification authority (CA).

    To enable and require SSL for all communications between the RPC proxy server and the Outlook clients, you must obtain and publish a certificate at the default Web site level. We recommend that you purchase your certificate from a third-party certification authority whose certificates are trusted by a wide variety of Web browsers.

    Important

    As an alternative, you can use the Certification Authority tool in Windows to install your own certification authority. By default, Web browsers do not trust your root certification authority in this scenario. When a user tries to connect in Outlook 2003 by using RPC over HTTP, that user loses the connection to Exchange. The user is not notified. The user loses the connection when one of the following conditions is true:

    • The client does not trust the certificate.

    • The certificate does not match the name that the client tries to connect to.

    • The certificate date is incorrect.

      Therefore, you must make sure that the client computers trust the certification authority. For more information about how to trust a root certification authority, see the Microsoft Knowledge Base article 297681, Error message: This security certificate was issued by a company that you have not chosen to trust.

      For additional information, see Policies to establish trust of root certification authorities.

      Additionally, if you use your own certification authority, when you issue a certificate to your RPC proxy server, you must make sure that the Common Name field or the Issued to field on that certificate contains the same name as the URL of the RPC proxy server that is available on the Internet. For example, the Common Name field or the Issued to field must contain a name that is similar to mail.contoso.com. The Common Name field or the Issued to field cannot contain the internal fully qualified domain name of the computer. For example, those fields cannot contain a name that is similar to mycomputer.contoso.com.

For More Information

For more information, see the following topics in the Exchange Server 2003 RPC over HTTP Guide:

For information about configuration options for the Exchange over the Internet feature, see Microsoft Knowledge Base article 831050, Description of the configuration options for the Exchange over the Internet feature in Outlook 2003.