Desktop Session Start-up Details Test

Figure 1 depicts a typical user logon process to a virtual desktop via XenDesktop broker.

Figure 1 : Citrix user logon process

The process depicted by Figure 1 above has been described below:

  1. User provides his/her credentials to the web interface.
  2. Web interface forwards the credentials to controller for verification process.
  3. Delivery controller transfers these credentials to the domain controller to check if the user is present in the active directory.
  4. Once it gets the successful confirmation from AD then controller communicates with site database to check what type of virtual desktop is available for current user.
  5. Controller then interacts with the hypervisor layer to gather information about the availability of virtual desktop.
  6. Controller then passes the ICA file for user and all the connection information is present inside ICA file so that client can establish the connection.
  7. After all the process is complete, the user is assigned the virtual desktop.
  8. The user then establishes a connection with the assigned virtual desktop.
  9. The virtual desktop again communicates with controller for verification of licensing.
  10. Controller checks for license from license server about what type of license is available for user in this current session. License server then communicates back with controller providing the licensing information.
  11. Information obtained from license server is then passed to the virtual desktop.

From the discussion above, it can be inferred that login processing happens at two different places – at the delivery controller, and inside the virtual desktop. While login, authentication, and application brokering happen on the delivery controller, session creation and setup happens inside the virtual desktop. A problem in any of these places can result in a poor user experience. Inevitably, these issues result in service desk calls and complaints that “Citrix is slow.” Diagnosing login problems has traditionally been a difficult, time-consuming, manual process due to the large number of steps involved. The key to resolving user experience issues therefore, lies in tracking each user’s sessions end-to-end, ascertaining the time spent by the session at each step of the logon process – be it on the delivery controller or on the virtual desktop– and accurately identifying where and at what step of the logon process, the slowdown occurred.

To determine the time taken by the entire logon process of a user, isolate logon slowness, and understand where the process was bottlenecked – whether on the delivery controller or on the XenApp server – use the User Logon Performance test mapped to the Citrix XA/XD Site component. If the User Logon Performance test reveals a problem in session start-up on the virtual desktop, then use the Virtual Desktop Session Start-up Details test.    

With the Virtual Desktop Session Start-up Details test, administrators can receive deep visibility into the virtual desktop end of the Citrix logon process. This test takes an administrator into the virtual desktop, reveals the users who are currently logged on to the virtual desktop, and accurately reports the average time it took for the sessions of each user to start inside the virtual desktop. This way, administrators can rapidly identify which user’s sessions are experiencing undue start-up delays.

In addition, the test also provides a break-up of the session start-up duration. This way, the test precisely pinpoints where the delay occurred – when user credentials were obtained? when credentials were validated? during profile loading? during login script execution? when mapping drives or creating printers?

For this purpose, the test categorizes its metrics into client start-up metrics and server start-up metrics.

The client start-up metrics are concerned with timing the operations that occur from the point when the user requests for access to a virtual desktop to the point at which a connection to the virtual desktop is established. While connection-brokering mechanisms involve components that are not on the physical client device, the tasks these systems perform have a direct impact on the performance of the connection start-up and are recorded as part of the client-side process.

The server start-up metrics are concerned with timing the operations that occur when creating a new session on the virtual desktop. This includes user authentication, client device mapping, profile loading, login scripts execution, and finally, starting the user's desktop.

Target of the test : A Citrix Hypervisor

Agent deploying the test : An internal/remote agent

Outputs of the test : One set of results for every user_on_VM

Configurable parameters for the test
Parameter Description

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 specified host listens. By default, this is NULL.

Xen User, Xen Password and Confirm Password

To enable the eG agent to connect to the XenServer API for collecting statistics of interest, this test should login to the target hypervisor as a root user. Provide the name of the root user in the Xen User text box. Root user privileges are mandatory when monitoring a XenServer 5.5 (or below). However, if you are monitoring XenServer 5.6 (or above) and you prefer not to expose the credentials of the root user, then, you have the option of configuring a user with pool-admin privileges as the Xen User. If you do not want to expose the credentials of a root/pool-admin user, then you can configure the tests with the credentials of a Xen User with Read-only privileges to the XenServer. However, if this is done, then the Xen Uptime test will not run, and the Xen CPU and Xen Memory tests will not be able to report metrics for the control domain descriptor. To avoid such an outcome, do the following before attempting to configure the eG tests with a Xen User who has Read-only privileges to the Citrix Hypervisor:

  • Modify the target hypervisor's configuration in the eG Enterprise. For this, follow the Infrastructure -> Components -> Add/Modify menu sequence, pick Citrix Hypervisor as the Component type, and click the Modify button corresponding to the target hypervisor.
  • In the MODIFY COMPONENT DETAILS page that then appears, make sure that the os is set to Xen and the Mode is set to SSH.
  • Then, in the same page, proceed to provide the User and Password of a user who has the right to connect to the XenServer console via SSH.
  • Then, click the Update button to save the changes.

Once this is done, you can configure the eG tests with the credentials of a Xen User with Read-only privileges.

The password of the specified Xen User needs to be mentioned in the Xen Password text box.

Then, confirm the Xen Password by retyping it in the Confirm Password text box.
SSL

By default, the Citrix Hypervisor is not SSL-enabled. This indicates that by default, the eG agent communicates with the target hypervisor using HTTP. Accordingly, the SSL flag is set to No by default. If you configure the target hypervisor to use SSL, then make sure that the SSL flag is set to Yes, so that the eG agent communicates with the target hypervisor using HTTPS. Note that a default SSL certificate comes bundled with every Citrix Hypervisor installation. If you want the eG agent to use this default certificate for communicating with an SSL-enabled Citrix Hypervisor, then no additional configuration is required. However, if you do not want to use the default certificate, then you can generate a self-signed certificate for use by the target hypervisor. In such a case, you need to explicitly follow the broad steps given below to enable the eG agent to communicate with the target hypervisor via HTTPS:

  • Obtain the server-certificate for the Citrix Hypervisor
  • Import the server-certificate into the local certificate store of the eG agent

For a detailed discussion on each of these steps, refer to the Troubleshooting section of this document.

Inside View Using

By default, this test communicates with every VM remotely and extracts “inside view” metrics. Therefore, by default, the Inside View Using flag is set to Remote connection to VM (Windows).

Typically, to establish this remote connection with Windows VMs in particular, eG Enterprise requires that the eG agent be configured with domain administrator privileges. In high-security environments, where the IT staff might have reservations about exposing the credentials of their domain administrators, this approach to extracting “inside view” metrics might not be preferred. In such environments therefore, eG Enterprise provides administrators the option to deploy a piece of software called the eG VM Agent on every Windows VM; this VM agent allows the eG agent to collect “inside view” metrics from the Windows VMs without domain administrator rights. Refer to Configuring Windows Virtual Machines to Support the eG Agent’s Inside View Using the eG VM Agent for more details on the eG VM Agent. To ensure that the “inside view” of Windows VMs is obtained using the eG VM Agent, set the Inside View Using flag to eG VM Agent (Windows). Once this is done, you can set the Domain, Admin User, and Admin Password parameters to none.

Domain, Admin User, and Admin Password, and Confirm Password

By default, this test connects to each virtual guest remotely and attempts to collect “inside view” metrics. In order to obtain a remote connection, the test must be configured with user privileges that allow remote communication with the virtual guests. The first step towards this is to specify the DOMAIN within which the virtual guests reside. The ADMIN USER and ADMIN PASSWORD will change according to the DOMAIN specification. Discussed below are the different values that the DOMAIN parameter can take, and how they impact the ADMIN USER and ADMIN PASSWORD specifications:

  • If the VMs belong to a single domain : If the guests belong to a specific domain, then specify the name of that domain against the DOMAIN parameter. In this case, any administrative user in that domain will have remote access to all the virtual guests. Therefore, an administrator account in the given domain can be provided in the ADMIN USER field and the corresponding password in the ADMIN PASSWORD field. Confirm the password by retyping it in the CONFIRM PASSWORD text box.

  • If the guests do not belong to any domain (as in the case of Linux guests) : In this case, specify "none" in the DOMAIN field, and specify a local administrator account name in the ADMIN USER below.

    Prior to this, you need to ensure that the same local administrator account is available or is explicitly created on each of the virtual machines to be monitored. Then, proceed to provide the password of the ADMIN USER against ADMIN PASSWORD, and confirm the password by retyping it in the CONFIRM PASSWORD text box.

    If key-based authentication is implemented between the eG agent and the SSH daemon of a Linux guest, then, in the ADMIN USER text box, enter the name of the user whose <USER_HOME_DIR> (on that Linux guest) contains a .ssh directory with the public key file named authorized_keys. The ADMIN PASSWORD in this case will be the passphrase of the public key; the default public key file that is bundled with the eG agent takes the password eginnovations. Specify this as the ADMIN PASSWORD if you are using the default private/public key pair that is bundled with the eG agent to implement key-based authentication. On the other hand, if you are generating a new public/private key pair for this purpose, then use the passphrase that you provide while generating the pair. For the detailed procedure on Implementing Key-based Authentication refer to Troubleshooting the Failure of the eG Remote Agent to Connect to or Report Measures for Linux Guests.

  • If the guests belong to different domains - In this case, you might want to provide multiple domain names. If this is done, then, to access the guests in every configured domain, the test should be configured with the required user privileges; this implies that along with multiple DOMAIN names, multiple ADMIN USER names and ADMIN PASSWORDs would also have to be provided. To help administrators provide these user details quickly and easily, the eG administrative interface embeds a special configuration page.

    To access this page, simply click on the Click here hyperlink that appears just above the parameters of this test in the test configuration page. To know how to use the special page, refer to Configuring Users for VM Monitoring.

  • If the INSIDE VIEW USING flag is set to ‘eG VM Agent (Windows)’ - In this case, the inside view can be obtained without domain administrator privileges. Therefore, set the domain, admin user, and admin password parameters to none.

Ignore VMs Inside View

Administrators of some high security XenServer environments might not have permissions to internally monitor one/more VMs. The eG agent can be configured to not obtain the 'inside view' of such ‘inaccessible’ VMs using the IGNORE VMS INSIDE VIEW parameter. Against this parameter, you can provide a comma-separated list of VM names, or VM name patterns, for which the inside view need not be obtained. For instance, your IGNORE VMS INSIDE VIEW specification can be: *xp,*lin*,win*,vista. Here, the * (asterisk) is used to denote leading and trailing spaces (as the case may be). By default, this parameter is set to none indicating that the eG agent obtains the inside view of all VMs on a Citrix Hypervisor host by default.

Note:

While performing VM discovery, the eG agent will not discover the operating system of the VMs configured in the IGNORE VMS INSIDE VIEW text box.

Exclude VMs

Administrators of some virtualized environments may not want to monitor some of their less-critical VMs - for instance, VM templates - both from 'outside' and from 'inside'. The eG agent in this case can be configured to completely exclude such VMs from its monitoring purview. To achieve this, provide a comma-separated list of VMs to be excluded from monitoring in the EXCLUDE VMS text box. Instead of VMs, VM name patterns can also be provided here in a comma-separated list. For example, your EXCLUDE VMS specification can be: *xp,*lin*,win*,vista. Here, the * (asterisk) is used to denote leading and trailing spaces (as the case may be). By default, this parameter is set to none indicating that the eG agent obtains the inside and outside views of all VMs on a virtual host by default. By providing a comma-separated list of VMs/VM name patterns in the EXCLUDE VMS text box, you can make sure the eG agent stops collecting 'inside' and 'outside' view metrics for a configured set of VMs.

Ignore Winnt

By default, the eG agent does not support the inside view for VMs executing on Windows NT operating systems. Accordingly, the IGNORE WINNT flag is set to Yes by default.

Webport

By default, in most virtualized environments, the target hypervisor listens on port 80 (if not SSL-enabled) or on port 443 (if SSL-enabled). This implies that while monitoring an SSL-enabled Citrix hypervisor, the eG agent, by default, connects to port 443 of the server to pull out metrics, and while monitoring a non-SSL-enabled Citrix hypervisor, the eG agent connects to port 80. Accordingly, the webport parameter is set to 80 or 443 depending upon the status of the ssl flag.  In some environments however, the default ports 80 or 443 might not apply. In such a case, against the webport parameter, you can specify the exact port at which the target hypervisor in your environment listens so that the eG agent communicates with that port.

Report by User

While monitoring a Citrix hypervisor, the REPORT BY USER flag is set to No by default, indicating that by default, the guest operating systems on the target hypervisor are identified using the host name specified in the operating system. On the other hand, while monitoring a Citrix hypervisor-VDI, this flag is set to Yes by default; this implies that in case of the Citrix hypervisor-VDI model, by default, the desktops will be identified using the login of the user who is accessing them. In other words, in VDI environments, this test will, by default, report measures for every username_on_virtualmachinename.

Report Powered OS

This flag becomes relevant only if the report by user flag is set to ‘Yes’.

If the report powered os flag is set to Yes (which is the default setting), then this test will report measures for even those VMs that do not have any users logged in currently. Such guests will be identified by their virtualmachine name and not by the username_on_virtualmachinename. On the other hand, if the report powered os flag is set to No, then this test will not report measures for those VMs to which no users are logged in currently.

Report Powered ON

You can set the REPORT POWERED ON status to Yes, so that the test reports an additional measure, Is VM powered on?, revealing whether a guest OS is currently running or not. The default status of this flag is set to Yes for a Citrix hypervisor. For a Citrix Hypervisor – VDI component on the other hand, this flag is set to No by default. This is because, in such environments, the virtual desktops will be in the powered-off state most of the time.

Detailed Diagnosis

  1. To make diagnosis more efficient and accurate, the eG suite 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.
   
Measurements made by the test
Measurement Description Measurement Unit Interpretation

New sessions

Indicates the number of sessions currently open for this user on this virtual desktop.

Number

Use the detailed diagnosis of this measure to view the complete details of this user’s session. Such details includes the name and IP address of the client from which the session was launched, when session creation started, and when it ended. With the help of this information, administrators can quickly understand if the session took too long to get created.

Session start-up duration

Indicates the time taken by this user to complete session start-up inside this virtual desktop.

Secs

Compare the value of this measure across users to know which user’s sessions took the longest to start on the virtual desktop. To know what is causing this ‘slowness’, compare the values reported by all the other ‘duration’ measures of this test for that user on that virtual desktop. This will quickly lead you to where that user’s session start-up is spending the maximum time.

Profile processing duration

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

Seconds

 

Group Policy processing duration

Indicates the time taken by this user’s session to process group policies.

Secs

If a user’s Session start-up duration is high, you may want to compare the value of this measure with that of the other ‘duration’ measures reported for this user to figure out if a delay in group policy processing is what is really ailing that user’s logon experience with this virtual desktop. In such a case, you can also use the detailed diagnosis of this measure to figure out the names of the group policy client-side extensions (CSE), the time each CSE took to run, the status of every CSE, and errors (if any) encountered by each CSE. Using these in-depth metrics, Citrix administrators can accurately pinpoint which CSE is impeding speedy group policy processing.

Note:

Detailed diagnostics will be available for this measure only if the eG VM Agent is deployed on the virtual desktops and the inside view using parameter of this test is set to eG VM Agent.

Logon performance improves when fewer Group Policies are applied. Merge GPOs when possible instead of having multiple GPOs.

Logon script execution duration

Indicates the time taken for the login script to execute for this user.

 

Secs

If a user complains of slowness, then, you can compare the value of this measure with that of the other ‘duration’ measures of that user to figure out what could have really caused the slowness.

Client side session start-up processing duration

This is the high-level client-side connection start-up metric. It starts at the time of the request (mouse click) and ends when the connection between this user’s client device and the virtual desktop has been established.

Secs

When any user complains of slowness when trying to logon to a virtual desktop, you may want to compare the value of this measure with that of the Server side session start-up processing duration duration measure of that user to know whether a client-side issue or a server-side issue is responsible for the slowness he/she is experiencing with that virtual desktop.

If this comparison reveals that the Client side session start-up processing duration of the user is high, it indicates a client-side issue that is causing long start times. In this case therefore, compare the value of the client start-up metrics such as the Application enumeration duration, Configuration file download duration, User credential obtention by client duration, ICA file download duration, Launch page web server duration, Name resolution duration, Name resolution web server duration, Session lookup duration, Session creation at client duration, Ticket response web server duration, Reconnect enumeration duration, and Reconnect enumeration web server duration to know what client-side issue is causing the Client side session start-up processing duration to be high.  

Backup URL count

This measure is relevant when the Citrix Workspace App is the session launch mechanism. It records the number of back-up URL retries before a successful launch. Note that this is the only start-up metric that is a measure of attempts, rather than time duration.

Number

If this metric has a value higher than 1, it indicates that the Web Interface server is unavailable and the Citrix Workspace App is attempting to connect to back-up Web Interface servers to launch the virtual desktop.

A value of 2 means that the main Web Interface server was unavailable, but the Citrix Workspace App managed to launch the virtual desktop successfully using the first back-up server that it tried.

A value higher than 2 means that multiple Web Interface servers are unavailable. Probable reasons for the non-availability of the Web Interface servers include (in order of likelihood):

  • Network issues between the client and the server. So the administrator should make sure that the Web Interface server is on the network and accessible to the clients.
  • An overloaded Web Interface server that is not responding (or has crashed for another reason). Try to log on to the server and check the Windows Performance Monitor/Task Manager to see how much memory is in use and so on. Also, review the Event Logs to see if Windows logged any serious errors.

Application enumeration duration

This measure is relevant when the Citrix Workspace App is the session launch mechanism. It measures the time needed by this user’s session to retrieve the list of applications from the Web Interface service.

Secs

If the Client side session start-up processing duration measure reports a high value for a user, then compare the value of this measure with that of the other client-side metrics such as Configuration file download duration, User credential obtention by client duration, ICA file download duration, Launch page web server duration, Name resolution duration, Name resolution web server duration, Session lookup duration, Session creation at client duration, Ticket response web server duration, Reconnect enumeration duration, and Reconnect enumeration web server duration to know whether/not slowness in application enumeration is the precise reason why it took the user a long time to establish a session with the virtual desktop. 

Configuration file download duration

This measure is relevant when the Citrix Workspace App is the session launch mechanism. It measures the time this user’s session took to retrieve the configuration file from the XML broker.

Secs

If the Client side session start-up processing duration measure reports a high value for a user, then compare the value of this measure with that of the other client-side metrics such as Application enumeration duration, User credential obtention by client duration, ICA file download duration, Launch page web server duration, Name resolution duration, Name resolution web server duration, Session lookup duration, Session creation at client duration, Ticket response web server duration, Reconnect enumeration duration, and Reconnect enumeration web server duration to know whether/not slowness in retrieving the configuration file from the XML server is the precise reason why it took the user a long time an ICA session with the XenApp server. 

User credential obtention by client duration

This measure is relevant when the Citrix Workspace App is the session launch mechanism. It measures the time required by this user’s session to obtain the user credentials.

 

Note that COCD is only measured when the credentials are entered manually by the user. Because this metric may be artificially inflated if a user fails to provide credentials in a timely manner, it is subtracted from the Start-up client duration.

However, in the event that the user manually inputs the credentials, and the value of this measure is higher than that of all the other client start-up metrics that this test reports, it is a clear indicator that any connection delay that the user may have experienced is owing to slowness in obtaining user credentials.

ICA file download duration

This measure is relevant when the Citrix Workspace App is the session launch mechanism. This is the time it takes for this user’s client to download the ICA file from the web server.

Secs

The overall process here is:

  1. The user clicks on application icon.
  2. The user's browser requests the Web Interface launch page.
  3. The Web Interface launch page receives the request and starts to process the launch, communicating with the virtual desktop and potentially other components such as Secure Ticket Authority (STA).
  4. The Web Interface generates ICA file data.
  5. The Web Interface sends the ICA file data back to the user's browser.
  6. The browser passes ICA file data to the client.

This measure represents the time it takes for the complete process (step 1 to 6). The measure stops counting time when the client receives the ICA file data.

The Launch page web server duration measure on the other hand, covers the Web server portion of the process (that is, steps 3 and 4).

If the ICA file download duration is high, but the Launch page web server duration is normal, it implies that the server-side processing of the launch was successful, but there were communication issues between the client device and the Web server. Often, this results from network trouble between the two machines, so investigate potential network issues first.

Launch page web server duration

This measure is relevant when the Web Interface is the session launch mechanism. It measures the time needed by this user’s session to process the launch page (launch. aspx) on the Web Interface server.

Secs

If the value of this measure is high, it indicates at a bottleneck on the Web Interface server.

Possible causes include:

  • High load on the Web Interface server. Try to identify the cause of the slow down by checking the Internet Information Services (IIS) logs and monitoring tools, Task Manager, Performance Monitor and so on.
  • Web Interface is having issues communicating with the other components. Check to see if the network connection between Web Interface and virtual desktop is slow. If the Web server seems okay, consider reviewing the virtual desktop for problems.

Name resolution duration

This is the time it takes the XML service to resolve the name of a published application to an IP address.

Secs

This metric is collected when a client device directly queries the XML Broker to retrieve published application information stored in IMA. This measure is only gathered for new sessions since session sharing occurs during startup if a session already exists.

When this metric is high, it indicates the XML Broker is taking a lot of time to resolve the name of a published application to an IP address. Possible causes include a problem on the client, issues with the XML Broker, such as the XML Broker being overloaded, a problem with the network link between the two, or a problem in IMA. Begin by evaluating traffic on the network and the XML Broker.

Name resolution web server duration

This measure is relevant when the Citrix Workspace App is the session launch mechanism. It is the time it takes the XML service to resolve the name of this virtual desktop to its IP address.

Secs

When this metric is high, there could be an issue with the Web Interface server or the Citrix Workspace App, the XML Service, the network link between the two, or a problem in IMA.

Like the Name resolution client duration measure, this metric indicates how long it takes the XML service to resolve the name of a virtual desktop to its IP address. However, this metric is collected when a Web Interface site is performing this process on behalf of a launch request it has received from either the Citrix Workspace App or from a user clicking a Web Interface page icon.

Session lookup duration

Indicates the time this user’s session takes to query every ICA session to host the requested published application.

MSecs

The check is performed on the client to determine whether the application launch request can be handled by an existing session. A different method is used depending on whether the session is new or shared.

Session creation at client duration

Indicates the new session creation time.

Secs

In the event of slowness, if the Client side session start-up processing duration of a user session is found to be higher than the Session start-up server duration, you may want to compare the value of this measure with all other client start-up measures to determine whether/not session creation is the process that is slowing down the application launch. 

Ticket response web server duration

This measure is relevant when the Citrix Workspace App or Web Interface is the desktop launch mechanism. This is the time this user’s sessions take to get a ticket (if required) from the STA server or XML service.

Secs

When this metric is high, it can indicate that the Secure Ticket Authority (STA) server or the XML Broker are overloaded.

Reconnect enumeration duration

This measure is relevant when the Citrix Workspace App or Web Interface is the desktop launch mechanism. This is the time it takes this user’s client to get a list of reconnections.

Secs

Compare the value of this measure with that of other client start-up metrics for a user to know what is the actual cause for the client start-up delay.

Reconnect enumeration web server duration

This measure is relevant when the Citrix Workspace App or Web Interface is the desktop launch mechanism. This is the time it takes the Web Interface to get the list of reconnections for this user from the XML service.

Secs

Compare the value of this measure with that of other client start-up metrics for a user to know what is the actual cause for the client start-up delay.

Server side session start-up processing duration

This is the high-level server-side connection start-up metric. It includes the time spent on this virtual desktop to perform the entire start-up operation.

Secs

When this metric is high, it indicates that there is a server-side issue increasing session start times. To zero-in on this issue, compare the values of the server start-up metrics such as  Session creation server duration, User credential obtention by server duration, Program neighbourhood credentials obtention server duration, Pass-through credentials duration, Credential authentication duration, Profile load server duration, Session creation processing duration, Endpoint resources mapping duration, Endpoint printers mapping duration.

Session creation server duration

Indicates the time spent by this virtual desktop in creating the session for this user.

Secs

This duration starts when the ICA client connection has been opened and ends when authentication begins. This should not be confused with ‘Session start-up server duration’.

User credential obtention by server duration

Indicates the time taken by this virtual desktop to obtain the credentials of this user.

Secs

This time is only likely to be a significant if manual login is being used and the server-side credentials dialog is displayed (or if a legal notice is displayed before login commences). Because this metric may be artificially inflated if a user fails to provide credentials in a timely manner, it is not included in the Session start-up server duration.

However, in the event that the user manually inputs the credentials, and the value of this measure is higher than that of all the other client start-up metrics that this test reports, it is a clear indicator that any connection delay that the user may have experienced is owing to slowness in obtaining user credentials.

Pass-through credentials duration

Indicates the time spent by this virtual desktop performing network operations to obtain credentials for this user.

Secs

This only applies to a Security Support Provider Interface login (a form of pass-through authentication where the client device is a member of the same domain as the server and Kerberos tickets are passed in place of manually entered credentials).

Program neighbourhood credentials obtention server duration

Indicates the time needed for this virtual desktop to cause the Program Neighborhood instance running on the client (“Program Neighborhood Classic”) to obtain this user’s credentials.

Secs

As in the case of the User credential obtention by server duration metric, because this metric may be artificially inflated if a user fails to provide credentials in a timely manner, it  is not included in the Server side session start-up processing duration duration.

Credential authentication duration

Indicates the time spent by this virtual desktop when authenticating the user’s credentials against the authentication provider, which may be Kerberos, Active Directory or a Security Support Provider Interface (SSPI).

Secs

Where server-side issues are causing user experience to deteriorate, you can compare the value of this measure with that of all the other server start-up metrics that this test reports – i.e., Session creation server duration, User credential obtention by server duration, Program neighbourhood credentials obtention server duration, Pass-through credentials duration, Profile load server duration, Session creation processing duration, Endpoint resources mapping duration, Endpoint printers mapping duration – to know what is the root-cause of delays in server start-up.   

Profile content processing duration

Indicates the time required by this virtual desktop to load this user’s profile.

Secs

If this metric is high, consider your Terminal Services profile configuration. Citrix Consulting has found that when customers have logon times greater than 20 seconds, in most cases, this can be attributed to poor profile and policy design. Roaming profile size and location contribute to slow session starts. When a user logs onto a session where Terminal Services roaming profiles and home folders are enabled, the roaming profile contents and access to that folder are mapped during logon, which takes additional resources. In some cases, this can consume significant amounts of the CPU usage.

Consider using the Terminal Services home folders with redirected personal folders to mitigate this problem. In general, consider using Citrix Profile management to manage user profiles in Citrix environments. This tool also provides logging capabilities to help isolate profile issues.

If you are using Citrix profile management and have slow logon times, check to see if your antivirus software is blocking the Citrix profile management tool.

Session creation processing duration

Indicates the time needed by this virtual desktop to run this user’s login script(s).

Secs

If the value of this measure is abnormally high for any user, consider if you can streamline this user or group's login scripts. Also, consider if you can optimize any application compatibility scripts or use environment variables instead.

Endpoint resources mapping duration:

Indicates the time needed for this virtual desktop to map this user’s client drives, devices and ports.

Secs

Make sure that, when possible, your base policies include settings to disable unused virtual channels, such as audio or COM port mapping, to optimize the ICA protocol and improve overall session performance.

Endpoint printers mapping duration

Indicates the time required for this virtual desktop to synchronously map this user’s client printers.

Secs

If the configuration is set such that printer creation is performed asynchronously, no value is recorded for this measure as it is does not impact completion of the session start-up.

On the other hand, if excessive time is spent mapping printers, it is often the result of the printer autocreation policy settings. The number of printers added locally on the users' client devices and your printing configuration can directly affect your session start times. When a session starts, the virtual desktop has to create every locally mapped printer on the client device. Consider reconfiguring your printing policies to reduce the number of printers that get created - especially if users have a lot of local printers.

Has user's session been reconnected?

Indicates whether/not this user session reconnected.

 

The values that this measure can report and their corresponding numeric values are discussed in the table above:

Measure Value Numeric Value
Yes 1
No 0

Note:

By default, this measure reports the Measure Values listed in the table above. In the graph of this measure however, the value of this measure is represented using their numeric equivalents only.

Profile provider

Indicates the provider who handles this user's profile.

 

The values reported by this measure and their corresponding numeric equivalents are described in the table below:

Measure Values Numeric Values
Citrix Profile management 0
Microsoft Roaming profile 1
Others 2

Note:

By default, this measure reports the above-mentioned Measure Values while indicating the provider who handles this user's profile. However, in the graph of this measure, the values will be represented using the corresponding numeric equivalents i.e., 0 to 2.

Profile type

Indicates the type of this user's profile.

 

The values reported by this measure and their corresponding numeric equivalents are described in the table below:

Measure Values Numeric Values
Managed profile 0
Temporary profile 1
Mandatory profile 2
Roaming profile 3
Unknown type 4

Note:

By default, this measure reports the above-mentioned Measure Values while indicating the profile type of this users. However, in the graph of this measure, the values will be represented using the corresponding numeric equivalents i.e., 0 to 4.

Group Policy processing status

Indicates the current status of the Group policy that is applied for this user.

 

The values reported by this measure and their corresponding numeric equivalents are described in the table below:

Measure Values Numeric Values
Success 1
Warning 2
Error 3

Note:

By default, this measure reports the above-mentioned Measure Values while indicating the current status of the Group policy. However, in the graph of this measure, the values will be represented using the corresponding numeric equivalents i.e., 1 to 3.

User account discovery

Indicates the amount of time taken by the LDAP call for this user to connect and bind to Active Directory during the last measurement period.

Secs

Compare the value of this measure across users to know which user’s logon process spent maximum time in retrieving account information.

To know which domain controller and DNS is being used, use the detailed diagnosis of this measure.

LDAP bind time to active directory

Indicates the amount of time taken by the LDAP call for this user to connect and bind to Active Directory during the last measurement period.

Secs

Compare the value of this measure across users to know which user’s logon process spent maximum time in connecting to Active Directory. Besides impacting authentication time, high LDAP bind time may also affect group policy processing.

Domain Controller discovery time

Indicates the time taken to discover the domain controller to be used for processing group policies for this user during the last measurement period.

Secs

Compare the value of this measure across users to know which user’s logon process spent maximum time in domain controller discovery.

Total Group Policy Object file access time

Indicates the amount of time the logon process took to access group policy object files for this user during the last measurement period.

Secs

Compare the value of this measure across users to know which user’s logon process spent maximum time in accessing the group policy object file.

To know which files were accessed and the time taken to access each file, use the detailed diagnosis of this measure. With the help of the detailed diagnostics, you can accurately isolate the object file that took the longest to access, and thus delayed the logon process.

Total Client-side extensions applied

Indicates the total number of client side extensions used for processing group policies for this user during the last measurement period.

Number

 

Client-side extensions with success state

Indicates the number of client side extensions that were successfully used for processing group policies for this user during the last measurement period.

Number

Use the detailed diagnosis of this measure to know which were the successful client side extensions for a user, and which group policy was processed by each extension.

Client-side extensions with warning state

Indicates the number of warnings received when client side extensions were used for processing group policies for this user during the last measurement period.

Number

Use the detailed diagnosis of this measure to know which were the client side extensions that resulted in the generation of warning events at the time of processing. You will also know which group policies were processed by each extension.

Client-side extensions with error state

Indicates the number of errors registered when client side extensions were used for processing group policies for this user during the last measurement period.

Number

Ideally, the value of this measure should be zero. A sudden/gradual increase in the value of this measure is a cause of concern.

If a non-zero value is reported for this measure, then use the detailed diagnosis of this measure to know which client side extensions resulted in processing errors. You will also know which group policies were processed by each such extension. Moreover, the error code will also be displayed as part of detailed diagnostics, so that you can figure out what type of error occurred when processing the client side extensions.

Total Client-side extension processed time

Indicates the amount of time that client side extensions took for processing group policies for this user during the last measurement period.

Secs

Compare the value of this measure across users to know which user's logon process spent maximum time in client side extension processing.

If this measure reports an unusually high value for any user, then, you may want to check the value of the LDAP bind time to active directory measure for that user to figure out if a delay in connecting to AD is affecting group policy processing. This is because, group policies are built on top of AD, and hence rely on the directory service's infrastructure for their operation. As a consequence, DNS and AD issues may affect Group Policies severely. One could say that if an AD issue does not interfere with authentication, at the very least it will hamper group policy processing.

You can also use the detailed diagnosis of this measure to know which client side extension was used to process which group policy for a particular user. Detailed diagnostics also reveal the processing time for each client side extension. This way, you can quickly identify the client side extension that took too long to be processed and thus delayed the user logon.

Estimated network bandwidth between VM and Domain Controller

Indicates the estimated network bandwidth between the VM and domain controller for this user during the last measurement period.

Kbps

 

Is link between VM and Domain Controller slow?

Indicates whether/not the network connection between the VM and domain controller is currently slow for this user.

 

Several components of Group Policy rely on a fast network connection. If a fast connection is unavailable between a VM and the DOC, group policy processing can be delayed. This is why, if the Group Policy processing duration measure reports an abnormally high value, you may want to check the value of the Is link between VM and domain controller slow? measure to determine whether the network connection between the VM and domain controller is slow.

If the network connection between the VM and domain controller is slow for a user, then this measure will report the value Yes. If it is fast, then this measure will report the value No (connection is fast).

The numeric values that correspond to the above-mentioned measure values are as follows:

Measure Value Numeric Value
Yes 1
No (connection is fast) 2

Note:

  • By default, this test reports the Measure Values listed in the table above to indicate the quality of the network link between the VM and the domain controller. In the graph of this measure however, the same is indicated using the numeric equivalents only.
  • To determine whether the network link is slow or fast, the Group Policy service compares the result of the estimated bandwidth to the slow link threshold (configured by Group Policy). A value below the threshold results in the Group Policy service flagging the network connection as a slow link. This measure reports the status of this flag only. To know the slow link threshold that the Group Policy has configured for this link, use the detailed diagnosis of this measure.

Is the user's profile size large?

Indicates whether the profile size of this user exceeds the default profile quota size of 100MB.

Boolean

If this measure shows 0, it indicates that the current profile size has not exceeded the quota size. The value 1 indicates that the current profile size has exceeded the quota size.

Current profile size

Indicates the current profile size of this user.

MB

 

Number of files in user’s profile

Indicates the number of files available in this user profile.

Number

 

Large files in user’s profile

The number of files in this user profile, which exceed the default file size limit of 100 MB.

Number

The detailed diagnosis of this measure, if enabled, lists all the files that have exceeded the default file size limit of 100 MB.

Group Policy applied on

Indicates whether the group policy for this user is applied during foreground processing or background processing.

 

Foreground and background processing are key concepts in Group Policy. Foreground processing only occurs when the machine starts up or when the user logs on. Some policy areas (also called Client Side Extensions (CSEs)) can only run during foreground processing. Examples of these include Folder Redirection, Software Installation and Group Policy Preferences Drive Mapping. In contrast, background processing is that thing that occurs every 90 or so minutes on Windows workstations, where GP refreshes itself periodically. Background processing happens in the background, while the user is working and they generally never notice it. While background processing does not impact performance, foreground processing can extend start and login times.

The values that this measure can report and their corresponding numeric values are listed in the table below:

Measure Value Numeric Value
Background 1
Foreground 2

Note:

By default, this test reports the Measure Values listed in the table above to indicate when the group policy of a user was applied. In the graph of this measure however, the same is indicated using the numeric equivalents only.

Group Policy processing mode

Indicates whether the group policies of this user are processed in the synchronous or asynchronous mode.

 

Foreground processing can operate under two different modes - synchronously or asynchronously. Asynchronous GP processing does not prevent the user from using their desktop while GP processing completes. For example, when the computer is starting up, GP asynchronous processing starts to occur for the computer, and in the meantime, the user is presented the Windows logon prompt. Likewise, for asynchronous user processing, the user logs on and is presented with their desktop while GP finishes processing. The user is not delayed getting either their logon prompt or their desktop during asynchronous GP processing. When foreground processing is synchronous, the user is not presented with the logon prompt until computer GP processing has completed after a system boot. Likewise the user will not see their desktop at logon until user GP processing completes. This can have the effect of making the user feel like the system is running slow. In short, synchronous processing can impact startup time, where asynchronous does not. Foreground processing will run synchronously for two reasons:

  • The administrator forces synchronous processing through a policy setting. This can be done by enabling the Computer ConfigurationPoliciesAdministrative TemplatesSystemLogonAlways wait for the network at computer startup and logon policy setting. Enabling this setting will make all foreground processing synchronous. This is commonly used for troubleshooting problems with Group Policy processing, but does not always get turned back off again.

  • A particular CSE requires synchronous foreground processing. There are four CSEs provided by Microsoft that currently require synchronous foreground processing: Software Installation, Folder Redirection, Microsoft Disk Quota and GP Preferences Drive Mapping. If any of these are enabled within one or more GPOs, they will trigger the next foreground processing cycle to run synchronously when they are changed.

It is therefore best to avoid synchronous CSEs and to not force synchronous policy. If usage of synchronous CSEs is necessary, minimize changes to these policy settings.

The values that this measure can report and their corresponding numeric values are listed in the table below:

Measure Value Numeric Value
Synchronous 1
Asynchronous 2

Note:

By default, this test reports the Measure Values listed in the table above to indicate when the group policy of a user was applied. In the graph of this measure however, the same is indicated using the numeric equivalents only.