Useful Tips

Troubleshooting HTTP RPC Connections

Pin
Send
Share
Send
Send


As you know, Outlook 2007/2010 can connect to the Microsoft Exchange server using the MAPI and HTTPS protocols. The first is designed to work inside the corporate network, the second for remote connections. Outlook selects the connection protocol from the bandwidth of the channel, and the metering is not actually done, and the settings are taken from the network adapter, if the speed is lower than 128K, then the connection is considered slow and the connection will be established via HTTPS. And if the connection to the server via MAPI is lost, then Outlook will try to establish a connection via HTTPS. And if the server is configured for basic authentication, then password entry windows may appear, which is very annoying for users.

How to avoid this? Typically, Outlook is configured using group policies using the "Outlook 2010 Group Policy template." But the Outlook Anywhere settings there are very poor and you can’t change the logic of Outlook work with a standard template. Microsoft offers the following solution.

You must apply additional administrative templates to the policies described below.

In principle, there is no point in using HTTPS inside the corporate network, only server configuration becomes more complicated and authorization windows may appear.

Prerequisite Check

To establish RPC connections over HTTP, a number of prerequisites must be met, and the diagnostic process must first verify that these conditions are met. The first of these is that Outlook 2003 and Windows XP Service Pack 2 (SP2) or XP SP1 must be installed on the client computer with the corresponding correction program, 331320, which eliminates problems with client delays. This program is described in more detail in the Microsoft article “Outlook 2003 Performs Slowly or Stops Responding When Connected to Exchange Server 2003 Through HTTP” at http://support.microsoft.com/?kb>

To verify that the machine has the correct version of the correction program, you can check the version of the rpcrt4.dll file in the \% windir% system32 directory on the client computer. You should find the rpcrt4.dll file in Windows Explorer, right-click on it and select Properties. In the Properties dialog box, click on the Version tab and select File Version from the Item name list. Version 5.1.2600.1142 or newer is required.

The second prerequisite: the RPC proxy server must run on Windows Server 2003, as well as the domain controllers (DC) or Global Catalog servers (GC) that the RPC proxy server uses to authenticate the client connection. Any GC servers that the user can be redirected to should also work with Windows 2003. The internal (back-end) Exchange server and any other Exchange servers (for example, public folder servers) should also work on Windows 2003 and Exchange 2003. Therefore The simplest rule is to leverage Windows 2003 and Exchange 2003 across your entire infrastructure.

Connection Type Check

The purpose of the RPC over HTTP method is to simplify the organization of connections between Outlook 2003 and Exchange 2003 for the end user. This means that the user should not notice the difference between the RPC connection over MAPI and the RPC connection over HTTP. Therefore, if Outlook 2003 cannot establish an RPC connection over HTTP, the program automatically switches to TCP / IP and tries to establish an RPC connection via MAPI.

This method is convenient when operating Exchange in normal mode, but it can be an annoying obstacle when you first try to organize RPC access via HTTP. The protocol switching process is completely invisible, and it is unclear whether the RPC connection via HTTP is activated or after its failure the RPC connection via MAPI is activated.

There is a simple technique by which a user of a client computer with Outlook 2003 can determine how to connect to the Exchange server. While holding down the Ctrl key, you should right-click on the Outlook icon in the system panel and select Connection Status. The Connection Status dialog box appears, indicating the type of connection that is currently being used.

To configure an RPC over HTTP connection, you can disable automatic protocol switching. To do this, you need to edit the registry on the client computer with Outlook 2003. In the HKEY_CURRENT_ USERSoftwareMicrosoftOffice11.0RPC section, create the DisableRpcTcpFallback parameter and set it to DWORD value 1 to block RPC / TCP switching. After making sure that the system is working correctly, you must enable the switch by setting the DisableRpcTcpFallback parameter to 0.

Checking client configuration

Microsoft has released two versions of RPC over HTTP - Version 1 and Version 2 - with various capabilities. Outlook 2003 uses RPC over HTTP Version 2, which requires the client to work with Secure Sockets Layer (SSL) and the connection is authenticated by an RPC proxy server. Therefore, you need to check the configuration of the MAPI client profile, which must be configured to use SSL, and correctly identify the RPC proxy server.

To verify the configuration, open Outlook 2003. In the Tools menu, select the E-mail Accounts item. After making sure that View or change existing e-mail accounts is selected, click the Next button. Then you need to select the appropriate account and click on the Change, More Settings buttons. The Microsoft Exchange Server dialog box appears in which you need to go to the Connection tab and select the Connect to my Exchange mailbox using HTTP check box.

Then click on Exchange Proxy Settings to open the dialog box shown on screen 1. This should be checked Mutually authenticate the session when connecting with SSL. By checking the box, you need to add the msstd: prefix to the name of the RPC proxy server in the Principal name for proxy server field.

Screen 1. Checking client configuration

Please note that the first contact point for the Outlook client can be a local HTTP proxy server, for example Microsoft Internet Security and Acceleration (ISA) Server 2000. In this case, make sure that this server (and not the RPC proxy server) is listed in the dialog Exchange Proxy Settings window. In addition, you must ensure that the local HTTP proxy server correctly routes connections to the RPC proxy server. For ISA Server 2000, you can verify connections by examining the log files.

Below the Principal name for proxy server field is the On fast networks, connect using HTTP first, then connect using TCP / IP checkbox ("In fast networks, first establish a connection using HTTP, then try to connect using TCP / IP") and the On slow check box networks, connect using HTTP first, then connect using TCP / IP ("On slow networks, first establish a connection using HTTP, then connect using TCP / IP"). By default, these check boxes are set for the switches described above. Slow connections are those with a data transfer rate of no more than 115 Kbps.

Along with configuring the client MAPI profile, you need to make sure that the Outlook 2003 client can establish an SSL connection to the RPC proxy server. You can do this by opening Microsoft Internet Explorer (IE) and establishing a connection https: // RpcProxyServer / RPC, where RpcProxyServer is the name of the RPC proxy server. HTTP Error 403.2 Forbidden: read access is denied error message means that the connection to the RPC Virtual Directory in Microsoft IIS on the RPC proxy server has been established. The error message is displayed because, although the client has the necessary permissions to connect to the RPC Virtual Directory, it does not have sufficient read permissions in this directory.

Checking server configuration

The article “Remote access to Exchange 2003 via HTTP channels” describes the basic server configuration settings for RPC access via HTTP, so I won’t repeat it. Instead, we will look at the main server problems that interfere with the correct operation of RPC connections over http.

  • Invalid ValidPorts parameter value. The ValidPorts parameter in the HKEY_LOCAL_MACHINESOFTWAREMicrosoft RpcRpcProxy RPC proxy server section must specify all Exchange servers, domain controllers, and GC servers with which the RPC proxy server communicates. If the RPCHTTP_Setup.vbs script, which can be obtained from Microsoft Product Support Services (PSS), is used to organize RPC connections over HTTP, then all host and port names must be correct. However, if RPCHTTP_Setup.vbs was not used, then you need to check the host and port names. In addition, you should make sure that the RPC proxy server provides translation of all the names specified in the ValidPorts element, and that the certificate provided by the RPC proxy server is valid.
  • Incorrectly configured internal Exchange server. The necessary registry settings for the internal Exchange server are automatically configured during the installation of Exchange 2003, so there should be no problems with the configuration. But the port settings of the internal Exchange server must be consistent with the port settings of the ValidPorts RPC proxy element. In addition, you need to remember that a new property has appeared in Exchange 2003 SP1 that allows you to configure the Exchange server as an RPC proxy server. This multipurpose server is called an external RPC-HTTP server. Thus, if there is a separate RPC proxy server, then the RPC-HTTP back-end server parameter (and not the RPC-HTTP front-end server parameter) should be selected. Access to the new property can be obtained through the Exchange System Manager (ESM). Just right-click on the Exchange server, select Properties and click on the RPC-HTTP tab.
  • Incorrect configuration of domain controllers or GC servers. If the RPC proxy server establishes connections with any DCs or GC servers, then the NSPI Interface Protocol Sequences parameter must be manually added to the HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ServicesNTDSParameters registry section of domain controllers or GC servers. This additional parameter is often a source of errors, so you should check its correctness on each DC and GC server. In addition, you need to make sure that the port settings of the GC servers are correct and consistent with the port settings in the ValidPorts RPC proxy server.

If the connection was not established, and there are no errors in the server configuration, then you can try restarting the server. Rebooting is a primitive trick, but sometimes it helps.

Connection check

You must ensure that communication between the RPC proxy server, the internal Exchange server, and the GC servers is possible. The most powerful tool for diagnosing RPC connections over HTTP is the RPC Ping utility from the Microsoft Windows Server 2003 Resource Kit. Outlook 2003 also has RPC tracing features that can help you troubleshoot communication channels.

RPC Ping. RPC Ping is a complex tool with many keys and qualifiers, with which you can find out if RPC requests achieve a specific goal (for example, a server) over a specified HTTP connection. For helpful information on RPC Ping, see Microsoft's article “How to Use the RPC Ping Utility to Troubleshoot Connectivity Issues with the Exchange By the Internet Feature in Outlook 2003” (http://support.microsoft.com/?kb>

Using RPC Ping, you can run several tests. In particular, confirm that the Outlook client can establish an RPC connection over HTTP with the RPC proxy server. To do this, use the command

The command is printed on several lines, but in the command window it should be entered in one. The same applies to the other multi-line commands in this article. The team is complex, so consider each of its arguments.

  • The -t argument specifies one of three protocol sequences: ncacn_http, ncacn_ip_tcp, or ncacn_np. For RPC connections over HTTP, ncacn_http must be specified.
  • The -s argument specifies the internal Exchange server, ExchangeServer is the name of the server.
  • The argument -o RpcProxy = indicates the RPC proxy server, ProxyServer is the server name.
  • The -P argument specifies the account used to authenticate the RPC proxy server. You can provide the necessary information in one of two formats: “username, domain, *” (if a password is not required) or “username, domain, password” (if a password is required), where username is the username, domain is the domain name, and password - user password.
  • The -I argument specifies the account that is used to authenticate with the Exchange server. The format “username, domain, *” or “username, domain, password” is also used to transmit the necessary information.
  • The -H argument specifies the authentication scheme of the RPC proxy server. You can specify 1 for the authentication type NT LAN Manager (NTLM) or 2 for the type Basic. In this example, I indicated 1 because I tested a network connection with NTLM.
  • The -u argument specifies the Security Support Provider (SSP). You can specify 9 (Negotiate), 10 (NTLM), 14 (Secure Channel), or 16 (Kerberos). Since I used the NTLM authentication scheme, 10 was selected for this argument.
  • The -a argument specifies the authentication level that is used to connect to the RPC proxy server. Possible values ​​are connect, call, pkt, integrity or privacy. In this example, the value connect is specified, since I tested the connection to the service.
  • The -F argument specifies whether to use external RPC authentication flags over HTTP. You can specify 2 (no SSL flag) or 3 (use the SSL flag). In this example, I have specified 3, because the SSL connection is used.
  • The -v argument indicates the logging mode. You can select the minimum mode (1), normal mode (2), or full logging (3). I recommend the full mode, because it can collect the most information.
  • The -E argument restricts the communication test to the RPC proxy server only. Note that the -e argument also exists, so case is significant.
  • The -R argument specifies the local HTTP proxy server, HttpProxy is the server name. If the local HTTP proxy server will not be used, you must specify none instead of the server name.

Figure 2 shows a sample execution of this command. Note the error message

Error 12029 returned in the WinHttpSendRequest. Ping failed. It indicates that the communication channel between the Outlook 2003 client and the RPC proxy server is faulty. The article “How to Use the RPC Ping Utility to Troubleshoot Connectivity Issues with the Exchange over the Internet Feature in Outlook 2003” provides a table listing the RPC Ping error messages and possible causes of these errors.

If the Pinging successfully completed message appears on the screen after running this command, then the RPC proxy server responded to the request, and the connection between the client and the RPC proxy server is fine. In this case, you must immediately check the connection between the RPC proxy server and the internal Exchange server. For testing you need to use the command

Note the absence of the -E switch. The key is missing, because the communication test should not be limited to the RPC proxy server.

Screen 2. RPC Ping Command Example

To route RPC Ping to an Exchange Store endpoint, use the command

The -f switch appeared in the command. It indicates an echo testing interface, where Uuid is the Universally Unique Identifier (UUID) and Ver is the interface version number. UUIDs provide connections from other sources. In this case, the UUID is a4f1db00-ca47-1067-b31f-00dd010662d. If no version number is specified, then RPC Ping uses version 1.0.

RPC Ping is a powerful diagnostic tool with a very complex command syntax. If you learn how to correctly use the necessary keys, working with RPC Ping is quite simple, and using the utility you can get a lot of useful information about the causes of the problems.

Outlook 2003 RPC tracing. To activate the basic functions of Outlook 2003 RPC tracing, open Outlook 2003 and select the Options item from the Tools menu. On the Other tab, click the Advanced Options button and select the Enable mail logging (troubleshooting) check box. Then you need to close Outlook 2003, wait about a minute, and reopen the program. From now on, Outlook 2003 will generate events and write them to the Application log on the client computer.

You can extend the RPC trace functions by creating several registry settings and replacing some DLLs on the client computer. In the registry, you need to create the RpcTraceEnable, RpcStackTrace, RpcDumpToFile and RpcOutputDir elements in the HKEY_CURRENT_USERSoftwareMicrosoftOffice11.0OutlookRPC section. In the Program FilesCommon FilesSystemMSMAPI1033 directory, replace the emsmdb32.dll, emsabp32.dll, emsui32.dll, and msmapi32.dll files with special versions of these DLLs. For more information about these changes, see PSS.

Typical culprits

RPC over HTTP functioning as a transport protocol between Outlook 2003 and Exchange 2003 is a complex process. Basically, the difficulties are hidden from the user, but the process does not always go smoothly. In the first stages of implementation, problems arise due to relatively simple configuration errors. Incorrect server information, invalid registry settings, and non-convertible names are common causes of malfunctions. Problems that arise in a running system are more difficult to diagnose. In such circumstances, problems most often arise due to the failure of infrastructure components. An analysis of the typical causes of malfunctions discussed in this article will help simplify and speed up troubleshooting.

Kieran McCorry ([email protected] ) - Chief Consultant, HP Consulting and Integration Technology Group, operates in Ireland. He is a co-author of Microsoft Exchange 2000 Infrastructure Design (Digital Press).

Share material with colleagues and friends

Pin
Send
Share
Send
Send