You can access Exchange Server 2003 mailboxes in numerous ways. For traditional Messaging API (MAPI) client access using Microsoft Office Outlook 2003, you have the choice of connecting in classic online mode or using remote procedure call (RPC) over HTTP connections. You can also connect through Outlook Web Access (OWA) or a handheld device. Finally, you can choose not to connect at all and instead work in cached mode.
To connect to your Exchange mailbox, you usually just start your client. However, changes to the environment might occasionally prevent the client from successfully connecting to the mailbox. You can employ some troubleshooting tools and techniques to help solve MAPI-based client connection problems. In this article, I cover troubleshooting techniques that you can use when you have problems connecting in Outlook's classic online mode. These techniques use readily available tools to check for network-level, protocol-level, and application-level problems. In a follow-up article, I'll describe troubleshooting tools and techniques that you can use when you have problems with RPC over HTTP connections.
Troubleshooting Network-Level Problems
When you start Outlook in classic mode, you should see your mailbox contents displayed soon after the client authenticates. (The authentication might not be obvious if you're using Integrated Windows authentication and your credentials are already cached on the client.) If you don't see your mailbox, you first must determine whether you have network connectivity between the Outlook client and the Exchange server.
The first step in determining whether you have network connectivity is to make sure that your client has a network address. You can use the command
ipconfig /all
from your client's command-shell window to check the client's network configuration. Running this command yields information about the TCP/IP address assigned to the client as well as information about the default gateway, DNS servers, and WINS servers. If you're having problems with the TCP/IP address, you might need to either reconfigure your network settings or make sure that any DHCP servers you're using are functioning properly.
If all is in order with the client's network configuration, you need to determine whether establishing a network connection between the client and Exchange server is possible. The easiest way to help make this determination is to use the Ping command. From the client's command-shell window, run the command
ping IPAddress
where IPAddress is your Exchange server's TCP/IP address. Keep in mind that a firewall between the client and server will block Internet Control Message Protocol (ICMP) echo requests, which the Ping command uses. Therefore, not having the ping reach the server doesn't necessarily mean you have a network problem.
You can further troubleshoot the network connection with the Tracert command. From the client's command-shell window, run the Tracert command, using the syntax
tracert IPAddress
Alternatively, you can specify the Exchange server's name rather than its TCP/IP address. Figure 1 shows sample output from this command. If you have a network outage between the client and server, Tracert's output can help you determine where the failure exists. Be aware that, like Ping, Tracert uses ICMP echo requests.
Even if you can connect to the Exchange server, running Tracert can be useful. You can look for particularly high latency figures in the route that your client/server connection takes. Latencies longer than 500 milliseconds (ms) are definitely worth investigation by the network administrator.
By default, the Outlook client first attempts to contact the RPC Endpoint Mapper server on port 135 on the Exchange server to agree on a set of ephemeral (or transient) MAPI ports within the 1024 through 65,535 range over which the client and Exchange server will conduct their session. To determine whether a problem exists with one of the transient MAPI ports, you can use the Netstat command. By running the command
netstat -a
on your client or the Exchange server, you can learn over which network ports communications are currently taking place. You might also run this command on clients that aren't having connectivity problems to validate that connections can be established over a particular port range. Changes to firewalls or Virtual LANs (VLANs) in your network might prevent connections in this MAPI port range, so if connection problems suddenly develop, ask your network administrator whether any alterations have been made recently. Clients might also access Global Catalog (GC) servers for Global Address List (GAL) referral, so changes to GC servers might prevent access as well. For information about how to modify the MAPI port range to use specific static values, see the Microsoft article "Exchange 2000 and Exchange 2003 Static Port Mappings" (http://support.microsoft.com/?kbid=270836).
In general, name-resolution problems are the biggest culprits when it comes to problems with Outlook client connections. Make sure that any short names or Fully Qualified Domain Names (FQDNs) that you use in your Exchange MAPI profile resolve to the correct TCP/IP address. You can use the Nslookup command to check whether your Exchange server name (in short-name or FQDN format) is resolving correctly against DNS. From the client's command-shell window, run the Nslookup command, using the syntax
nslookup MyHostName
where MyHostName is the name of the server to which you're trying to confirm connectivity. Another instance in which you should use this Nslookup command to make sure that the Exchange server name is resolving correctly against the HOSTS or LMHOSTS file in the \%systemroot%\system32\drivers\etc directory.
Although I've described these troubleshooting tools and techniques in the context of MAPI client connections, they aren't limited to just MAPI connections. In general, you can use them for troubleshooting any kind of client connection problem.
Troubleshooting Protocol-Level Problems
An Outlook client communicates with an Exchange server by using RPCs over MAPI across a network link. Even when you've successfully verified basic network connectivity, this verification might not guarantee that RPCs can travel between the client and the Exchange server.
One quick method to determine whether RPCs are getting through from the client to the server is to access your MAPI profile in the Control Panel Mail applet. In this applet, retype your server's name, then click Check Name. The Check Name function sends an RPC request from your client to the Exchange server to validate your mailbox details. If this RPC request is successful, you'll see the server name and the username fields become underlined and the Check Name button become shaded—sure signs that you can make an RPC connection to your Exchange server.
If the Check Name test is unsuccessful, either the RPC didn't make it to the Exchange server (possibly because a network device, such as a firewall or router, is blocking RPC packets between the client and server) or the Exchange services aren't responding to the RPC request (possibly because the Exchange server can't access a GC to process the Check Name request). To rule out the former cause, you should talk with your network administrator to confirm that RPCs aren't being blocked, possibly with a firewall or proxy server, such as Microsoft Internet Security and Acceleration (ISA) Server 2000. Assuming all is OK, you should then verify that the Exchange services are running on the Exchange server. On the Start menu, go to Settings, Control Panel and verify that at least the Exchange System Attendant and Information Store services are running. You should also look in the event log on your Exchange server for any obvious errors, such as Exchange servers failing to start. If services are running and no events are logged, you'll need to run some diagnostic utilities to check that the RPCs are actually reaching the Exchange server.
To validate RPC connectivity, you can use the Rping utility, which is in the Microsoft Windows Server 2003 Resource Kit or the Microsoft Windows 2000 Server Resource Kit. Rping consists of two components: rpings.exe, which runs on the Exchange server, and rpingc.exe, which runs on the client. You can find both components in the \Program Files\Windows Resource Kits\Tools directory on the server on which you installed the resource kit. Copy rpings.exe to any location on your Exchange server. This component acts as an RPC endpoint and runs continuously after you run the following command:
rpings.exe -p MyProtocol
where MyProtocol is IPX/SPX, NAMEDPIPES, NETBIOS, TCPIP, or VINES, depending on the protocol you use to connect your Outlook client to your Exchange server. (Although this command appears on several lines here, you would enter it on one line in the command-shell window.) TCPIP is the most common protocol specified.
After rpings.exe is running on the server, you should run a copy of rpingc.exe on the client. Rpingc.exe uses a GUI-based interface, which Figure 2 shows. You must enter the resolvable name of your Exchange server in the Exchange Server text box. Optionally, you can specify the protocol you want to use and whether you want to validate connections only to the Rping endpoint or to specific Exchange endpoints, such as the Store or Admin (i.e., Exchange System Attendant) functions.
To validate that the Exchange services are properly registered with the RPC subsystem, you can use the resource kit's Rpcdump utility. Rpcdump interrogates the RPC Endpoint Mapper service on the Exchange server and displays the services (endpoints) that are available for RPC connections. If the services are available, then you know that you have a problem with just the one client connection rather than all the clients. You can run Rpcdump locally on the Exchange server or remotely from a client. To run Rpcdump locally on the Exchange server, you can run the Rpcdump command, using the syntax
rpcdump /s MyServer /i /v
where the /s switch tells the utility to query the server that MyServer specifies. MyServer can be the server's short name or FQDN. The /i switch tells the utility to ping the services to test responsiveness. The /v switch specifies the verbose mode. Rpcdump can generate a lot of output, so you might want to pipe the output of the command to a text file for easy analysis.
Figure 3 shows sample Rpcdump output from my Exchange server. When you run Rpcdump against your Exchange server, you'll likely see a number of Exchange services listed in the output, including
- Exchange Server STORE ADMIN Interface
- Microsoft Information Store
- Exchange 2003 Server STORE EMSMDB Interface
- MS Exchange MTA 'Mta' Interface
- MS Exchange MTA 'Qadmin' Interface
- MS Exchange System Attendant Cluster Interface
- MS Exchange System Attendant Public Interface
- MS Exchange System Attendant Private Interface
- MS Exchange Directory RFR Interface
If the Exchange services are running without logging errors and the Exchange server is receiving RPCs from your client but you still can't connect, you must perform one more check on the Exchange server. The server must somehow have been reconfigured to prevent MAPI logons from specific Outlook versions. To determine whether this problem exists, you need to inspect the value of the Disable MAPI Clients entry in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
Services\MSExchangeIS\ParametersSystem registry subkey. If set, this value will define a range of MAPI client versions that will be denied logon rights to the Exchange Store. (When attempting to log on, the clients will receive the error message MAPI_E_LOGON_FAILED.) The client versions that are disabled are represented as a comma-separated string in the Disable MAPI Clients entry. For example, the string -5.0.2653.24, 11.0.4704.1-11.0.4704.4, 11.0.5604.0- disables access for all MAPI clients with the following version numbers:
- up to 5.0.2653.24 (inclusive)
- from 11.0.4701.1 up to 11.0.4704.4 (inclusive)
- from 11.0.5604.0 and later (inclusive)
You can determine the version number of the MAPI client that your PC is running by right-clicking the emsmdb32.dll file in the \Program Files\Common Files\System\Mapi\1033 directory, selecting Properties, then clicking the Version tab. Note that the file might be in a slightly different location on your PC, depending on the client version you're running, but you can easily find it by using the Search tool on the Start menu.
Troubleshooting Application-Level Problems
Occasionally, the Outlook application might not start correctly or you might have made some modifications that have rendered it unusable. For example, you might have inadvertently deleted the local folders that have been assigned for mail delivery. Fortunately, Outlook has many command-line switches that you can execute on startup that will reset various aspects of Outlook. To run Outlook with the command-line switches, run the following command:
\program files\microsoft office office11\outlook.exe MySwitch
where MySwitch is one of the command-line switches that Table 1 shows.
If you can connect to the Exchange server from your Outlook client but the initial client startup is exceptionally slow, you can perform several checks to determine the problem. The Web-exclusive sidebar "Troubleshooting Slow Outlook Start-ups" (http://www.winnetmag.com/microsoftexchangeoutlook, InstantDoc ID 42317) describes these checks.
Standard Techniques to Troubleshoot Common Problems
In this article, I've described some of the common problems that prevent the Outlook client from connecting to the Exchange server. For the most part, client/server connection problems are caused by network outages or name-resolution troubles and rarely by anything else. Fortunately, easy-to-use tools and techniques—such as the Ipconfig, Ping, Tracert, Netstat, Nslookup, Rpings, and Rpcdump commands—are readily available to troubleshoot problems at the network, protocol, and application levels.
