SQL Server Magazine

(Although this command appears on several lines here, enter it on one line in the command-shell window. The same holds true for the other multiline commands in this article.) Admittedly, this command is complex, so let's take a look at each argument:

• The -t argument specifies one of three protocol sequences: ncacn_http, ncacn_ip_tcp, or ncacn_np. For RPC over HTTP connections, you need to specify ncacn_http.
• The -s argument specifies the back-end Exchange server, where ExchangeServer is that server's name.
• The -o RpcProxy= argument specifies the RPC proxy server, where ProxyServer is that server's name.
• The -P argument specifies the account to be used to authenticate with the RPC proxy server. To provide the necessary information, you can use one of two formats: "username,domain,*" (if no password is required) or "username,domain,password" (if a password is required), where username is the user's name, domain is the user's domain, and password is the user's password.
• The -I argument specifies the account to be used to authenticate with the Exchange server. Again, you use either the "username,domain,*" or "username,domain,password" format to provide the necessary information.
• The -H argument specifies the RPC proxy server's authentication scheme. You can specify 1 for NT LAN Manager (NTLM) authentication or 2 for Basic authentication. For this example, I specified 1 because I was testing a network link that supported NTLM.
• The -u argument specifies the Security Support Provider (SSP). You can specify 9 (Negotiate), 10 (NTLM), 14 (Secure Channel), or 16 (Kerberos). Because I used NTLM for the authentication scheme, I specified 10 for this argument.
• The -a argument specifies the authentication level that is to be used to connect to the RPC proxy server. The possible values are connect, call, pkt, integrity, or privacy. For this example, I specified connect because I was testing a connection to the service.
• The -F argument specifies whether to use RPC over HTTP front-end authentication flags. You can specify 2 (no SSL flag) or 3 (use SSL flag). For this example, I specified 3 because I was using an SSL connection.
• The -v argument specifies the logging mode. You can choose between minimal logging (for which you specify 1), normal logging (2), or complete logging (3). I recommend complete logging because you'll get the most information.
• The -E argument restricts the connectivity test to the RPC proxy server only. (Note that there's also an -e argument, so letter case is important.)
• The -R argument specifies the local HTTP proxy server to be used, where HttpProxy is that server's name. If no local HTTP proxy server is to be used, you need to specify none instead of the server's name.

Figure 2 shows sample output from when I ran this command. Note the error message Error 12029 returned in the WinHttpSendRequest. Ping failed. This error message lets you know that a problem lies in the connection between the Outlook 2003 client and the RPC proxy server. "How to Use the RPC Ping Utility to Troubleshoot Connectivity Issues with the Exchange Over the Internet Feature in Outlook 2003" provides a helpful table that lists the error messages that RPC Ping might return and possible reasons for those error messages.

If you run this command and see Pinging successfully completed in the output, the RPC proxy server responded to the ping, which means the problem doesn't lie in the connection between the client and the RPC proxy server. In that case, the next step is to check the connection between the RPC proxy server and the back-end Exchange server. For this test, use the command

rpcping -t ncacn_http
  -s ExchangeServer
  -o RpcProxy=ProxyServer
  -P "username,domain,*"
  -I "username,domain,*"
  -H 1 -u 10 -a connect -F 3
  -v 3 -R HttpProxy

Note the absence of the -E switch. Because you don't want to restrict the connectivity test to the RPC proxy server, you don't include that switch.

To perform an RPC Ping against the Exchange Store endpoint, use the command

rpcping -t ncacn_http
  -s ExchangeServer
  -o RpcProxy=ProxyServer
  -P "username,domain,*"
  -I "username,domain,*"
  -H 1 -u 10 -a connect -F 3
  -v 3 -R HttpProxy
  -f Uuid,Ver

  

Note the addition of the -f switch. The -f switch specifies the interface to ping, where Uuid is that interface's universally unique identifier (UUID) and Ver is that interface's version number. UUIDs facilitate connections from other sources. In this case, the UUID is a4f1db00-ca47-1067-b31f-00dd010662d. If you don't specify a version number, RPC Ping uses version 1.0.

RPC Ping is an advanced troubleshooting tool that has intimidating command syntax. However, after you know which switches to use and how to use them, using RPC Ping is relatively straightforward and provides good insight into connectivity problems.

Outlook 2003 RPC tracing. To enable Outlook 2003's basic RPC tracing functionality, open Outlook 2003 and select Options from the Tools menu. Go to the Other tab, then click Advanced Options. Select the Enable mail logging (troubleshooting) check box. Close Outlook 2003, wait for a minute or so, then reopen it. From this point on, Outlook 2003 will generate events and log them in the client PC's Application event log.

More advanced RPC tracing functionality is possible if you create several registry entries and replace several DLLs on the client PC. In the registry, you must create the RpcTraceEnable, RpcStackTrace, RpcDumpToFile, and RpcOutputDir entries under the HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\RPC subkey. In the \Program Files\Common Files\System\MSMAPI\1033 directory, you need to replace the emsmdb32.dll, emsabp32.dll, emsui32.dll, and msmapi32.dll files with special versions of those DLLs. For more information about these modifications, contact PSS.

Look for the Usual Suspects
Using RPC over HTTP as a transport between Outlook 2003 and Exchange 2003 is a complicated process. For the most part, the complexity is transparent to the user, but occasionally the process doesn't run that smoothly. During the early stages of implementation, problems are generally the result of relatively simple configuration mistakes. Incorrect server information, incorrect registry entries, and unresolvable names are the usual culprits. Problems that occur after the system has been operating a while can be more difficult to diagnose. Under such circumstances, the problems are likely the result of a component in the infrastructure going out of service. If you look for the common causes that I've discussed, you'll probably have an easier time and more success with finding and implementing the solution.

End of Article

Prev. page     1 2 [3]     next page -->