GSX Blog

Exchange 2010 Monitoring: Client Access (Part 2, Performance)

Posted by Carl Drechsel on Tue, Nov 29, 2011

This is the second part of a three part series that addresses monitoring client access in an Exchange 2010 environment.  It is meant to provide a good overall introduction into client access monitoring. This post will highlight Performance from an access and hardware perspective.

Exchange 2010

Access Performance

It’s one thing to know that you client access server is accessible, it’s another thing to know it is performing as expected. One of the key ways to monitor the Client Access Server role is by taking several performance counter endpoints into consideration.

 Outlook Web App

MSExchange OWA-We can determine and monitor current user load by taking a couple of counters into consideration.

MSExchange OWA\Current Unique Users

Shows the number of unique users currently logged on to Outlook Web Access. This value monitors the number of unique active user sessions, so that users are only removed from this counter after they log off or their session times out.

MSExchange OWA\Requests/sec

Shows the number of requests handled by Outlook Web Access per second.

MSExchange OWA\Average Response Time

Shows the average time (in milliseconds) that elapsed between the beginning and end of an OEH or ASPX request. Used to determine the latency that a client is experiencing.

MSExchange OWA\Average Search Time

Shows the average time that elapsed while waiting for a search to complete.

 Outlook Anywhere

RPC/HTTP Proxy-We can determine and monitor current Outlook anywhere usage and load.

RPC/HTTP Proxy\Current Number of Incoming RPC over HTTP Connections

Shows the current number of front-end HTTP connections.

RPC/HTTP Proxy\Current Number of Unique Users

Shows the number of unique users currently connected to a back-end server via RPC/HTTP.

RPC/HTTP Proxy\RPC/HTTP Requests per Second

Shows the rate of RPC/HTTP requests sent to the back-end servers helpful in determining load.


MSExchange ActiveSync-We can determine and monitor mobile connections and performance. These counters can help determine if problems with mobile device access are local to the Client Access server.

MSExchange ActiveSync\Requests/sec

Shows the number of HTTP requests that are received from the client via ASP.NET per second.  Determines the current Exchange ActiveSync request rate.

MSExchange ActiveSync\Requests/sec

Shows the number of HTTP requests that are received from the client via ASP.NET per second. Stats Only to determine current user load.

MSExchange ActiveSync\Average Request Time

Shows the average time that elapsed while waiting for a request to complete.  Includes Ping Request Time, which can increase the general response time of this counter. Adding ping counters helps clarify where performance is being impacted. Determines the rate at which Availability service requests are occurring.

Rpc Client Access

MSExchange RpcClientAccess-We can determine and monitor overall client access connectivity

MSExchange RpcClientAccess\Active User Count

Active User Count is the number of unique users that have shown some activity in the last 2 minutes.

MSExchange RpcClientAccess\Connection Count

Connection Count is the total number of client connections maintained.

MSExchange RpcClientAccess\RPC Operations/sec

RPC Operations/sec is the rate at which RPC operations occur, per second.

MSExchange RpcClientAccess\User Count

User Count is the number of users that are connected to the service.

 Availability Service

MSExchange Availability Service-The Availability service in Exchange 2010 provides Microsoft Office Outlook clients resource checking availability. These counters help you to assess the client load and responsiveness of the service itself.

MSExchange Availability Service\Availability Requests (sec)

Shows the number of requests serviced per second. The request can be only for free/busy or include suggestions. One request may contain multiple mailboxes. Determines the rate at which Availability service requests are occurring.

MSExchange Availability Service\Average Time to Process a Free Busy Request

Shows the average time to process a free/busy request in seconds. One request may contain multiple mailboxes. Free/busy responses do not have meeting suggestions.

 Address Book Service

MSExchangeAB –We can use the counters below to monitor address book service connections and performance.

MSExchangeAB\NSPI Connections Current

NSPI Connections Current is the number of NSPI clients that are currently connected to the server.

MSExchangeAB\NSPI RPC Browse Requests Average Latency

Shows the average time, in ms, that Name Service Provider Interface (NSPI) browse requests took to complete during the sampling period.

MSExchangeAB\NSPI RPC Requests Average Latency

Shows the average time, in ms, that NSPI requests took to complete during the sampling period.

Exchange Control Panel

MSExchange Control Panel –The counters below can help determine Control Panel load and performance.

MSExchange Control Panel\Requests - Average Response Time

Requests - Average Response Time is the average time (in milliseconds) the Exchange Control Panel took to respond to a request during the sampling period.

MSExchange Control Panel\ASP.Net Request Failures/sec

ASP.Net Request Failures/sec is the number of failures per second detected by ASP.Net in the Exchange Control Panel.

MSExchange Control Panel\Inbound Proxy Requests/sec

Inbound Proxy Requests/sec is the number of requests received from a primary Client Access server per second.

There are various additional counters associated with these objects that can provide valuable insight into overall Client Access performance.  Thresholds vary per counter and will also vary on the environment being monitored. There are some generic recommended thresholds, but it is best to take a baseline performance metric during normal operations and use that to compare to subsequent measurements.

Hardware Performance

Of course both connectivity and access performance are subject to the performance of your underlying hardware.  The obvious things that we need to consider to ensure system performance are processor and memory utilization as well as network saturation. These can be monitored by using standard windows Performance Monitor counters for the associated hardware components.  See below for a few examples to keep an eye on.



Processor (_Total)\% Processor Time

The average percentage of time that all processors are active. This counter is the primary indicator of average processor activity. This value is derived by calculating the percentage of time during the sample interval that all processors spent in executing their idle thread (which consumes cycles on a processor when no other threads are ready to run), and then subtracting the result from 100 percent.


This value should remain below 75%, if you’re constantly running above that the server is over utilized, check user load as you might need to add additional servers to the CAS array

System\Processor Queue Length

The number of threads in the processor queue. Shows ready threads only, not threads that are running. Even multiprocessor computers have a single queue for processor time; thus, for multiprocessors, you need to divide this value by the number of processors servicing the workload. A sustained processor queue of less than two threads per processor is normally acceptable, depending upon the workload.

Memory \ %Committed Bytes in Use

% Committed Bytes In Use is the ratio of Memory \ Committed Bytes to the Memory \ Commit Limit. Committed memory is the physical memory in use for which space has been reserved in the paging file should it need to be written to disk. The commit limit is determined by the size of the paging file.  If the paging file is enlarged, the commit limit increases, and the ratio is reduced). This counter displays the current percentage value only; it is not an average.

Network Interface\Bytes Total/sec.

This will tell you overall how much information is going in and out of the interface. Typically, you can use this to get a general feel, but will want to look at the Bytes Sent/sec and the Bytes Received/sec for a more exact detail of the type of traffic.

Keeping an eye on these counters can help give you a better idea of your client access environments load and performance. Please check back next week for part three as we look into how you can use GSX Monitor to monitor, manage, measure and analyze client access connectivity and performance within your Exchange Server 2010 environment. If you missed part one: connectivity, you can view that here: Exchange 2010 Monitoring: Client Access (Part 1, Connectivity). Also in the meantime, check our website to see our overall solution for Exchange 2010 monitoring.


Tags: Exchange 2010, client access server, counters, perfmon, Exchange 2010 monitoring, Performance