Citrix Application Session Prelaunch

Application Prelaunch is a feature that was available in XenApp 6.5, gone in FMA v7+ and now back again in XenApp/XenDesktop 7.6. The goal of prelaunch is to “pre-prepare” a session in the background for a user when they launch Citrix Receiver for Windows so that when they do eventually click to launch the resource the prelaunch session is replaced with a regular session and startup time is much faster.

How do we enable Application Prelaunch using Citrix Studio?

Prelaunch is only supported on Server OS, and that is Server OS with VDA 7.6 minimum installed. StoreFront 2.0 is required at minimum.

Prelaunch is enabled by Delivery Group, and can be enabled for all users who have access to that Delivery Group or a subset of users. Edit a Delivery Group and click on Application Prelaunch.

Notice the following settings:

  • Prelaunch when any user in the Delivery Group logs on to Receiver for Windows – Prelaunch for any user who logs on with access to this Delivery Group.
  • Prelaunch when any of the following users log on to Receiver for Windows – Prelaunch for any user defined in the list you specify.
  • After a specified time – End a prelaunch session after x amount of minutes, hours or days if the user actually never launches the application.
  • When average load on all machines exceeds (%) – Defined by percentage. If the percentage of load on all machines is exceeded prelaunch sessions will be ended to ensure extra new sessions are not affected.
  • When load on any machine exceeds (%) – Defined by percentage. If the percentage of load on one machine is exceeded prelaunch sessions will be ended to ensure extra new sessions are not affected.

Note: It is important to note that a prelaunch session consumes a Citrix license once connected. Prelaunch sessions that are not used by the user are by default disconnected after 15 minutes and terminated after two hours. This behaviour can be changed using the Set-BrokerSessionPreLaunch cmdlet.3-min

Note: There is a bug in Studio 7.6 that may set MaxTimeBeforeDisconnect to 00:00:00 – this is fixed with Hotfix http://support.citrix.com/article/CTX142245

The termination time can be modified within the Delivery Group also.

1-min

When prelaunch is enabled on a Delivery Group the Delivery Group reflects so.2-minWhat else is required?

A bit of endpoint configuration is required. Firstly Citrix Receiver for Windows must be installed.

Install Receiver with SSON and configure StoreFront for passthrough authentication. See https://jgspiers.com/citrix-sso-receiver-and-receiver-for-web/ for help on configuring SSON.

Set EnablePreLaunch=True either by:

Finally, you will want to create the below keys so that a prelaunch session is created as soon as a user launches and authenticates to StoreFront with Citrix Receiver. Without these keys the prelaunch session may never create unless a user restarts Citrix Receiver.

  • HKLM/Software/Wow6432Node/Citrix/Dazzle – REG_SZ InitialRefreshMaxMs=1
  • HKLM/Software/Wow6432Node/Citrix/Dazzle – REG_SZ InitialRefreshMinMs=15-min

Note: If using 32bit OS the location for the above keys will be HKLM/Software/Citrix/Dazzle.

To confirm a session is created using prelaunch, you can run a command such as Get-BrokerSession or Get-BrokerSession -AppState PreLaunched. 6-min

Note: If you have enabled prelaunch on a Delivery Group but it does not seem to be working but all prerequisites are in place, restart the VDAs and most likely prelaunch will now work.

You can also start prelaunch on a schedule by using the Schedule REG_SZ key and setting the State REG_SEZ key to 2. Both keys are located in HKLM/Software/Wow6432Node/Citrix/ICA Client/Prelaunch for 64bit machines and HKLM/Software/Citrix/ICA Client/Prelaunch on 32bit machines. This method is called Scheduled pre-launch and allows sessions to be prelaunched only during certain times of the day for example high-traffic periods. The user device must already be running and authenticated with Receiver before the prelaunch scheduled time begins. User overrides can be set within HKCU and by using the UserOverride REG_SZ key, giving it a value of 1.7-min

Note:

There is a known issue with prelaunch not working on Stores that are configured for resource filtering. For example, you have a “XenApp” filter on the below store so that only resources with the “XenApp” keyword are displayed in Receiver client/Receiver for Web. The workaround is to use exclude words for filtering rather than include words.8-minChanged to exclude.

9-min


11 Comments

  • Ray

    April 19, 2018

    So if you do son it will enable pre launch by default on receiver? Of course you need the rest, but just making sure for the receiver side.

    Reply
  • Ray

    April 19, 2018

    I meant sson.

    Reply
    • George Spiers

      April 19, 2018

      Not quite – You have to use the “/enableprelaunch=true” switch during Receiver install (or set the value in your registry afterwards manually or by using GPOs) and then you have to enable prelaunch on your Delivery Group too.

      Reply
  • Ray

    April 26, 2018

    Yea for the delivery group part.
    Ahh was confused by this…

    Session pre-launch is disabled by default. To enable session pre-launch, specify the ENABLEPRELAUNCH=true parameter on the Receiver command line or set the EnablePreLaunch registry key to true. The default setting, null, means that pre-launch is disabled.

    Note: If the client machine has been configured to support Domain Passthrough (SSON) authentication, then prelaunch is automatically enabled.

    So I need the key after all?

    Reply
    • George Spiers

      April 26, 2018

      I always set it regardless 🙂

      Reply
  • Ricky

    January 24, 2019

    There’s a problem with this, which is that the published app may prelaunch from the wrong server.

    Let’s say I have 2 published application servers in the same delivery group:

    1. Server 2008 R2 with app XYZ installed
    2. Server 2012 R2 with app ABC installed

    They both belong to the same delivery group, but they each have a different app installed. Let’s assume that the app only works on their respective OS level. Both apps are published and have tagging configured correctly.

    If you run the apps manually, they both launch from the correct servers. However, if prelaunch is used, app XYZ may launch from Server 2012 R2 (which doesn’t have the app installed) and vice versa for app ABC. I can’t figure out how to get prelaunch to respect the tags correctly.

    Application Group and tagging are both configured correctly. No problem lauching manually.

    Reply
    • George Spiers

      January 26, 2019

      Interesting. Sounds like a bug, have you contacted Citrix support?

      Reply
    • George Spiers

      January 28, 2019

      Yes this seems to be the behaviour. Have you logged a call? I noticed the same thing.

      Reply
    • Tonny Andersson

      September 20, 2019

      I think the point with delivery groups is to have identical servers in them. If you have servers with different applications, create multiple delivery groups.

      Reply
  • Ricky

    January 27, 2019

    Nope not yet. So this is supposed to work with the Application Group & tagging?

    Reply
    • George Spiers

      January 29, 2019

      I would expect it to work otherwise it defeats the purpose, but there is nothing out there in Citrix documentation to mention it working or not working..

      Reply

Leave a Reply