(For more resources related to this topic, see here.)

Optimizing Session Startup

The most frequent complaint that system administrators receive from users about XenApp is definitely that the applications start slowly. They certainly do not consider that at least the first time you launch an application published by XenApp, an entire login process takes place.

In this article you’ll learn:

• Which steps form the login process and which systems are involved
• The most common causes of logon delays and how to mitigate them
• The use of some advanced XenApp features, like session pre-launch

The logon process

Let’s briefly review the logon process that starts when a user launches an application through the Web Interface or through a link created by the Receiver. The following diagram explains the logon process:

The logon process

Resolution

The user launches an application (A) and the Web Interface queries the Data Collector (B) that returns the least-loaded server for the requested application (C). The Web Interface generates an ICA file and passes it to the client (D).

Connection

The Citrix client running on the user’s PC establishes a connection to the session-host server specified in the ICA file. In the handshake process, client and server agree on the security level and capabilities.

Remote Desktop Services (RDS) license

Windows Server validates that an RDS/Terminal Server (TS) license is available.

AD authentication

Windows Server authenticates the user against the Active Directory (AD). If the authentication is successful, the server queries account details from the AD, including Group Policies (GPOs) and roaming profiles.

Citrix license

XenApp validates that a Citrix license is available.

Session startup

If the user has a roaming profile, Windows downloads it from the specified location (usually a file server). Windows then applies any GPOs and XenApp applies any Citrix policies. Windows executes applications included in the Startup menu and finally launches the requested application.

Some other steps may be necessary if other Citrix components (for example, the Citrix Access Gateway) are included in your infrastructure.

Analysing the logon process

Users perceive the overall duration of the process from the time when they click on the icon until the appearance of the application on their desktops. To troubleshoot slowness, a system administrator must know the duration of the individual steps.

Citrix EdgeSight

Citrix EdgeSight is a performance and availability management solution for XenApp and XenDesktop. If you own an Enterprise or Platinum XenApp license, you’re entitled to install EdgeSight Basic (for Enterprise licensing) or Advanced (for Platinum licensing). You can also license it as a standalone product.

If you deployed Citrix EdgeSight in your farm, you can run the Session Startup Duration Detail report, which includes information on both, the duration of server-side and client-side steps. This report is available only with EdgeSight Advanced.

For each session, you can drill down the report to display information about server-side and client-side startup processes. An example is shown in the following screenshot:

EdgeSight’s Session Startup Duration Detail report

The columns report the time (in milliseconds) spent by the startup process in the different steps. SSD is the total server-side time, while CSD the total client-side time. You can find a full description of the available reports and the meaning of the different acronyms in the EdgeSight Report List at http://community.citrix.com/display/edgesight/EdgeSight+5.4+Report+List. In the preceding example most of the time was spent in the Profile Load (PLSD) and Login Script Execution (LSESD) steps on the server and in the Session Creation (SCCD) step on the client.

EdgeSight is a very valuable tool to analyze your farm. The available reports cover all the critical areas and gives detailed information about the “hidden” work of Citrix XenApp.

With the Session Startup Duration Detail report you can identify which steps cause a slow session startup. If you want to understand why server-side steps, like the Profile Load step in the preceding example that lasted more than 15 seconds, take too much time, you need a different tool.

Windows Performance Toolkit

Windows Performance Toolkit (WPT) is a tool included in the Windows ADK, freely downloadable from the Microsoft website (http://www.microsoft.com/en-us/download/details.aspx?id=30652).

You need an Internet connection to install Windows ADK. You can run the setup on a client with Internet access and configure it to download all the required components in a folder. Move the folder on your server and perform an offline installation.

WPT has two components:

• Windows Performance Recorder, which is used to record all the performance data in an .etl file
• Windows Performance Analyzer, a graphical program to analyze the recorded data

Run the following command from the WPT installed folder to capture slow logons:

C:WPT>xperf -on base+latency+dispatcher+NetworkTrace+Registry+File
IO -stackWalk CSwitch+ReadyThread+ThreadCreate+Profile -BufferSize 128 
-start UserTrace -on "Microsoft-Windows-Shell-Core+Microsoft-Windows-
Wininit+Microsoft-Windows-Folder Redirection+Microsoft-Windows-User 
Profiles Service+Microsoft-Windows-GroupPolicy+Microsoft-Windows-Winlogon
+Microsoft-Windows-Security-Kerberos+Microsoft-Windows-User 
Profiles General+e5ba83f6-07d0-46b1-8bc7-7e669a1d31dc+63b530f8-29c9-4880
-a5b4-b8179096e7b8+2f07e2ee-15db-40f1-90ef-9d7ba282188a" -BufferSize 1024 
-MinBuffers 64 -MaxBuffers 128 -MaxFile 1024

After having recorded at least one slow logon, run the following command to stop recording and save the performance data to an .etl file:

C:WPT>xperf -stop -stop UserTrace -d merged.etl

This command creates a file called merged.etl in the WPT install folder. You can open this file with Windows Performance Analyzer. The Windows Performance Analyzer timeline is shown in the following screenshot:

Windows Performance Analyzer timeline

Windows Performance Analyzer shows a timeline with the duration of each step; for any point in time you can view the running processes, the usage of CPU and memory, the number of I/O operations, and the bytes sent or received through the network.

WPT is a great tool to identify the reason for delays in Windows; it, however, has no visibility of Citrix processes. This is why EdgeSight is still necessary for complete troubleshooting.

Common causes of logon delays

After having analyzed many logon problems, I found that the slowness was usually caused by one or more of the following reasons:

• Authentication issues
• Profile issues
• GPO and logon script issues

In the next paragraphs, you’ll learn how to identify those issues and how to mitigate them. Even if you can’t use the advanced tools (EdgeSight, WPT, and so on) described in the preceding sections, you can follow the guidelines in the next sections and best practices to solve or prevent most of the problems related to the logon process.

Authentication issues

During the logon process, authentication happens at multiple stages; at minimum when a user logs on to the Web Interface and when the session-host server creates a session for launching the requested application. Citrix XenApp integrates with Active Directory. The authentication is therefore performed by a Domain Controller (DC) server of your domain.

Slowness in the Domain Controller response, caused by an overloaded server, can slow down the entire process. Worse, if the Domain Controller is unavailable, a domain member server may try to connect for 30 seconds before timing out and choosing a different DC.

Domain member servers choose the Domain Controller for authenticating users based on their membership to Active Directory Sites. If sites are not correctly configured or don’t reflect the real topology of your network, a domain member server may decide to use a remote Domain Controller, through a slow WAN link, instead of using a Domain Controller on the same LAN.

Profile issues

Each user has a profile that is a collection of personal files and settings. Windows offers different types of profiles, with advantages and disadvantages as shown in the following table:

Type	Description
Local	The profile folder is local to each server.
Roaming	The profile folder is saved on a central storage (usually a file server).
Mandatory	A read-only profile is assigned to users; changes are not saved across sessions.

From the administrator’s point of view, mandatory profiles are the best option because they are simple to maintain, allow fast logon, and users can’t modify Windows or application settings. This option however is not often feasible. I could use mandatory profiles only in specific cases, for example; when users have to run only a single application without the need to customize it.

Local profiles are almost never used in a XenApp environment because even if they offer the fastest logon time, they are not consistent across servers and sessions. Furthermore, you’ll end up with all your session-host servers storing local profiles for all your users, and that is a waste of disk space. Finally, if you’re provisioning your servers with Provisioning Server, this option, if not applicable as local profiles. would be saved in the local cache, which is deleted every time the server reboots.

System administrators usually choose roaming profiles for their users. Roaming profiles indeed allow consistency across servers and sessions and preserve user.

Roaming profiles are, however, the most significant cause of slow logons. Without a continuous control, they can rapidly grow to a large size. A small profile with a large number of files, for example, a profile with many cookies, can cause delays too.

Roaming profiles also suffer of the last write wins problem. In a distributed environment like a XenApp farm, it is not unlikely that users are connected to different servers at the same time. Profiles are updated when users log off, so with different sessions on different servers, some settings could be overwritten, or worse, the profile could be corrupted.

Folder redirection

To reduce the size of roaming profiles, you can redirect most of the user folders to a different location. Instead of saving files in the user’s profile, you can configure Windows to save them on a file sharing system.

The advantages of using folder redirection are:

• The data in the redirected folders is not included in the synchronization job of the roaming profile, making the user logon and logoff processes faster
• Using disk quotas and redirecting folders to different disks, you can limit how much space is taken up by single folders instead of the whole profile
• Windows Offline Files technology allows users to access their files even when no network connection is available
• You can redirect some folders (for example, the Start Menu) to a read-only share, giving all your users the same content

Folder redirection is configured through group policies as shown in the following screenshot:

Configuring Folder Redirection

For each folder, you can choose to redirect it to a fixed location (useful if you want to provide the same content to all your users), to a subfolder (named as the username) under a fixed root path to the user’s home directory, or to the local user profile location.

You may also apply different redirections based on group membership and define advanced settings for the Documents folder.

In my experience, folder redirection plays a key role in speeding up the logon process. You should enable it at least for the Desktop and My Documents folder if you’re using roaming profiles.

Background upload

With Windows 2008 R2, Microsoft added the ability to perform periodic upload of the user’s profile registry file (NTUSER.DAT) on the file share. Even if this option wasn’t added to address the last write wins problem, it may help to avoid profile corruption and Microsoft recommends enabling it through a GPO as shown in the following screenshot:

Enabling Background upload

Citrix Profile Management

Citrix developed its own solution for managing profiles, Citrix Profile Management.

You’re entitled to use Citrix Profile Management if you have an active Subscription Advantage for the following products:

• XenApp Enterprise and Platinum edition
• XenDesktop Advanced, Enterprise, and Platinum edition

You need to install the software on each computer whose user profiles you want to manage. In a XenApp farm install it on your session-host servers.

Features

Citrix Profile Management was designed specifically to solve some of the problems Windows roaming profiles introduced. Its main features are:

• Support for multiple sessions, without the last write wins problem
• Ability to manage large profiles, without the need to perform a full sync when the user logs on
• Support for v1 (Windows XP/2003) and v2 (Windows Vista/Seven/2008) profiles
• Ability to define inclusion/exclusion lists
• Extended synchronization can include files and folders external to the profile to support legacy applications

Configuring

Citrix Profile Management is configured using Windows Group Policy.

In the Profile Management package, downloadable from the Citrix website, you can find the administrative template (.admx) and its language file (.adml). Copy the ADMX file in C:WindowsPolicyDefintions and the ADML file in C:WindowsPolicyDefintionslang (for example, on English operating systems the lang folder is en-US).

A new Profile Management folder in Citrix is then available in your GPOs as shown in the following screenshot:

Profile Management’s settings in Windows GPOs

Profile Management settings are in the Computer section, therefore, link the GPO to the Organizational Unit (OU) that contains your session-host servers.

Profiles priority order

If you deployed Citrix Profile Management, it takes precedence over any other profile assignment method. The priority order on a XenApp server is the following:

• Citrix Profile Management
• Remote Desktop Services profile assigned by a GPO
• Remote Desktop Services profile assigned by a user property
• Roaming profile assigned by a GPO
• Roaming profile assigned by a user property

Troubleshooting

Citrix Profile Management includes a logging functionality, you can enable via GPO as shown in the following screenshot:

Enabling the logging functionality

With the Log settings setting, you can also enable verbose logging for specific events or actions.

Logs are usually saved in %SystemRoot%System32LogfilesUserProfileManager but you can change the path with the Path to log file property.

Profile Management’s logs are also useful to troubleshoot slow logons. Each step is logged with a timestamp so analyzing those logs you can find which steps last for a long time.

GPO and logon script issues

In a Windows environment, it’s common to apply settings and customizations via Group Policy Objects (GPOs) or using logon scripts.

Numerous GPOs and long-running scripts can significantly impact the speed of the logon process. It’s sometimes hard to find which GPOs or scripts are causing delays. A suggestion is to move the XenApp server or a test user account in a new Organizational Unit, with no policies applied and blocked inheritance. Comparing the logon time in this scenario with the normal logon time can help you understand how GPOs and scripts affect the logon process.

The following are some of the best practices when working with GPOs and logon scripts:

• Reduce the number of GPOs by merging them when possible. The time Windows takes to apply 10 GPOs is much more than the time to apply a single GPO including all their settings.
• Disable unused GPOs sections. It’s common to have GPOs with only computer or user settings. Explicitly disabling the unused sections can speed up the time required to apply the GPOs.
• Use GPOs instead of logon scripts. Windows 2008 introduced Group Policy Preferences, which can be used to perform common tasks (map network drives, change registry keys, and so on) previously performed by logon scripts. The following screenshot displays configuring drive maps through GPOs.



Configuring drive maps through GPO

Session pre-launch, sharing, and lingering

Setting up a session is the most time-consuming task Citrix and Windows have to perform when a user requests an application. In the latest version of XenApp, Citrix added some features to anticipate the session setup (pre-launch) and to improve the sharing of the same session between different applications (lingering).

Session pre-launch

Session pre-launch is a new feature of XenApp 6.5. Instead of waiting for the user to launch an application, you can configure XenApp to set up a session as soon as the user logs on to the farm.

At the moment, session pre-launch works only if the user logs on using the Receiver, not through the Web Interface.

This means that when the user requests an application, a session is already loaded and all the steps of the logon process you’ve learned have already taken place. The application can start without any delay. From my experience, this is a feature much appreciated by users and I use it in the production farms.

Please note that if you enable session pre-launch, a license is consumed at the time the user logs on.

Configuring

A session pre-launch is based on a published application on your farm. A common mistake is thinking that when you configure a pre-launch application, Citrix effectively launches that application when the user logs on. The application is actually used as a template for the session. Citrix uses some of its settings, like users, servers/worker groups, color depth, and so on.

To create a pre-launch session, right-click on the application and choose Other Tasks | Create pre-launch application as shown in the following screenshot:

Creating pre-launch application

To avoid confusion, I suggest renaming the configured pre-launch session removing the actual application name, for example, you can name it Pre-launch WGProd.

A pre-launched session can be used to run applications that have the same settings of the application you chose when you created the session. For example, it can be used by applications that run on the same servers. If you published different groups of applications, usually assigned to different worker groups, you should create pre-launch sessions choosing one application for each group to be sure that all your users’ benefit from this feature.

Life cycle of a session

If you configured a pre-launch session, when the Receiver passes the user credentials to the XenApp server a new session is created. The server that will host the session is chosen in the usual way by the Data Collector.

In Citrix AppCenter, you can identify pre-launched sessions from the value in the Application State column as shown in the following screenshot:

Pre-launched session

Using Citrix policies, you can set the maximum time a pre-launch session is kept:

• Pre-launch Disconnect Timer Interval, is the time after which the pre-launch session is put in disconnected state
• Pre-launch Terminate Timer Interval, is the time after which the pre-launch session is terminated

Session sharing

Session sharing occurs when a user has an open session on a server and launches an application that is published on the same server. The launch time for the second application is quicker because Citrix doesn’t need to set up a new session for it.

Session sharing is enabled by default if you publish your applications in seamless window mode. In this mode, applications appear in their own windows without containing an ICA session window. They seem physically installed on the client.

Session sharing fails if applications are published with different settings (for example, color depth, encryption, and so on). Make sure to publish your applications using the same settings if possible.

Session sharing takes precedence over load balancing; the only exception is if the server reports full load.

You can force XenApp to override the load check and to also use fully loaded servers for session sharing. Refer to CTX126839 for the requested registry changes. This is, however, not a recommended configuration; a fully loaded server can lead to poor performance.

Session lingering

If a user closes all the applications running in a session, the session is ended too. Sometimes it would be useful to keep the session open to speed up the start of new applications. With XenApp 6.5 you can configure a lingering time. XenApp waits before closing a session even if all the running applications are closed.

Configuring

With Citrix user policies, you can configure two timers for session lingering:

• Linger Disconnect Timer Interval, is the time after which a session without applications is put in disconnected state
• LingerTerminate Timer Interval, is the time after which a session without applications is terminated

If you’re running an older version of XenApp, you can keep a session open even if users close all the running applications with the KeepMeLoggedIn tool; refer to CTX128579.

Summary

The optimization of the logon process can greatly improve the user experience. With EdgeSight and Windows Performance Toolkit you can perform a deep analysis and detect any causes of delay. If you can’t use those tools, you are still able to implement some guidelines and best practices that will surely make users’ logon faster.

Setting up a session is a time-consuming task. With XenApp 6.5, Citrix implemented some new features to improve session management. With session pre-launch and session lingering you can maximize the reuse of existing sessions when users request an application, speeding up its launch time.

Resources for Article:

---

Further resources on this subject:

• Managing Citrix Policies [Article]
• Getting Started with XenApp 6 [Article]
• Getting Started with the Citrix Access Gateway Product Family [Article]

---