How to troubleshoot connectivity issues that are caused by RPC client protocol registry entries

This article discusses remote procedure call (RPC) protocol registry keys and how they can affect Microsoft Outlook connectivity to Microsoft Exchange Server. This article also discusses basic troubleshooting procedures.

Outlook uses RPCs to make calls to the network. RPCs permit Outlook to send calls to many different protocol stacks. The calls depend on the protocol stack that is available on the computer. The most common protocol is TCP/IP. Other RPC protocols include NetBIOS, NetBIOS over TCP/IP, and IPX/SPX. If a client computer sends the appropriate RPC protocol requests, the server must have those protocols available.

RPC protocol registry entries

This section describes the main registry entries that control the RPC protocol that Outlook uses.

RPC_Binding_Order

The RPC_Binding_Order entry is created when you install the Outlook client or Exchange Server. The RPC_Binding_Order entry determines the protocol sequence that is used when Outlook RPC communications are initiated.

Note The RPC_Binding_Order entry is not created in Microsoft Exchange Server 2003 or in Microsoft Exchange 2000 Server. This entry is only created in Microsoft Exchange Server 5.5 and in earlier versions of Exchange.

You can find this entry in the following registry key: By default, the Rpc_Binding_Order entry contains the following value data: For more information about how to modify or restore the binding order, click the following article number to view the article in the Microsoft Knowledge Base:

RPC_Srv_Binding_Order

The RPC_Svr_Binding_Order registry entry is created when you install the Outlook client or Exchange Server. Do not confuse this entry with the RPC_Binding_Order registry entry. This entry is not used with Outlook RPC connections. This entry determines the protocol sequence that is used for certain server-to-server communications. You can use the RPC Dump utility to determine the protocols that are available for the clients to use. For additional information about the RPC Dump utility, see the "Use RPC Dump to identify server RPC issues" section of this article.

You can find the RPC_Svr_Binding_Order entry in the following registry subkey:By default, the Rpc_Svr_Binding_Order entry contains the following value data: Note Other values may be present if additional protocols are installed.

ClientProtocols

The ClientProtocols registry subkey is created when you install the operating system and the first network protocol. The ClientProtocols registry subkey contains entries that determine the protocols that can be used by the client operating system to connect to Exchange Server. Outlook can determine the RPC protocol to send; this registry subkey determines if the operating system supports that protocol. You can find this subkey in the following registry key on Microsoft Windows 2000 and Microsoft Windows XP: By default, the ClientProtocols subkey contains the following registry entries for TCP/IP:Note In Microsoft Windows NT 4.0, the registry subkey location is the same, but the default TCP/IP entries are different. The following table describes the default TCP/IP entries for Windows NT:Note In Microsoft Windows 98, the subkey is in the same location, but the default TCP/IP entries are different. The following table describes the default TCP/IP entries for Windows 98:

Troubleshoot RPC registry entries

If one or more of the RPC registry entries are missing, Outlook may not connect to Exchange Server. If the ClientProtocols subkey or data values are missing, the Outlook client may not be able to use the expected protocol to connect. For Outlook to use the appropriate RPC protocol, the ClientProtocols subkey and data values must be present and accurate.

For example, on the computer that is running Outlook, if the only RPC ClientProtocols registry entry that is present is ncacn_np (with a value of rpcrt4.dll), Outlook tries to connect to the computer that is running Exchange Server by using named pipes over TCP/IP on the default port of 139. If the connection must traverse a firewall, port 139 must be open. The missing registry entry ncacn_ip_tcp (with a value of rpcrt4.dll) must be restored to support a TCP/IP connection that uses port 135 or port 445 to the Exchange Server.

Additionally, if the RPC registry entries are missing on the server, the Exchange services are not registered to respond to client requests. Therefore, the client cannot connect to Exchange by using the requested protocol. For example, if the server does not have the RPC ClientProtocols registry entry for ncacn_ip_tcp, the Microsoft Exchange Information Store is not available when you use TCP/IP to connect. You can use RPC Dump to troubleshoot this issue.

Outlook error messages

The following error messages may appear in the Outlook client when the RPC registry entries are missing or corrupted:

• The name could not be resolved. The Microsoft Exchange address book was unable to logon to the Microsoft Exchange Server computer.
• Outlook could not logon. Check to make sure you are connected to the network and are using the proper server and mailbox name.
• The name could not be resolved. Network problems are preventing connection to the Microsoft Exchange Server computer. Contact your system administrator if this condition persists.
• Your logon information was incorrect. Check your username and domain, then type your password again. If your account is new or if your administrator requested a password change you need to click Change Password then logon with your new password.
• Cannot Start Microsoft Outlook. The attempt to log on to the Microsoft Exchange Server computer has failed.
• The server containing the global address list is no longer available. You can reconnect to a different server by restarting Outlook or retry the operation when the server is reachable.
• The connection to the Microsoft Exchange Server is unavailable. Outlook must be online or connected to complete this action.

If RPC registry entries are missing or corrupted, the following issues may occur:

• Users receive new mail, but new mail notifications do not work. This issue may occur if RPC registry values for the User Datagram Protocol (UDP) are missing.
• Users cannot connect to the computer that is running Exchange Server.
• Users cannot verify an alias name in the Global Address List.
• Users are prompted to enter logon credentials several times, and then receive the error messages listed earlier in this article.
• Fax printers are not accessible.

Use Network Monitor to identify RPC issues

You can use Network Monitor to identify RPC-related issues. For example:

• If your captured trace does not contain any RPC traffic from the client to the server, the whole RPC subkey may be missing. If the subkey is present, make sure that the ncacn_ip_tcp entry (with a value of rpcrt4.dll) is not missing. If the ncacn_ip_tcp entry (with a value of rpcrt4.dll) is missing, the client does not try to connect to TCP/IP by using port 135. The client only tries connections that use NetBIOS or named pipes over TCP/IP (port 139 or port 445).
• If your captured trace shows the client successfully connecting to the endpoint mapper, the client successfully sends an RPC opnum0x3 request. The client receives a response where the last four pairs of hexadecimal data show the following: D6 A0 C9 16. Typically, this response contains zeros if the request is successful. This behavior may occur if the server is missing the ncacn_ip_tcp registry value in the ClientProtocols registry subkey. In this scenario, the Microsoft Exchange Information Store service is not available for use over TCP/IP.

For more information about how to analyze client network traffic by using Exchange Server, visit the following Microsoft Web site:

Use RPC Dump to identify server RPC issues

You can use the RPC Dump tool to troubleshoot server RPC issues. You can use the RPC Dump tool to list the RPC applications that are running on the server. There are three RPC components that must be available for the Outlook client to successfully connect:

• The endpoint mapper.
• The Microsoft Exchange Information Store service with the universal unique identifier (UUID) of a4f1db00-ca47-1067-b31e-00dd010662da.
• The Name Service Provider Interface (NSPI) with the UUID of f5cc5a18-4264-101a-8c59-08002b2f8426.
  • In Exchange Server 5.5 and earlier, the NSPI was provided by the Microsoft Exchange Directory Service.
  • In Exchange Server 2003 and in Exchange 2000 Server, the NSPI is provided by the global catalog server. On a global catalog server, the NSPI runs under the Net Logon service (lsass.exe). The Exchange server can provide NSPI referral and proxy functionality.
  For more information about NSPI and Outlook clients, click the following article number to view the article in the Microsoft Knowledge Base:
  256976  (http://support.microsoft.com/kb/256976/ ) How MAPI clients access Active Directory

You must run the RPC Dump tool from a command prompt. Common command-line commands include:

• rpcdump.exe /i > rpcdump.txt
• rpcdump.exe /p > rpcdump.txt

Both of these commands direct the output that is generated to the Rpcdump.txt file.

The RPC Dump tool is typically used together with Network Monitor. For example, if the Outlook client cannot successfully verify a name, you can run the RPC Dump tool on the server that provides the NSPI.

Note If f5cc5a18-4264-101a-8c59-08002b2f8426 is missing from a global catalog server for TCP/IP (ncacn_ip_tcp), the Outlook clients cannot connect to the NSPI over TCP/IP.

You can also use the RPC Dump tool when Outlook clients can successfully verify the names, but the Outlook clients cannot log on to the mailbox. By running the RPC Dump tool, you can determine if the store (a4f1db00-ca47-1067-b31e-00dd010662da) is registered with RPC with TCP/IP (ncacn_ip_tcp), Named Pipes (ncacn_np), or other protocols. This problem is typically caused by missing ClientProtocols registry entries on the server. The problem may also occur if both the NSPI and the store are statically mapped to the same port.

For more information about static port mappings for Exchange Server 2003 and Exchange 2000 Server, click the following article number to view the article in the Microsoft Knowledge Base: Note The RPC Dump tool does not list the endpoint mapper. For additional information about how to obtain the RPC Dump tool, visit the following Microsoft Web site:

Restore missing RPC registry values

To restore missing RPC registry values on the client or on the server, follow these steps.

Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:

Step 1: Verify registry entries

1. Click Start, and then click Run.
2. In the Open box, type regedit, and then click OK.
3. Locate the following key in the registry:
   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\ClientProtocols
   Verify that all entries are present and correct by referring to the tables contained in the "ClientProtocols" section of this article.
4. If any values are missing, add the missing values. To do this, follow these steps:
   1. On the Edit menu, point to New, and then click String Value.
   2. Type the name of the missing string value, and then press ENTER.
   3. Press ENTER.
   4. In the Edit String dialog box, type the missing value data in the Value data box, and then click OK.
5. Quit Registry Editor.
6. Restart the computer.
7. Test Exchange Server connectivity.

Step 2: Verify the version of the DLL file

If all the registry values exist, verify the version of the RPC DLL file that is on the computer. The version of the RPC DLL file must match the version and the build number of the Windows operating system on the computer.

Note The registry keys that are described earlier in this article list the names of the .dll files that each RPC uses. For example, Rpc4rt4.dll is the .dll file that is used by TCP/IP on Windows 2000 and on Windows XP.

To determine the version and the build number of the Windows operating system on the computer, follow these steps.

1. Click Start, and then click Run.
2. In the Open box, type winver.
3. Make a note of the version and the build number.

To determine the version of the .dll file, follow these steps:

1. In Windows Explorer, locate the RPC .dll file in the Windows\System32 folder.
2. Right-click the file, and then click Properties.
3. Click Version.
4. Note the file version.
   
   The file version must reflect the build number of the Windows operating system on the computer. For example, on Windows XP version 5.1 build 2600, the Rpcrt4.dll file version is 5.1.2600.0.

If the version of the .dll file does not match the version and the build number of the Windows operating system on the computer, replace the .dll file with the correct version. To do this, follow these steps:

1. Locate the correct version of the .dll file.
   
   You can find the file on the Windows CD, in Windows service packs, or on another computer that is running the same build of Windows.
2. On the computer that is experiencing the problem, locate the .dll file.
3. Change the extension of the .dll file to .bak or .old.
4. Copy the correct .dll file to the computer that is experiencing the problem.
5. Restart the computer.
6. Test Exchange Server connectivity.

Step 3: Remove and then reinstall TCP/IP

Important This step must only be performed on the client computer or computers.

On the Outlook client computer, if you cannot reestablish Exchange Server connectivity by following steps 1 and 2, remove and then reinstall TCP/IP. Microsoft recommends that you do not remove the TCP/IP protocol from the server. To remove and then reinstall TCP/IP on the client computer, follow these steps:

1. Log on as the local administrator.
2. Click Start, and then click Control Panel.
3. Double-click Network Connections.
4. Right-click the Local Area connection, and then click Properties.
5. Install another protocol to maintain a placeholder for the connection. For example, install NWLink.
6. Click to clear the Internet Protocol (TCP/IP) check box, and then click OK.
7. Click Yes.
8. Repeat steps 3 through 5 for each network connection that is listed.
9. Restart your computer.
10. Click Start, and then click Control Panel.
11. Double-click Network Connections.
12. Right-click the network connection, and then click Properties.
13. Click to clear the Internet Protocol (TCP/IP) check box, and then click OK.
14. Click Yes.
15. Reinstall TCP/IP in each network connection.
16. In each network connection, remove the protocol that was installed to maintain the placeholder (such as NWLink). Do not remove other protocols if they were already installed.
17. Restart your computer.

For more information about how to troubleshoot connectivity issues, click the following article numbers to view the articles in the Microsoft Knowledge Base: