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.
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.
When prelaunch is enabled on a Delivery Group the Delivery Group reflects so.What 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:
- Installing Receiver with the ENABLEPRELAUNCH=true switch (see https://jgspiers.com/command-line-install-citrix-receiver-for-windows/ for command line install help).
- Setting EnablePreLaunch REG_SZ key to True within HKLM\Software\Citrix\Dazzle for 32bit machines or HKLM\Software\Wow6432Node\Citrix\Dazzle on 64bit machines.
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=1
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.
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.
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.Changed to exclude.
Ray
April 19, 2018So 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.
Ray
April 19, 2018I meant sson.
George Spiers
April 19, 2018Not 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.
Ray
April 26, 2018Yea 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?
George Spiers
April 26, 2018I always set it regardless 🙂
Ricky
January 24, 2019There’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.
George Spiers
January 26, 2019Interesting. Sounds like a bug, have you contacted Citrix support?
George Spiers
January 28, 2019Yes this seems to be the behaviour. Have you logged a call? I noticed the same thing.
Tonny Andersson
September 20, 2019I think the point with delivery groups is to have identical servers in them. If you have servers with different applications, create multiple delivery groups.
Ricky
January 27, 2019Nope not yet. So this is supposed to work with the Application Group & tagging?
George Spiers
January 29, 2019I 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..