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

Configurable parameters for the test
Test period - How often should the test be executed Host - The host for which the test is to be configured. port – The port at which the host listens.

Measurements made by the test
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.