When your Exchange Server 2003 environment experiences a performance or stability problem, you need to be able to quickly diagnose and correct the malfunction and stem the flood of user complaints. Knowing how to collect the relevant debugging data is important. As an Exchange administrator, I've learned about several tools and techniques that can benefit your troubleshooting efforts and maximize the uptime on your Exchange servers.
Logging Debugging Information
Exchange 2003 logs informational, warning, and error events to the Application event log. Therefore, your first step in troubleshooting Exchange problems is to look in the Application event log. To view the log, open Windows Event Viewer (Start, All Programs, Administrative Tools, Event Viewer).
The default diagnostics logging level for all Exchange services is None. This level logs events such as start-up and shut-down of services, status of backup events, and errors. This logging level is adequate for single-server deployments that aren't experiencing any problems, but you'll probably need to increase logging levels for complex enterprise deployments that have many servers.
You can use the Microsoft Management Console (MMC) Exchange System Manager (ESM) snap-in to change the level of diagnostics logging for Exchange components. To do so, open ESM, right-click the server for which you want to set the logging levels, and select Properties. Select the Diagnostics Logging tab, which Figure 1 shows.
I recommend that you set logging levels conservatively when you first deploy Exchange, then refine the settings as you gain monitoring experience. Table 1 shows the settings I've configured on my production server, but these settings probably won't suit every deployment. For example, I've set diagnostics logging levels for public folder replication events to Maximum. My server is part of an Exchange deployment that closely monitors public folder replication, and setting the diagnostics logging to these levels helps us troubleshoot replication problems more effectively. If your organization doesn't use public folders, you could set the diagnostics logging for public folder components to None.
Increasing the diagnostics level to Maximum for any component causes that component to write every internal processing event to the Application event log. Some components can write hundreds of informational events in a short time, thereby complicating your efforts to find useful information in the log. Thus, you should use caution when setting Maximum logging levels.
However, setting Maximum diagnostics logging levels can be useful for troubleshooting problems with individual Exchange services. For example, the Microsoft article "XADM: How to Troubleshoot Exchange 2000 System Attendant Startup Failures" (http://support.microsoft.com/?kbid=245024) describes how to troubleshoot System Attendant failures by turning up logging on System Attendant service subcomponents such as the Name Service Provider Interface (NSPI), which is the service that Outlook Messaging API (MAPI) clients use to locate an Exchange Global Catalog (GC) server. After you resolve a problem, reset logging levels back to their normal levels.
Troubleshooting Exchange Hangs
When an Exchange server hangs, Exchange processes go into a frozen state and can't write information to the event log. Therefore, these types of problems are often difficult to troubleshoot. By default, Exchange 2003 doesn't create any dump files in the event of a crash, and by default, debugging symbols aren't installed. You can read more about installing debugging symbols in the Web-exclusive sidebar "Dr. Watson Debugging Symbols" (http://www.winnetmag.com/microsoftexchangeoutlook, InstantDoc ID 42879).
A server hang can have many causes, including insufficient virtual memory, a memory leak caused by an application, a process that hogs available CPU resources, or a conflict for system resources between the OS and a third-party application. In such circumstances, Microsoft Product Support Services (PSS) engineers or anyone else attempting to troubleshoot the problem will require certain information before they can discover the root cause.
Debugging Tools
To debug an Exchange server crash or hang event, PSS typically requests that you run three utilities (MPS_Reports, ADPlus, and VaDump) and send the output to PSS for analysis. For more information about sending your debugging information to PSS, see the Web-exclusive sidebar "Getting Help from Microsoft PSS" (http://www.winnetmag.com/microsoftexchangeoutlook, InstantDoc ID 42881).
I recommend that you install the MPS_Reports, ADPlus, and VaDump debugging tools on all your servers as part of your server build process. Without these tools, you might not be able to diagnose a hanging server. For more information about installing and using these tools, as well as the URLs for downloading them, see "Microsoft Resources." Microsoft regularly adds new features to its debugging tools, so I suggest checking the Microsoft site for updates every few months and upgrading the tools on a quarterly basis as part of your usual server-update process.
MPS_Reports
The MPS_Reports utility gathers configuration information from a server and runs on all versions of Windows Server 2003, Windows XP, Windows 2000, and Windows NT 4.0. You'll need local administrator privileges to run the utility. MPS_Reports generates compressed files that contain configuration information, so it requires disk space to run. The program is available in the following versions:
- Alliance edition (mpsrpt_alliance.exe) is a general, all-purpose version that captures a range of configuration information.
- Cluster edition (mpsrpt_cluster.exe) captures information relevant to Windows Cluster Service.
- Directory Services edition (mpsrpt_dirsvc.exe) captures information relevant to Microsoft Directory Services.
- Network edition (mpsrpt_network.exe) captures information relevant to networking.
- Setup edition (mpsrpt_setupperf.exe) captures information relevant to setup and performance.
- Software Update Services edition (mpsrpt_sus.exe) captures information relevant to Microsoft Software Update Services (SUS).
- SQL edition (mpsrpt_sql.exe) captures information relevant to Microsoft SQL Server.
- MDAC edition (mpsrpt_mdac.exe) captures information relevant to Microsoft Data Access Components (MDAC).
The Alliance, Setup, and Directory Services editions are the versions that apply to debugging Exchange. The Alliance and Setup versions help you eliminate drivers and incorrect Windows configuration as a root cause for Exchange server instability, and the Directory Services edition helps you troubleshoot Directory Services problems. Note that MPS_Reports is only a reporting tool; it doesn't change the registry or require any downtime. See "Microsoft Resources" for more information about installing and running MPS_Reports.