AVD User Logon Details Test

The process of a user logging into a RemoteApp/Desktop managed by an AVD broker is complex. Figure 1 depicts a typical logon process.

Figure 1 : A typical user logon process

The logon sequence is as discussed hereunder:

  1. Using supported Azure Virtual Desktop client user subscribes to the Azure Virtual Desktop Workspace

  2. Azure Active Directory authenticates the user and returns the token used to enumerate resources available to a user

  3. Client passes token to the Azure Virtual Desktop feed subscription service

  4. Azure Virtual Desktop feed subscription service validates the token

  5. Azure Virtual Desktop feed subscription service passes the list of available desktops and RemoteApps back to the client in the form of digitally signed connection configuration

  6. Client stores the connection configuration for each available resource in a set of .rdp files

  7. When a user selects the resource to connect, the client uses the associated .rdp file and establishes the secure TLS 1.2 connection to the closest Azure Virtual Desktop gateway instance and passes the connection information

  8. Azure Virtual Desktop gateway validates the request and asks the Azure Virtual Desktop broker to orchestrate the connection

  9. Azure Virtual Desktop broker identifies the session host and uses the previously established persistent communication channel to initialize the connection

  10. Remote Desktop stack initiates the TLS 1.2 connection to the same Azure Virtual Desktop gateway instance as used by the client

  11. After both client and session host connected to the gateway, the gateway starts relaying the raw data between both endpoints, this establishes the base reverse connect transport for the RDP

  12. After the base transport is set, the client starts the RDP handshake

As is evident from the discussion above, the logon process spans both the key tiers of the AVD infrastructure - the Microsoft-managed control plane tier on the cloud, and the customer-managed on-premises tier. A slowdown anywhere in the logon process, in any tier, can adversely impact the overall logon experience of a user. For instance, if a user's desktop request spends too much time in the control plane being load balanced, that user's logon experience will suffer. Likewise, if any group policy takes too long to be processed and applied during a logon, it can significantly delay the logon process at the customer end. To assure users of instant, on-demand access to virtual desktops at all times, administrators should monitor each user's logon experience with AVD in real-time, rapidly identify the user whose logon performance has degraded, and accurately isolate what problem in which tier is responsible for the degradation. eG Enterprise helps administrators achieve all of the above!

The AVD User Logon Details test monitors the logon experience of each AVD user, from when the broker processes that user's desktop request to when he/she is allowed access to a session host. In the process, the test shines the spotlight on users whose logon experience is sub-par. Additionally, the test measures the time spent by a user at each step of the logon process. This way, the test accurately pinpoints the root-cause of logon delays that a user may experience - is it owing to issues in the control plane? or is it because of slowness in the customer network? - if so, where in the customer end is the bottleneck? profile loading? setting up session environment? shell start-up? group policy processing? or others? Using the detailed diagnostics, administrators can also zero-in on the precise user session in which the logon experience was unsatisfactory, and why.

For deeper insights into a user's logon performance inside the customer network, you can use the User Logon Details - AVD test (mapped to the AVD Host Pool component). With the help of the User Logon Details - AVD test, administrators can figure out if an authentication delay (probably caused by a processing bottleneck on the AD / Azure AD in the customer's network) impacted the logon experience of the user. This test also leads administrators to the precise group policy and client side extension that was processed too slowly, thereby slowing down the user logon.

Note:

Typically, to consolidate log entries, correlate log data, and perform complex analysis, a host pool's logs are often sent to one/more Log Analytics Workspaces. This test reports valid metrics by reading data from these Log Analytics Workspaces only. If the host pool's logs are not sent to any Log Analytics Workspace, then this test will only report the value 0 for most of its measures. To avoid this, before configuring this test, make sure that the host pool's logs are configured to be sent to at least one Log Analytics Workspace. Follow the steps discussed in Configuring the Host Pool Logs to be Sent to a Log Analytics Workspace to achieve this.

Target of the test : A Microsoft AVD Broker

Agent deploying the test: A remote agent

Output of the test: One set of results for each user connecting to the AVD service

Configurable parameters for the test
Parameters Description

Test Period

How often should the test be executed.

Host

The host for which the test is to be configured.

Subscription ID

Specify the GUID which uniquely identifies the Microsoft Azure Subscription to be monitored. To know the ID that maps to the target subscription, do the following:

  1. Login to the Microsoft Azure Portal.

  2. When the portal opens, click on the Subscriptions option (as indicated by Figure 2).

    Figure 2 : Clicking on the Subscriptions option

  3. Figure 3 that appears next will list all the subscriptions that have been configured for the target Azure AD tenant. Locate the subscription that is being monitored in the list, and check the value displayed for that subscription in the Subscription ID column.

    Figure 3 : Determining the Subscription ID

  4. Copy the Subscription ID in Figure 3 to the text box corresponding to the SUBSCRIPTION ID parameter in the test configuration page.

Tenant ID

Specify the Directory ID of the Azure AD tenant to which the target subscription belongs. To know how to determine the Directory ID, refer to Configuring the eG Agent to Monitor the Microsoft Azure App Service

Client ID and Client Password

The eG agent communicates with the target Microsoft Azure Subscription using Java API calls. To collect the required metrics, the eG agent requires an Access token in the form of an Application ID and the client secret value. To know how to determine the Application ID and the key, refer to Configuring the eG Agent to Monitor the Microsoft Azure App Service. Specify the Application ID of the created Application in the Client ID text box and the client secret value in the Client Password text box.

Proxy Host

In some environments, all communication with the Azure cloud be routed through a proxy server. In such environments, you should make sure that the eG agent connects to the cloud via the proxy server and collects metrics. To enable metrics collection via a proxy, specify the IP address of the proxy server and the port at which the server listens against the Proxy Host and Proxy Port parameters. By default, these parameters are set to none, indicating that the eG agent is not configured to communicate via a proxy, by default.

Proxy Username, Proxy Password and Confirm Password

If the proxy server requires authentication, then, specify a valid proxy user name and password in the Proxy Username and Proxy Password parameters, respectively. Then, confirm the password by retyping it in the Confirm Password text box.

Log Analytics Workspace Name

Typically, to consolidate log entries, correlate log data, and perform complex analysis, a host pool's logs are often sent to one/more Log Analytics Workspaces.

By default, the Log Analytics Workspace Name parameter is set to All. This indicates that the test reads log data from all Log Analytics Workspaces configured for the target subscription, by default. However, if you want the test to use only those Log Analytics Workspaces to which a host pool's logs are sent, then provide the names of these workspaces here as a comma-separated list. To determine the names of the workspaces, do the following:

  1. Login to the Microsoft Azure Portal, and click on Host Pools to view the configured host pools.

  2. Select any of the host pools displayed therein by clicking on it.

  3. Next, keep scrolling down the left panel of the page that then appears, until the Diagnostic Settings option (under Monitoring) become visible.  Click on Diagnostic Settings to proceed.

  1. The diagnostic settings that pre-exist (if any) for the chosen host pool will then appear. If any of the existing diagnostic settings have already been configured with Log Analytics Workspaces, then the Log Analytics workspace column of that list will display these workspace names. You can configure the LOG ANALYTICS WORKSPACE NAME parameter of this test with any of these workspace names. If required, you can even configure this parameter with two/more workspaces displayed here, as a comma-separated list

  1. However, If the Log Analytics workspace column is blank for all the existing diagnostic settings, it is a clear indication that the host pool's logs are yet to be configured to be sent to any Log Analytics Workspace. In this case therefore, you should create a new diagnostic setting for the target host pool where a Log Analytics Workspace is configured as the destination for the logs. To achieve this, follow the procedure detailed in Configuring the Host Pool Logs to be Sent to a Log Analytics Workspace.

DD Frequency

Refers to the frequency with which detailed diagnosis measures are to be generated for this test. The default is 1:1. This indicates that, by default, detailed measures will be generated every time this test runs, and also every time the test detects a problem. You can modify this frequency, if you so desire. Also, if you intend to disable the detailed diagnosis capability for this test, you can do so by specifying none against DD frequency.

Detailed Diagnosis

To make diagnosis more efficient and accurate, eG Enterprise embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option.

The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled:

  • The eG manager license should allow the detailed diagnosis capability
  • Both the normal and abnormal frequencies configured for the detailed diagnosis measures should not be 0.
Measures made by the test:
Measurement Description Measurement Unit Interpretation

Total logon processing duration

Indicates the total time taken by this user to log into an Azure virtual desktop.

Secs

If this value is abnormally high for any user, then, you can compare the time measurements reported by this test to know where exactly the user logon was bottlenecked - was it on the Microsoft-managed control plane? or on the customer-managed network? If the control plane is delaying the logon, then you can compare the value of the Orchestration duration, Load balancer duration, Transport duration, and RDP stack duration metrics to isolate where on the control plane the user request spent the most time -is it in orchestrating? transport? load balancing? or RDP stacking? If the customer network is where the problem is, then compare the time metrics displayed under the Logon Duration Breakups section to know when the delay was maximum - during session environment setup? profile loading? shell start-up? group policy processing? when being processed by the System event notification service or FSLogix service? or others?

Orchestration duration

Indicates the time taken by the broker to orchestrate this user's connection on the desktop.

Secs

 

Load balancer duration

Indicates the time taken by the broker to load-balance the user's logon request.

Secs

 

Transport duration

Indicates the time spent by this user's logon requests in transport.

Secs

 

RDP stack duration

Indicates the time spent by this user's logon requests in the RDP stack.

Secs

 

Logon duration

Indicates the total time this user's logon took in the customer's network.

Secs

If the value of the Total logon processing duration is abnormally high for a user, then compare the value of this measure with that of the Orchestration duration, Load balancer duration, Transport duration, and RDP stack duration measures to know what caused the user's logon experience to deteriorate - is it a orchestration / load balancing / transport / RDP stacking problem in the control plane? or a problem in the customer network? In the case of the latter, compare the values of all the duration metrics in the Logon Duration Breakup section to know where in the customer network the slowness originated.

Desktop ready duration

Indicates the time taken by this user's desktop to be readied for launch.

Secs

 

Application ready duration

Indicates the time taken by this user's RemoteApp to be readied for launch.

Secs

 

RDP authentication duration

Indicates the time taken by this user's RDP sessions to be authenticated.

Secs

 

If the RDP stack duration measure reports a very high value, then compare the value of these measures to know why this is so - is it because of a delay in authentication? authorization? or license check?

 

RDP authorization duration

Indicates the time taken by this user's RDP sessions to be authorized.

Secs

RDP license check duration

Indicates the time taken by this user's RDP sessions to check license availability.

Secs

Session environment duration

Indicates the time taken by this user's logon to setup the session environment.

Secs

 

If the Logon duration measure reports an abnormally high value for a user, then compare the value of these metrics for that user to know where in the customer network the problem lies - in session environment setup? in processing by the system event notification service / FSLogix service / shell service? in profile loading? in group policy processing? or in other types of processing?

 

 

 

 

 

 

System event notification service duration

The System Event Notification Service (SENS) creates a uniform connectivity and notification interface for applications. This measure indicates the time taken by this user's logon request to be processed by this system event notification service.

Secs

Profile load duration

Indicates the time taken to load this user's profile.

Secs

Group policy processing duration

Indicates the time taken by the user's group policies to be applied.

Secs

Terminal session duration

Indicates the average time taken by all the Terminal sessions of this user.

Secs

FSLogix service duration

Indicates the time taken by the FSLogix service to process this user's logon request.

Secs

Shell start duration

Indicates the time taken to launch/start the default Windows 10 shell of this user's desktop.

Secs

Other processing duration

Indicates the time spent by this user's logon in other types of processing.

Secs

Total sessions

Indicates the total number of sessions for this user.

Number

Use the detailed diagnosis of this test to know more about the desktop sessions that are currently open for the user. The client from which each session connected, the subscription, resource group, and resource that was accessed in every session, and the total logon processing time per session are displayed as part of the detailed statistics. This way, you can quickly compare the logon time across sessions, and accurately identify the exact session in which the user took the longest to logon. A breakup of the logon duration is also available for each session, thus enabling you to accurately isolate the root-cause of the poor logon performance in that session.

Shared sessions

Indicates the number of shared sessions for this user.

Number

Use the detailed diagnosis of this test to know which are the shared sessions.

Reconnected sessions

Indicates the number of sessions for this user that reconnected.

Number

Use the detailed diagnosis to know which sessions of the user, reconnected.