Rdp Client Access Test

A Microsoft RDS server environment is a shared environment in which multiple users connect to a server from remote terminals using the Remote Desktop Protocol (RDP). One of the key factors influencing user experience in such an environment is the latency seen by the users when connecting to the server. High network latencies or packet losses during transmission can cause significant slow-downs in request processing by the server. Hence, monitoring latencies between the server and individual client terminals is important.

The Rdp Client Access test is executed by the eG agent on a Microsoft RDS server. This test auto-discovers the users who are currently logged on to the server and the IP address from which they are connecting to the Microsoft RDS server.  For each user, the test monitors the quality of the link between the client and the Microsoft RDS server.

Using this test, an administrator can identify user sessions that are being impacted by high latencies or by excessive packet drops. In some cases, a Microsoft RDS server may regard a user session as active, even though the network link connecting the user terminal to the Microsoft RDS server has failed. The Rdp Client Access test alerts administrators to such situations.

This test is disabled by default. To enable the test, go to the enable / disable tests page using the menu sequence : Agents -> Tests -> Enable/Disable, pick the Microsoft RDS ad the desired Component type, set Performance as the Test type, choose the test from the disabled tests list, and click on the < button to move the test to the ENABLED TESTS list. Finally, click the Update button.

Target of the test : A Microsoft RDS server

Agent deploying the test : An internal agent

Outputs of the test : One set of outputs for every user currently connected to the Microsoft RDS server

Configurable parameters for the test
Parameters Description

Test period

This indicates 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

Displaydomain

By default, the DISPLAYDOMAIN flag is set to Yes; this indicates that thistest, by default, will report metrics for every domainname\username who is currently connected to the server. This way, administrators can quickly figure out which user is connecting to the server from which domain. You can set this flag to No to ensure that this test reports metrics for each username only.

Packetsize

The size of packets used for the test (in bytes)

Packetcount

The number of packets exchanged between the Microsoft RDS server and the user terminal during the test

Timeout

How long after transmission should a packet be deemed lost (in seconds)

PacketInterval

Represents the interval (in milliseconds) between successive packet transmissions during the execution of this test.

Reportunavailability

  • By default, this flag is set to No. This implies that, by default, the test will not report the unavailability of network connection between a user terminal and the Microsoft RDS server. In other words, if the Packet loss measure of this test registers the value 100%for any user, then, by default, this test will not report any measure for that user; under such circumstances, the corresponding user name will not appear as a descriptor of this test. You can set this flag to Yes, if you want the test to report and alert you to the unavailability of the network connection between a user terminal and the Microsoft RDS server.  
  • Measurements made by the test
    Measurement Description Measurement Unit Interpretation

    Number of sessions

    Indicates the current number of sessions for a particular user

    Number

    The value 0 indicates that the user is not currently connected to the Microsoft RDS server.

    Average delay

    Indicates the average delay between transmission of a request by the agent on a Microsoft RDS server and receipt of the response back from the user terminal.

    Secs

    Comparing the value of this measure across users will enable administrators to quickly and accurately identify users who are experiencing higher latency when connecting to a Microsoft RDS server.

    Minimum delay

    Indicates the minimum delay between transmission of a request by the agent on a Microsoft RDS server and receipt of the response back from the user terminal.

    Secs

    A significant increase in the minimum round-trip time is often a sure sign of a poor link between the server and a user's terminal.

    Packet loss

    Indicates the percentage of packets lost during data exchange between the Microsoft RDS server and the user terminal.

    Percent

    Comparing the value of this measure across users will enable administrators to quickly and accurately identify users who are experiencing slowdowns because of poor performance on the network links between their terminals and the Microsoft RDS server.

    Note:

    • If the same user is connecting to the Microsoft RDS server from multiple client terminals, the value of the Number of sessions, Avg delay, and Packet loss measures will be averaged across all the sessions of that user. The Minimum delay measure, on the other hand, will display the least value reported for Minimum delay across all the sessions of that user.
    • When a user logs out, the number of sessions will be reduced by 1. If the number of user sessions becomes 0, the corresponding entry for that user in the eG user interface will be removed after a short period of time.
    • By default, the Rdp Client Access test spawns a maximum of one thread at a time for monitoring each of the RDP connections to a Microsoft RDS server. Accordingly, the MaxRdpClientThreads parameter in the eg_tests.ini file (in the <EG_INSTALL_DIR>\manager\config directory) is set to 1 by default. In large Microsoft RDS server farms however, numerous concurrent users attempt to connect to the Microsoft RDS server from multiple remote client terminals. To enhance the efficiency of the test and to make sure that it scales to monitor the large number of RDP connections to the Microsoft RDS server, you might want to consider increasing the value of the MaxRdpClientThreads parameter. If this parameter is set to say, 15, then, it implies that the test will spawn a maximum of 15 threads at one shot, thus monitoring 15 RDP connections to the Microsoft RDS server, simultaneously.