Citrix Session Start-up Details Test

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 Virtual Apps 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.

Compare the value of this measure across users to know which user’s sessions took the longest to start-up. To know what is causing this slowness, 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 session start-up process is spending the maximum time.

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

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

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.

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.

Backup URL count

When any user complains of slowness, you may want to compare the value of this measure with that of the Server side session start-up processing 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 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.

If this metric has a value higher than 1, it indicates that the Web Interface server is unavailable and the Virtual Apps Plugin (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 Virtual Apps Plugin 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.

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 an ICA session with the Virtual Apps server.

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 Virtual Apps server.

Note that this 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.

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 Virtual Apps 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.

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 Virtual Apps server. Check to see if the network connection between Web Interface and Virtual Apps is slow or some Virtual Apps servers are down or overloaded. If the Web server seems okay, consider reviewing the Virtual Apps farm for problems.

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 Virtual Apps Plugin 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.

When this metric is high, there could be an issue with the Web Interface server or the Virtual Apps plugin 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 Virtual Apps 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 Virtual Apps plugin (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 Virtual Apps plugin (formerly, the Program Neighborhood Agent).

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.

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 Server side session start-up processing 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.

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

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.

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.

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

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

Note:

When monitoring Citrix Virtual Apps servers below v7.6, this measure may sometimes report abnormally high values. If you want to disregard such values, then do the following:

• Edit the eg_tests.ini file (in the <EG_INSTALL_DIR>\manager\config directory).
• Look for the CitrixEuemMaxSCSD parameter in the file.
• By default, this parameter is set to 600 (seconds). This means that, if the Session creation server duration measure reports a value that is higher than 600 seconds (by default), then eG Enterprise will hide this measure from the UI. You can change the value of the CitrixEuemMaxSCSD parameter to suit your needs.
• Finally, save the eg_tests.ini file.

When monitoring Citrix Virtual Apps servers above v7.6 however, this test will not report such abnormal values for the Session creation server duration measure. So, the CitrixEuemMaxSCSD parameter is not applicable in this case.

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 Server side session start-up processing 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.

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

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.

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, and Endpoint printers mapping duration – to know what is the root-cause of delays in server start-up.

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.

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.

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.

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, Virtual Apps 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.

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

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.

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

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.

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

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.

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

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.

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.

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.

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

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 identify the Group Policy that is associated with the user, accurately isolate the object file that took the longest to access, and thus delayed the logon process.

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.

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.

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.

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.

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:

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.

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.

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

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:

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.