Virtual Desktop User Logon Experience Test

When a user clicks on an icon to launch an application delivered by VDI server, you will see a description of the processes that are taking place to launch the requested application. Any problem experienced in the launch process - within the VDI infrastructure or the supporting infrastructure components (e.g., the Active Directory server, the License server, the Web Interface server, the Profile server, etc.) - can result in a poor user experience. Inevitably, these issues result in service desk calls and complaints that “VDI is slow.” Diagnosing login problems has traditionally been a difficult, time-consuming, manual process due to the large number of steps involved, many of which are external to the VDI server. Critical operations such as user login script execution and profile loading can significantly elongate the overall login experience for a VDI user. The key to resolving user experience issues therefore, lies in tracking each user session with the VDI server, ascertaining the time spent by the session at each step of the logon process - be it within or external to the VDI server - and accurately identifying at what step of the logon process, the slowdown occurred - when user credentials are obtained? When credentials are validated? During profile loading? During login script execution? When mapping drives or creating printers? This is exactly what the Virtual Desktop User Logon Experience does.

This test captures every user login to the VDI server, provides visibility into each individual step involved in the login process of that user, and the time required for each step to finish. 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 an application, e.g., by clicking an icon, to the point at which an instance of the ICA client has finished opening a connection to Presentation Server. While connection-brokering mechanisms, such as Web Interface for VDI server or Program Neighborhood Agent, 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 VDI server. This includes user authentication, client device mapping, profile loading, login scripts execution, and finally, starting the user's application (in the case of a desktop this will be explorer.exe). If a session already exists and a new application is being started through session sharing, only the application start stage will be considered as part of server start-up.

The total time required for these two areas to complete will directly affect the experience of the user while waiting for their application to become ready. This way, the test pinpoints those users whose logins were slow, and also reveals the specific causes of slow logins. This visibility enhances the performance of applications delivered by VDI server, resulting in a better user experience.

Target of the test : A VDI-in-a-Box Manager

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
Parameters Description

Test period

This indicates how often should the test be executed.

Host

The host for which this test is to be configured.

Port

The port at which the specified host listens to. By default, this is NULL.

Virtual Center

If the eG manager had discovered the target ESX server by connecting to vCenter, then the IP address of the vCenter server used for discovering this ESX server would be automatically displayed against the Virtual Center parameter; similarly, the ESX User and ESX Password text boxes will be automatically populated with the vCenter user credentials, using which ESX discovery was performed.

If this ESX server has not been discovered using vCenter, but you still want to monitor the ESX server via vCenter, then select the IP address of the vCenter host that you wish to use for monitoring the ESX server from the Virtual Center list. By default, this list is populated with the IP address of all vCenter hosts that were added to the eG Enterprise system at the time of discovery. Upon selection, the ESX User and ESX Password that were pre-configured for that vCenter server will be automatically displayed against the respective text boxes.

On the other hand, if the IP address of the vCenter server of interest to you is not available in the list, then, you can add the details of the vCenter server on-the-fly, by selecting the Other option from the VIRTUAL CENTER list. This will invoke the ADD VCENTER SERVER DETAILS page. Refer to Section 3.1.1.1.1 to know how to add a vCenter server using this page. Once the vCenter server is added, its IP address, ESX User, and ESX Password will be displayed against the corresponding text boxes.

On the other hand, if you want the eG agent to behave in the default manner -i.e., communicate with each ESX server for monitoring it - then set the Virtual Center parameter to ‘none’. In this case, the ESX User and ESX Password parameters can be configured with the credentials of a user who has at least ‘Read-only’ privileges to the target ESX server.

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 the eG Agent to Collect Current Hardware Status Metrics section 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, 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 VMs 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 VM Details – ESX Testsection.
  • If the guests do not belong to any domain : 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 the Monitoring Xen Servers.

  • If the inside view using flag is set to ‘eG VM Agent (Windows)’: On the other hand, if the Inside View Using flag is set to eG VM Agent (Windows) , then it implies that 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 Hyper-V VDI 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, you 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 virtual 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.

Report By User

While monitoring a Hyper-V VDI, the Report By User flag is set to No by default, indicating that by default, the guest operating systems on the Hyper-V VDI are identified using the hostname specified in the operating system. On the other hand, while monitoring a Hyper-V VDI, this flag is set to Yes by default; this implies that in case of the Hyper-V 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 By Managertime

By default, this flag is set to Yes. This indicates that the user login time displayed in the DETAILED DIAGNOSIS page for this test and in the Thin Client reports will be based on the eG manager's time zone by default. Set this flag to No if you want the login times displayed in the DETAILED DIAGNOSIS page for this test and in the Thin Client reports to be based on the virtual server's local time.

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, 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

User sessions

Indicates the number of sessions currently open for this user on the VDI server.

Number

Compare the value of this measure across users to know which user has the maximum number of open sessions. In the event of an overload, this will point you to that user who is contributing the most to the workload of the VDI server.

Use the detailed diagnosis of this measure to view the complete details of each user session. Such details includes the name and IP address of the client from which every session was launched, when session creation started, and when it ended. With the help of this information, administrators can quickly pinpoint those sessions that may have taken too long to be created.

Logon duration

Indicates the time taken by this user to complete the logon process.

Secs

Compare the value of this measure across users to know which user took the longest to logon to the VDI server. To know what is causing this ‘slow login’, compare the values reported by all the other ‘duration’ measures of this test for that user. This will quickly lead you to where that user's logon process is spending the maximum time.

Profile load duration

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

Secs

Compare the value of this measure across users to know which user's profile took the longest to load. If that user's Logon 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 profile loading is what is really ailing that user's logon experience.

One of the common reasons for high profile load time is the large size of the user profile. Use the User Profile test to know if this user's profile is indeed exceeding the configured size limit. If so, use the User Profile test again to know which specific files in that user's profile are contributing to its large size, and check if such files can be deleted to reduce profile size, and consequently, the logon duration.

Moreover, this measure reports the average time taken for loading a user's profile across all the sessions of that user. To know the profile load time per user session, use the detailed diagnosis of this measure. This will accurately pinpoint the session in which the profile took the longest to load.

Group policy processing duration

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

Secs

Compare the value of this measure across users to know which user's sessions took the longest time to process group policies. If that user's Logon 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.

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

Login script execution duration

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

Secs

Compare the value of this measure across users to know for which user the login script took the longest time to execute.

If this 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.

Start-up client 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 ICA connection between this user's client device and VDI server has been established.

Secs

In the case of a shared session, this duration will normally be much shorter, as many of the set-up costs associated with the creation of a new connection to the server are not incurred.

When any user complains of slowness, you may want to compare the value of this measure with that of the Session start-up server duration measure of that user to know whether a client-side issue or a server-side issue is responsible for the slowness.

If this comparison reveals that the Start-up client 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 client duration, Configuration file download client duration, Credentials obtention client duration, ICA file download duration, Launch page web server duration, Name resolution client duration, Name resolution web server duration, Session look-up client duration, Session creation client duration, and Ticket response web server duration to know what client-side issue is causing the Start-up client duration to be high.

Back-up URL client count

This measure is relevant when the Citrix receiver is the application 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 receiver (formerly known as Program Neighborhood Agent) is attempting to connect to back-up Web Interface servers to launch the application.

A value of 2 means that the main Web Interface server was unavailable, but the Citrix receiver managed to the launch the application 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 client duration

This measure is relevant when the Citrix receiver is the application launch mechanism. It measures the time needed by this user's sessions to retrieve the list of applications from the Web Interface service.

Secs

If the Start-up client 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 the Configuration file download client duration, Credentials obtention client duration, ICA file download duration, Launch page web server duration, Name resolution client duration, Name resolution web server duration, Session look-up client duration, Session creation client duration, and Ticket response 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 an ICA session with the VDI server.

Configuration file download client duration

This measure is relevant when the Citrix receiver is the application launch mechanism. It measures the time this user's sessions took to retrieve the configuration file from the XML server.

Secs

If the Start-up client 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 client duration, Credentials obtention client duration, ICA file download duration, Launch page web server duration, Name resolution client duration, Name resolution web server duration, Session look-up client duration, Session creation client duration, and Ticket response 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 VDI server.

Credentials obtention client duration

This measure is relevant when the Citrix receiver is the application launch mechanism. It measures the time required by this user's sessions to obtain the user credentials.

Secs

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 measure.

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 receiver or Web Interface is the application 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 VDI server 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 plugin (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 application launch mechanism. It measures the time needed by this user's sessions 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, such as the VDI server. Check to see if the network connection between Web Interface and VDI is slow or some VDI servers are down or overloaded. If the Web server seems okay, consider reviewing the VDI farm for problems.

Name resolution client 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 (for example, when using the citrix receiver or a Custom ICA Connection). 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 receiver or Web Interface is the application launch mechanism. It is the time it takes the XML service to resolve the name of a published application to a VDI Server address

Secs

When this metric is high, there could be an issue with the Web Interface server or the Citrix receiver site (formerly known as the Neighborhood Agent site), 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 published application to a VDI 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 receiver (previously known as Program Neighborhood Agent) or from a user clicking a Web Interface page icon. This metric applies to all sessions launched through the Web Interface or the Citrix receiver (formerly, the Program Neighborhood Agent).

Session look-up client duration

Indicates the time this user's sessions take to query every ICA session to host the requested published application.

Secs

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 client duration

Indicates the new session creation time, from the moment wfica32.exe is launched to the establishment of the connection.

Secs

In the event of slowness, if the Start-up client 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 receiver or Web Interface is the application 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 client duration

This measure is relevant when the Citrix receiver is the application 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 receiver or Web Interface is the application 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.

Session start-up server duration

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

Secs

In the event of an application starting in a shared session, this metric is normally much smaller than when starting a completely new session, which involves potentially high- cost tasks such as profile loading and login script execution.

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, Credentials obtention server duration, Program neighborhood credentials obtention server duration, Credentials obtention network server duration, Credentials authentication server duration, Profile load server duration, Login script execution server duration, Drive mapping server duration, and Printer creation server duration.

Session creation server duration

Indicates the time spent by the server 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’.

Credentials obtention server duration

Indicates the time taken by the server 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 Credentials obtention 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.

Credentials obtention network server duration

Indicates the time spent by the server 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 neighborhood credentials obtention server duration

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).

Secs

As in the case of the Credentials obtention 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 Credentials obtention server duration.

Credentials authentication server duration

Indicates the time spent by the server 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, Credentials obtention server duration, Program neighborhood credentials obtention server duration, Credentials obtention network server duration, Profile load server duration, Login script execution server duration, Drive mapping server duration, and Printer creation server duration - to know what is the root-cause of delays in server start-up.

Profile load server duration

Indicates the time required by the server 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.

Login script execution server duration

Indicates the time needed by the server 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.

Drive mapping server duration

Indicates the time needed for the server 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.

Printer creation server duration

Indicates the time required for the server 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, VDI 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.