Troubleshooting Microsoft RPC performance for Microsoft Services

Troubleshooting Microsoft RPC performance for Microsoft Services

Microsoft RPC (MSRPC) is commonly used to provide access to Microsoft services and applications over the network. This article discusses troubleshooting Microsoft RPC performance degradations and the services that rely upon MSRPC.

What is MSRPC?

RPC (Remote Procedure Call) fits into a wider framework called DCE (Distributed Computing Environment). RPC enables you to call different applications via a single network communication.

Microsoft has its own implementation called MSRPC. Microsoft’s proprietary technology called Distributed Component Object Model (DCOM) is a software framework which enables several software components distributed over several machines to communicate with each other. DCOM was previously called “Network OLE”.

While RPC simplifies the communication between different Microsoft systems, it uses one dedicated network protocol and communication method for several client/server processes. RPC can be leveraged by several services simultaneously.

What makes troubleshooting Microsoft RPC performance difficult?

1. Recognizing RPC

RPC may use a variety of ports and network services:

Service Name	UDP	TCP
HTTP	80, 443, 593	80, 443, 593
Named Pipes	445	445
RPC Endpoint Mapper	135	135
RPC Server Programs	Dynamically Assigned	Dynamically Assigned

• Recognize RPC when it is communicating on commonly used ports (e.g., 80, 443, 593 and 445, which are generally used by other network protocols). Based on this, one is not able to:
• Recognize RPC when it is using dynamically assigned ports (random allocation of destination ports above 1024)

As an example, here is the variety of ports used by MS RPC:

2. Distinguishing the services carried by RPC

One RPC network channel may carry several system-level services: RPC acts like a set of APIs over the network.

You have no practical way to distinguish different processes through the network protocols unless you consider the payload of each packet.

As an example, here are the different services using MSRPC:

How can you work around this?

With a network sniffer (e.g., Wireshark)

Once you have captured some traffic, in some cases, your protocol analyzer may recognize the packets which belong to an MS RPC traffic.

In this case, it will also report (in the details of the packet) a unique identifier (UUID) that corresponds to a given service.

Once you have this UUID, it will be either recognized by your network analyzer or you can look it up in a web search engine:

Once you know the service, you should isolate the conversation for this service and calculate the time intervals between the packets to get the response times for the different transactions (this article shows how to measure network performance through passive traffic analysis).

With a wire data solution (e.g., SkyLIGHT PVX)

Any serious wire data solution providing performance analytics (ITOA) automates the following steps:

1. Recognize DCE/RPC traffic independently from the layer 3 ports used to communicate.
2. Identify and provide a readable information on the service/application carried by RPC.

SkyLIGHT PVX recognizes over 750 services and applications carried by RPC automatically thanks to its unique Port Independent Protocol Identification algorithms.

1. Provide an instant view on a complete set of network and application performance metrics for a given application (and client, and server)

For any conversation, SkyLIGHT PVX computes the network and application performance metrics in real time so that they are instantly available for any session carried by the network: