Configure session prelaunch and session linger – Citrix Website/Blogs/Citrix TV

Citrix 7.6 configuration for session prelaunch and linger

Source Citrix Blogs by By

XenApp and XenDesktop 7.6 session lingering explained

Session lingering is an complementary option to session prelanuch and in most XenApp implementations both these option will be used together to provide the best user experience and to make access to published resources fast and easy. Session lingering similar to session prelaunch was reintroduced in XenApp and XenDesktop 7.6

Introduction 

It may happen, that users by mistake close a published application and when they restart the same application, there might be a delay in the display of the application because the session creation and connection takes time. Session lingering prevents a session from being closed as soon as the user ends the last published application in a session. Instead of logging off, the session is silently retained to provide very short reaction time for future access to published applications.
The readiness time can be of course configured, configuration process will be described in the How to configure section below.

Key considerations:

The following conditions must be considered when session lingering is going to be used:

  • Session lingering is configured per Delivery Group
  • The Delivery Group must support applications. If you configure delivery group to deliver only desktops, prelaunch and linger screens will not be available in Edit Delivery Group wizard.
  • Session lingering is available only for the machines must be running a VDA for Server OS, minimum version 7.6.
Note: Please see section Licensing and resource implications in my previous post: XenApp and XenDesktop 7.6 session prelaunch explained.

How to configure ?

To be able to utilize session lingering the following configuration task must be completed:

  1. Configure StoreFront 2.6 for Pass Through Authentication – to configure StoreFront for pass-through authentication follow the steps below:
    1. Open Citrix StoreFront console
    2. In the left pane select Authentication
    3. In the right pane  (Action pane) click Add/Remove Method
    4. Select Domain pass-through and Accept settings
    5. Verify domain pass-through is added and enabled if as it is shown in Figure 1prel_1
  2. Enable and configure Session Lingering on XenDesktop 7.6 delivery group – to enable session lingering follow the steps below:
    1. Open Citrix Studio
    2. In the left pane select Delivery Groups
    3. In the middle pane select the delivery group you want to modify
    4. In the right  pane  (Action pane) click Edit Delivery Group
    5. On the left side select Application Lingering and configure required settings.
    6. You can configure 2 behaviors:
      1. If lingering session will be created – by default lingering is disabled.
      2. How long lingering session remain active – there are two methods to specify how long an unused session remains active when the user does not start an application: a configured timeout and server load thresholds. You can configure all of them; the event that occurs first will cause the unused session to end.

Timeout – you can configure the time interval 1-99 days, 1-2376 hours, or 1-142,560 minutes.

Thresholds – you can configure two thresholds: the average load on all machines in the Delivery Group exceeds a specified percentage (1-99%) and the load on any machine in the Delivery Group exceeds a specified percentage (1-99%). When a threshold is exceeded, the sessions that have been in lingering state for the longest time are ended, sessions are ended one-by-one at minute intervals until the load falls below the threshold. (While the threshold is exceeded, no new lingering sessions are started.)

Note: In Citrix Studio you can setup only termination timeout. Time before disconnection (disconnection timeout) can be changed using powershell cmdlet.

The example is shown in Figure 2 below sling_2

How to verify if session lingering is working  ?

In order to verify if session lingering is configured you can do either:

  • select the delivery group in Citrix Studio. The result is shown in the Figure 4.sling_5
  • run powershell cmdlet Get-BrokerSessionLinger. The result is shown in the Figure 5  sling_3
  • run powershell cmdlet Get-BrokerSession. The result is shown in the Figure 5  sling_4

Session prelaunch is one of the set of features created to provide a better user experience working on XenApp and XenDesktop products. XenDesktop session prelaunch was reintroduced in version 7.6 – originally session prelaunch was available in XenApp 6.5 but was removed from the first version of XenDesktop 7.

Introduction 

The session prelaunch help all or specified users access applications quickly, by starting sessions before they are requested. By default session prelaunch is turned off and must be configured manually. In the default configuration each session starts (launches) when a user starts an application, and remains active until the last open application in the session closes. When this option is configured a session is waiting for a user and when the user starts an application prelaunched session is replaced with a regular session. If the user does not start an application (the prelaunched session is unused). We can configure the time when prelaunch session is created and for how long that session remains active. The configuration details are shown in section How to configure ? below.

Key considerations:

The following conditions must be considered when session prelaunch is going to be used:

  • Session prelaunch is configured per Delivery Group
  • The Delivery Group must support applications. If you configure delivery group to deliver only desktops, prelaunch and linger screens will not be available in Edit Delivery Group wizard.
  • Session prelaunch is available only for the machines must be running a VDA for Server OS, minimum version 7.6.
  • Session prelaunch  is supported only when using Citrix Receiver for Windows. In Citrix Receiver 4.2 when you install the Single Sign-on (SSON) component, session prelaunch enabled by default.
  • When using session prelaunch:
    • Physical client machines cannot use the suspend or hibernate power management functions.
    • Client machine users can lock their sessions but should not log off.

Licensing and resource implications

Prelaunched sessions consume a license, but only when connected. Unused prelaunched sessions disconnect after 15 minutes by default. This value can be configured in PowerShell (New/Set-BrokerSessionPreLaunch cmdlet). Optimal configuration balances the benefits of earlier application availability for users against the cost of keeping licenses in use and resources allocated.

Important note: You should carefully verify your licensing model before you enable session prelaunch for all users. This option is fine when you use 1:1 concurrent license or per user/desktop license. If you configure session prelaunch for all users and you have less licenses than total number of workstations you will hit your license limit just in first few minutes in the morning when users will logon to the network (prelaunch session will be created in the background for all users with citrix receiver installed on their computer even though they may not use a XenApp app at all.
If you have other than 1:1 license ratio you can consider to enable session prelaunch only for specified Active Directory groups. You can also try to fix possible problems using short prelaunch timeout – for not used prelaunched sessions or linger timeout to disconnect disconnected sessions but this could be only a workaround.

How to configure ?

To be able to utilize session prelaunch the following configuration task must be completed:

Server side actions:

  1. Configure StoreFront 2.6 for Pass Through Authentication – to configure StoreFront for pass-through authentication follow the steps below:
    1. Open Citrix StoreFront console
    2. In the left pane select Authentication
    3. In the right pane  (Action pane) click Add/Remove Method
    4. Select Domain pass-through and Accept settings
    5. Verify domain pass-through is added and enabled if as it is shown in Figure 1prel_1
  2. Enable and configure Session Prelaunch on XenDesktop 7.6 delivery group – to enable session prelaunch follow the steps below:
    • Open Citrix Studio
    • In the left pane select Delivery Groups
    • In the middle pane select the delivery group you want to modify
    • In the right  pane  (Action pane) click Edit Delivery Group
    • On the left side select Application Prelaunch and configure required settings. You can configure 2 behaviors:
      1. When prelaunch session will be created – Launch when user start an appliaction (no prelaunch) is default selection
      2. How long unused prelaunched sessions remain active – there are two methods to specify how long an unused session remains active when the user does not start an application: a configured timeout and server load thresholds. You can configure all of them; the event that occurs first will cause the unused session to end.

Timeout – a configured timeout specifies the number of minutes, hours, or days an unused prelaunched session remains active. If you configure too short a timeout, prelaunched sessions will end before they provide the user benefit of quicker application access. If you configure too long a timeout, incoming user connections might be denied because the server doesn’t have enough resources.You cannot disable this timeout from Studio, but you can in the SDK (New/Set-BrokerSessionPreLaunch cmdlet). If you disable the timeout, it will not appear in the Studio display for that Delivery Group or in the Edit Delivery Group wizard.

Thresholds – automatically ending prelaunched sessions based on server load ensures that sessions remain open as long as possible, assuming server resources are available. Unused prelaunched sessions will not cause denied connections because they will be ended automatically when resources are needed for new user sessions.You can configure two thresholds: the average percentage load of all servers in the Delivery Group, and the maximum percentage load of a single server in the Delivery Group. When a threshold is exceeded, the sessions that have been in the prelaunch or lingering state for the longest time are ended, sessions are ended one-by-one at minute intervals until the load falls below the threshold. (While the threshold is exceeded, no new prelaunch sessions are started.)

The example is shown in Figure 2 below

prel_2

  1. Configure pass-through settings on client device  – in most cases this will be done via Group Policy. To configure this follow the steps below:
    1. Open Group Policy Editor
    2. Create a new group policy and switch to edit mode
    3. Browse to Computer Configuration -> Administrative Templates
    4. Right click and select Add/Remove templates
    5. Add dd the icaclient.adm this is located in the install location of Receiver “C:Program FilesCitrixICA ClientConfiguration”.
    6. Browse to Computer Configuration -> Administrative Templates -> Classic Administrative Templates -> User Authentication -> Local Username and Password
    7. Enable Local user name and password and configure it as it is shown in the Figure 3 below
    8. Link created group policy object to OU with client computersprelunch_5

Client side actions:

  1. Install citrix receiver with Single Sign on – from the command line use Citrix Receiver with the /includeSSON flag.
  2. Verify if the following registry key is enabled and set to true: HKLMSoftwareCitrixDazzleEnablePreLaunch. Based on the citrix blog article, starting from Citrix Receiver 4.2 session prelaunch should be enabled by default. If not enabled, use GPO or other method to enable and configure this registry setting.
  3. Restart client computer

How to verify if session prelaunch is working  ?

In order to verify if session prelaunch is configured select the delivery group in Citrix Studio. The result is shown in the figure 4.

prel_4

To display all session lingering settings powershell cmdlet Get-BrokerSessionPreLaunch can be used. The result is displayed in Figure 5.

prel_7

In order to verify if session prelaunch is realy working is to use powershell cmdlet to display all sessions. Use powershell cmdlet get-brokersession to display all sessions with all details as it is shown in Figure 6. Not easy to read for 100 and more sessions :)

prel_5

I would prefer to add some additional parameters to make the result more readable. Use the following command to display session information in more friendly layout:

Get-BrokerSession -SessionType Application -Property AppState, SessionState, Uid, UserName, ApplicationsInUse, DnsName, ReceiverName |Format-Table

The result is shown in Figure 7

prel_6

Source: Citrix Website

The session prelaunch and session linger features help specified users access applications quickly, by starting sessions before they are requested (session prelaunch) and keeping application sessions active after a user closes all applications (session linger).

By default, session prelaunch and session linger are not used: a session starts (launches) when a user starts an application, and remains active until the last open application in the session closes.

Considerations:

  • The Delivery Group must support applications, and the machines must be running a VDA for Server OS, minimum version 7.6.
  • These features are supported only when using Citrix Receiver for Windows, and also require additional Receiver configuration. For instructions, search for “session prelaunch” in the eDocs content for your Receiver for Windows version.
  • When using session prelaunch:
    • Physical client machines cannot use the suspend or hibernate power management functions.
    • Client machine users can lock their sessions but should not log off.
  • Prelaunched and lingering sessions consume a license, but only when connected. Unused prelaunched and lingering sessions disconnect after 15 minutes by default. This value can be configured in PowerShell (New/Set-BrokerSessionPreLaunch cmdlet).
  • Careful planning and monitoring of your users’ activity patterns are essential to tailoring these features to complement each other. Optimal configuration balances the benefits of earlier application availability for users against the cost of keeping licenses in use and resources allocated.
  • You can also configure session prelaunch for a scheduled time of day in Receiver.

To enable session prelaunch:

  1. Select Delivery Groups in the Studio navigation pane.
  2. Select a Delivery Group, and then click Edit Delivery Group in the Actions pane.
  3. On the Application Prelaunch page, enable session prelaunch by choosing when sessions should launch:
    • When a user starts an application. This is the default setting; session prelaunch is disabled.
    • When any user in the Delivery Group logs on to Receiver for Windows.
    • When anyone in a list of users and user groups logs on to Receiver for Windows. Be sure to also specify users or user groups if you choose this option.
  4. A prelaunched session is replaced with a regular session when the user starts an application. If the user does not start an application (the prelaunched session is unused), the following settings affect how long that session remains active. For details about these settings, see How long unused prelaunched and lingering sessions remain active below.
    • When a specified time interval elapses. You can change the time interval (1-99 days, 1-2376 hours, or 1-142,560 minutes).
    • When the average load on all machines in the Delivery Group exceeds a specified percentage (1-99%).
    • When the load on any machine in the Delivery Group exceeds a specified percentage (1-99%).

    Recap: A prelaunched session remains active until one of the following events occurs: a user starts an application, the specified time elapses, or a specified load threshold is exceeded.

To enable session linger:

  1. Select Delivery Groups in the Studio navigation pane.
  2. Select a Delivery Group, and then click Edit Delivery Group in the Actions pane.
  3. On the Application Lingering page, enable session linger by selecting the Keep sessions active until radio button.
  4. Several settings affect how long a lingering session remains active if the user does not start another application. For details about these settings, see How long prelaunched and lingering sessions remain active below.
    • When a specified time interval elapses. You can change the time interval (1-99 days, 1-2376 hours, or 1-142,560 minutes).
    • When the average load on all machines in the Delivery Group exceeds a specified percentage (1-99%).
    • When the load on any machine in the Delivery Group exceeds a specified percentage (1-99%).

    Recap: A lingering session remains active until one of the following events occurs: a user starts an application, the specified time elapses, or a specified load threshold is exceeded.

How long unused prelaunched and lingering sessions remain active – There are several ways to specify how long an unused session remains active if the user does not start an application: a configured timeout and server load thresholds. You can configure all of them; the event that occurs first will cause the unused session to end.

  • Timeout – A configured timeout specifies the number of minutes, hours, or days an unused prelaunched or lingering session remains active. If you configure too short a timeout, prelaunched sessions will end before they provide the user benefit of quicker application access. If you configure too long a timeout, incoming user connections might be denied because the server doesn’t have enough resources.

    You cannot disable this timeout from Studio, but you can in the SDK (New/Set-BrokerSessionPreLaunch cmdlet). If you disable the timeout, it will not appear in the Studio display for that Delivery Group or in the Edit Delivery Group wizard.

  • Thresholds – Automatically ending prelaunched and lingering sessions based on server load ensures that sessions remain open as long as possible, assuming server resources are available. Unused prelaunched and lingering sessions will not cause denied connections because they will be ended automatically when resources are needed for new user sessions.

    You can configure two thresholds: the average percentage load of all servers in the Delivery Group, and the maximum percentage load of a single server in the Delivery Group. When a threshold is exceeded, the sessions that have been in the prelaunch or lingering state for the longest time are ended, sessions are ended one-by-one at minute intervals until the load falls below the threshold. (While the threshold is exceeded, no new prelaunch sessions are started.)

Servers with VDAs that have not registered with the Controller, and servers in maintenance mode are considered fully loaded. An unplanned outage will cause prelaunch and lingering sessions to be ended automatically to free capacity.

What’s new for XenApp and XenDesktop with UPS 7.6!

Source: Citrix Blog

Citrix XenDesktop 7.6 included the release of a new version of the Citrix Universal Print Server, UPS 7.6; with this release our test results showed very significant improvements in the software, including:

  • Stability at a sustained load of about 50 print jobs per minute
  • Excellent recovery from periods of stress/overload
  • Protocol efficiency optimizations (reduced chattiness) resulting in a better user experience (opening the Print dialog is about 6 times faster) and better performance over WAN connections
  • Increased protection from faulty printer drivers, including when UPS is used in conjunction with printer driver isolation

Better Documentation

To accompany this release of UPS we have also improved the documentation available in the Citrix XenDesktop Handbook, with a new revised section on printing from our consultancy teams based on their field experience. Although in the XenDesktop” Handbook this advice is also relevant to those using UPS for XenApp Printing. I’d recommend reading Ed Duncan’s great blog overviewing the solutions available, here, for great insight into what UPS can do and a guide to the documentation available.

Citrix does printing solutions?

Yes, and now very well! Citrix spent many years developing enterprise printing technologies; whilst delivering cloud SaaS is becoming common, most businesses still need basic, core functionality. Hotfix UPS 7.1.100 (Q1 2014) addressed a number of stability and scalability issues:

UPS 7.6 has continued this drive for quality and we recommend those using UPS 7.1.100 also upgrade to UPS 7.6 for further enhancements.

Printing files can inflate and place a very high load on bandwidth. Transferring our expertise in compression techniques from our other products and HDX has resulted in some nice compression technology between the client and the UPS, which mean that this is genuinely a WAN suitable solution.

The Future

UPS 7.6 has been about reworking the core architectures for robustness and scale to ensure the platform is future-proof. This will provide the platform ongoing on which we can provide newer features and support for newer versions of Windows Server.  We have spent a lot of this development cycle changing our development tools, automating testing and stress testing.  I’ve blogged about why I’m particularly excited to be the Product Manager for this product.

One of our key focuses has been ensuring printer driver faults can be identified by our own test tools. Printer drivers can be wrapped in pretty strange ways and protecting our infrastructure from leaking and faulty drivers has been a key focus. I’m hoping we’ll be in a position to open our in-house tools to our partner vendors and also customers so they can also identify and isolate faulty drivers easily in the future.

I’m also currently planning our roadmap for new server OS support and new printing features.

Is UPS expensive to get?

It’s free! Citrix is the only virtualisation vendor to provide such a comprehensive solution and as part of our core product. So no dealing with third-party support nor any additional licensing costs! We’ve been analyzing the strengths of the technologies and Mayank provides an excellent overview, here, where you can get ideas on how to assess and compare printing solutions, quality, bandwidth and capacity planning.

Are these improvements available for XenDesktop 5.6, 7.x and XenApp 6.5 Users?

Yes they are! The new components of the UPS 7.6 are currently included in the main XenDesktop/XenApp 7.6 download. With hindsight this is not the most convenient place for XenApp customers to look for new components (UPSClient and UPD) and the need to download the entire download is simply inconvenient. We are working to repackage those components in a more convenient format in the future.

Update (27/Nov/2014): The components are now available for independent download (login to downloads with Citrite ID):

XenApp 6.5 Upgrade Details

There is a caveat for installation on XenApp 6.5 owing to a driver versioning mismatch associated with HRP004 (HotFix RollUp Pack 4 detailed in CTX138366). We are revising our processes to ensure such a mismatch does not occur in the future. And we aim to resolve this with a later HRP (so if you are reading this when HRP005 or higher is available, this information is not relevant and should not be applied to any HRP other than 004 without explicit advice from Citrix to do so).

  • The recommended order of installation is: HRP004 first, followed by UPS 7.6
  • The driver versioning mismatch will result in a dialogue box asking if you wish to install an older driver version when you install UPS7.6, which you should agree to do
  • The dialogue box will interrupt automatic install
  • We are working on a KB article detailing a WA for those users for whom unattended/scripted install is required (if your need is pressing please do contact Citrix Support). Update (3rd Nov 2014): A tool to avoid this issue is now available, see http://support.citrix.com/article/CTX200268

HTML5 and Chrome Receiver Printing!

We are aiming to continue to have the broadest range of printing options available for our XenDesktop and XenApp users allowing them to use the widest range of end-points and to allow people to work where they want and how. Aligned to the XenDesktop 7.6 release, we also released new receivers for HTML5 and Chrome that support local pdf. This is a smart feature whereby if you open a word document on your client, you can choose to print to our new Citrix PDF driver, this then sends the document up to the server and the PDF is sent back to your end-point over ICA and opened on your PDF viewer of choice e.g. CutePDF from where you can print to your printers of choice. It’s a really flexible generic solution which avoids the need to install and maintain local drivers on end-clients. You can read about the HTML5 receiver printing functionality, here, and about the Chrome receiver and its support for the Google Print Cloud, here. Thomas Berger covers some of the security and usability benefits associated with these printing solutions, relative to competitive solutions, in this great overview.

Other Information

  • Citrix Printing Solutions for XenApp and XenDesktop, a review by West Monroe Partners, a Citrix partner enjoy customer success with UPS
  • Details of Canon’s investment in drivers optimised for Citrix printing, here
  • Marek Dressler’s printing focused blog series from Citrix Support, a great place to keep up to date with the latest information, here
  • Independent Consultant Dave Bretty’s blog on how UPS has simplified and resolved driver management for XenApp customers is a nice read, here
  • CTX136332, advice on printer driver isolation
MyXenApp

A blog dedicated to Citrix technology

There's More to the Story: a blog about LIFE, chronic illness, and Mental Health

I’m the loud and relentless "patient" voice and advocate they warned you about. I happen to have type 1 diabetes, ADHD, anxiety, OCD, PCOS, endometriosis, thyroid issues, asthma, allergies, lactose intolerance (and more), but there’s more to story.

DeployWindows

Learn Troubleshoot and Manage Windows

Dirk & Brad's Windows Blog

Microsoft Platform How To's, Best Practices, and other Shenanigans from Highly-qualified Windows Dorks.

Ingmar Verheij

About Citrix, Remote Desktop, Performance, Workspace, Monitoring and more...

Virtual to the Core

Virtualization blog, the Italian way.

CloudPundit: Massive-Scale Computing

the business of Internet infrastructure, cloud computing, and data centers

UCSguru.com

Every Cloud Has a Tin Lining.

speakvirtual

See no physical, hear no physical, speak no physical - speakvirtual.com

IT BLOOD PRESSURE

IT can be easy

Ask the Architect

My workspace journey

blog.scottlowe.org

The weblog of an IT pro specializing in virtualization, storage, and servers

akosijesyang

a place under control of his big head

this is... The Neighborhood

the Story within the Story

Yellow Bricks

by Duncan Epping

THE SAN GUY

Enterprise Storage Engineer

My Virtual Vision

My thoughts on application delivery