As Cris mentioned in his blog, the Citrix engineering teams are continuing to add features to XenApp and XenDesktop to provide a better user experience on the new FlexCast Management Architecture (FMA). In this multi-part blog series, we want to share what problems are important to you and how we plan to solve them.

In part 3 of this series, one of the features which we are working on upgrading as our customers transition from IMA-based XenApp releases to FMA is “Fast application access via session pre-launch and lingering.”

This feature creates a local-like feel for published applications by eliminating the slow log-on process at application launch, which can take longer than end users are willing to endure, mostly due to complex enterprise AD environments. Both session pre-launch and lingering work by ensuring the user has a session (either active or disconnected) before application launch.  The application launch simply triggers a reconnect (if disconnected) followed by session sharing.  Both of these operations are quick and appear almost instantaneous to the user, giving them a fast, local-like app launch experience.

Simplifying Session Prelaunch Configuration

We are working on upgrading the session pre-launch feature from XenApp 6.5 with a new and improved admin experience.

In XenApp 6.5, the configuration was spread across Citrix Receiver registry keys, “pre-launch application” objects in AppCenter, and policy settings.  In particular, pre-launch required configuring static timers via policies to disconnect and terminate sessions.

Under the FlexCast Management Architecture, we plan to make pre-launch a Delivery Group property in Citrix Studio to simplify the admin experience and ensure that the only delegated admin permission needed to enable pre-launch is Edit Delivery Group.

We also plan to move the terminate timer to Studio. The disconnect and terminate timers can also be configured using the Broker PowerShell SDK.

Simplifying Session Linger Configuration

Likewise, we are also working on upgrading the session lingering feature that was used in XenApp 6.5.  This feature keeps application sessions open after the last application terminates, in case the user launches another application.

Like pre-launch, lingering has a disconnect and terminate timeout.  In XenApp 6.5, these were configured via policies and enforced by HDX, but in the upcoming release, the configuration and implementation will be moved to the broker and can be configured using the Broker Powershell SDK.

But Wait…There’s More!  Autonomic Session Termination

One of the limitations with session lingering in XenApp 6.5 is the requirement to configure static timeouts.  Set them too short, and sessions are terminated before they provide any benefit.  Set them too long, and incoming user connections may be denied because the server is out of resources.

One way we are looking to address this is to provide an option to automatically terminate pre-launched and lingering sessions based on VDA load, not based on statically configured timers.  This would ensure that we keep sessions as long as possible — even days or weeks if there are ample server resources.  However, pre-launched and lingering sessions would never cause denied connections because they would be automatically terminated when needed to free resources for new user sessions.

This is achieved by allowing the administrator to configure two thresholds on the delivery group:

  • The average load of all VDAs in the group at which point pre-launch and lingering sessions will be terminated.  If this threshold is exceeded, the broker will select a session for termination across all VDAs in the group.
  • The maximum load of a single VDA.  If any VDA’s load exceeds this value, a session on this VDA will be selected for termination.

Sessions will be selected for termination based on how long they have been in the pre-launch or lingering state.  Older sessions will be selected first.

These load-based thresholds let you set really long values (24 hours or more) without worrying about exhausting capacity.

One more advantage is that thresholds based on licenses can be configured on the delivery groups.

Note that when autonomic session termination is enabled, the broker will still enforce the disconnect and terminate timers on all pre-launch and lingering sessions.  Sessions may be terminated because of a timer or autonomic termination — whichever happens first.

This feature would also provide benefits for non-Windows and mobile Receivers, which currently don’t offer pre-launch support.  Enabling lingering for a day or more may be a good substitute.

Stay tuned as we plan to share updates on our progress in future blogs.