RPC Client Access Service Test
In Microsoft Exchange Server 2013/2016, the Outlook Anywhere feature, formerly known as RPC over HTTP, lets clients who use Microsoft Outlook 2013/2016, Outlook 2010, or Outlook 2007 connect to their Exchange servers from outside the corporate network or over the Internet using the RPC over HTTP Windows networking component. The Windows RPC over a component, which Outlook Anywhere clients use to connect, wraps remote procedure calls (RPCs) with an HTTP layer. This allows traffic to traverse network firewalls without requiring RPC ports to be opened. To ensure that the user experience with Exchange remains unaffected, administrators should be able capture RPC connection failures to the server and detect bottlenecks in RPC connections, well before users notice and complain. This is where the RPC Client Access Service test helps. By monitoring the RPC connection attempts to the server over HTTP and capturing connection failures and delays promptly, the RPC Client Access Service test proactively alerts administrators to real/potential road-blocks to server accesses from Outlook clients.
Target of the test : A Microsoft Exchange 2013/2016 server
Agent deploying the test : An internal agent
Outputs of the test : One set of results for the Exchange 2013/2016 server being monitored
|
Measurement | Description | Measurement Unit | Interpretation |
---|---|---|---|
Active users count: |
Indicates the number of unique users that have shown some activity in the last 2 minutes. |
Number |
These measures are a good indicator of the current session load on the Exchange server. |
RPCs attempted by users: |
Indicates the client-reported number of RPCs attempted by users (since the service wasa started). |
Number |
|
RPCs failed: |
Indicates the client-reported number of failed RPCs (since the service was started). |
Number |
Ideally, this value should be 0. A high value is indicative of frequent RPC failures. The reasons for the same will have to be uncovered. |
RPCs succeeded: |
Indicates the client-reported number of successful RPCs (since the service was started). |
Number |
|
RPC average latency: |
Indicates the latency averaged for the past 1024 packets.
|
Secs |
This value should be below 0.050 seconds at all times. A slowdown in RPC packet processing can adversely impact the user experience. |
RFC operations rate: |
Indicates the rate at which RPC operations occur, per second.
|
Operations/Sec |
Generally, spikes in RPC requests that do not increase RPC operations/sec indicate that there are bottlenecks preventing the store from fulfilling the requests in a timely manner. It is relatively simple to identify where the bottlenecks are occurring with regards to RPC requests and RPC operations/sec. If the client experiences delays, but the RPC requests are zero and the RPC operations/sec are low, the performance problem is happening before Exchange processes the requests (that is, before the Microsoft Exchange Information Store service actually gets the incoming requests). All other combinations point to a problem either while Exchange processes the requests or after Exchange processes those requests. |
RPC packets rate: |
Indicates the rate at which RPC packets are processed. |
Packets/Sec |
A high value is desired for this measure. If this value drops steadily, it could indicate a connection bottleneck. |
Current client requests being processed: |
Indicates the number of client requests that are currently being processed by the RPC Client Access service.
|
Number |
The Exchange server is configured with a pre-set maximum number of RPC requests that can be handled simultaneously (default is 100). If this value is exceeded, client requests to the server will be rejected. This measure should be below 30 most of the time. |
Users connected: |
Indicates the number of users who are connected to the service. |
Number |
This is a good indicator of the current user load on the server. |