Monitoring disk-related and remote procedure call (RPC) related counters can help you gauge Exchange Server 2007 mailbox health. This tip from Microsoft Exchange Server expert Brien Posey explains several of those counters.
Logical Disk(*)\Avg. Disk sec/Read and Logical Disk(*)\Avg. Disk sec/ Write counters -- These counters display the average amount of time it takes to read data from and write data to disks. Average values for these counters should remain below 10 milliseconds (ms), but it's tough to trigger an alert based on averages. Microsoft suggests that these counters remain below 50 ms; use this value for performance alerts.
Logical Disk(*)\Avg. Disk sec/Transfer counter -- This counter shows the server's average disk transfer times. This counter should average around 20 ms, with spikes no higher than 50 ms. Excessively high spikes can indicate a disk bottleneck or an impending disk failure.
Remote procedure calls
Microsoft Outlook is designed to communicate with Exchange Server using remote procedure calls (RPCs), assuming that Outlook is running in MAPI mode. If a mailbox server is slow to process RPCs, the delay will affect Outlook. Users may not notice this delay unless Outlook is operating in online mode. But the delay can affect user productivity.
Microsoft provides recommended average values for most RPC-related Performance Monitor counters, but those values won't trigger
MSExchangeIS|RPC Requests counter -- This counter shows you the total number of RPC calls that the Information Store is processing. Performance can suffer if the server gets bogged down processing too many RPC requests.
It's recommended that the total number of RPC requests never exceed 70. Exchange can handle more RPC requests than that, but server performance can suffer. Exchange can handle 500 RPC requests. Once this limit has been exceeded, the server will begin dropping RPC requests.
MSExchangeIS\RPC Num. of Slow Packets counter -- This counter tells you how many of the last 1,024 RPC packets took longer than 2 seconds to process. A few slow RPC packets are normal on a busy Exchange Server, but on average, this counter should indicate a value of 1 or less and should never exceed 3.
The following Performance Monitor counters show when RPC requests from clients aren't being processed.
MSExchangeIS\Client: RPC Failed: Server Too Busy counter -- This shows the total number of client RPC requests that failed since the information store started. These failures occur because the server is too busy to process the request. This counter should always be 0.
MSExchangeIS\Client: RPC Failed: Server Too Busy/sec counter -- This shows the number of failed RPC requests that occur each second when the server is too busy. This counter should also always be 0.
If either of these counters produces a value of 1 or higher, it usually means that the server's RPC threads have been exhausted. Exchange can only process 500 RPC threads at a time.
In some cases, though, Exchange will use a feature called RPC client back-off to prevent a client from using too many server resources. If this type of client throttling occurs against a client running an older version of Outlook, these two counters can produce false positives.
About the author: Brien M. Posey, MCSE, is a five-time recipient of Microsoft's Most Valuable Professional (MVP) award for his work with Exchange Server, Windows Server, Internet Information Services (IIS), and File Systems and Storage. Brien has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. As a freelance technical writer, Brien has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal website at www.brienposey.com.
Do you have comments on this tip? Let us know.
Please let others know how useful this tip was via the rating scale below. Do you know a helpful Exchange Server, Microsoft Outlook or SharePoint tip, timesaver or workaround? Email the editors to talk about writing for SearchExchange.com.
This was first published in August 2009