Citrix XenApp & XenDesktop 7.17 allows you to enable session sharing between a published desktop and application in a double hop scenario with almost no administrative effort. For your end users, this means that a published app available locally in their published desktop will be started within the same session. This avoids an additional logon cycle allowing the application to launch faster. This is not only beneficial for user experience, it also saves resources in your environment as sessions are consolidated.

Some history

Since XenApp 7.x, the default behavior for launching a published app from a published desktop (double hop or also commonly known as ICA in ICA) was changed to always start a new session. Workarounds are available to override the default but these can be more challenging to implement and may imply some limitations. For those who are unable to upgrade short term, I will summarize the previous method at the end of this article.

XenApp/XenDesktop 7.9 introduced the application groups feature giving administrators a lot more control and flexibility regarding session sharing between applications. However, this functionality was only applicable to published apps and did not offer more control on session sharing between apps and desktops. XA/XD 7.17 addresses this limitation in a very easy to configure way and is completely transparent for your end users.

Requirements

This feature needs three components to be aware to operate: the Desktop Delivery Controller (DDC), Storefront and Citrix Receiver. The requirements to achieve session sharing between a published desktop and application are as follows:

  • Desktop Delivery Controller 7.17
  • Storefront 3.14
  • Citrix Receiver for Windows 4.11 on the published desktop
  • Application published on the same Desktop Delivery Group
  • Application launched using the Citrix Receiver legacy client. (Web client is not supported)
  • ApplicationType must be HostedOnDesktop

You are not required to upgrade the VDA to 7.17. This means that if you would like to stick to a certain feature set of the VDA, e.g. 7.15 LTSR, it is still possible to use the feature as long as the components mentioned above are at the minimum version.

How does it work?

The requirements mentioned above may already gave you a hint on the flow of the feature. Please find a high level overview below:

  1. The administrator configures behavior through a computer policy using the Receiver admx-template. (optional, as enabled by default)
  2. User launches a published app from within the published desktop. Citrix Receiver installed on the desktop will contact Storefront to initiate the application launch. If the application is available locally and if allowed by the policy, Storefront will take the request to launch locally into account and will include this information in the XML app launch request sent to the DDC.
  3. The DDC handles the XML app launch request. The adminisitrator can configure on a per-app basis if local launch is allowed.
  4. The DDC will send the XML file containing the information on how to launch the application back to Storefront . If local launch is prohibited, it will contain the information on how and where to start a new session.
  5. Storefront informs Receiver how to start the application. If local launch is prohibited or not possible, Storefront will generate an ICA file as normal.
  6. Receiver checks whether it can launch the application locally or not.
  7. Application is launched:
    a. All conditions to use the feature are met: start the application locally
    b. Local app launch is not possible: Start a new session using the ICA file received

Implementation

Once you have your Citrix Receiver 4.11 installed in the published desktop and the backend at the correct XenApp/XenDesktop version, enabling session sharing between published application and desktop can be done without much effort. By default, it is allowed.
You can control the feature’s behavior as follows:

IMPORTANT: this feature also works in Single Hop scenarios! This means that the same policies and application settings can be used to configure the behavior on Windows endpoints.

Receiver

The admx-template available with Receiver for Windows allows you to fine-tune the behavior through a computer policy. These client settings are applicable for all published applications launched through Receiver.

Possible settings:

  • Enabled: launching locally (within the same session) is enabled and following additional options are available:
    • AllowAllApps: The app will launch locally instead of the equivalent published app. This includes local Win32 apps (e.g. Calculator, Notepad)
    • AllowInstalledApps: Only additionally installed local apps (i.e. excluding local Win32 apps) will launch locally instead of the equivalent published app
    • AllowNetworkApps: Always launch the published app
  • Disabled: published apps will always be launched in a new session
  • Not configured: enabled with setting AllowInstalledApps

After succesful application of the policy, you can observe the settings in the VDA’s registry:

Storefront

There is no additional configuration needed. Storefront will include the preference in the XML app launch request sent to the delivery controller automatically. (as of version 3.14)

Desktop Delivery Controller

On the DDC, you can enable or disable the feature on a per-application basis server–side. This setting takes precedence on the Receiver setting allowing administrators to enforce prohibiting the feature. As with Receiver, the default is Allowed.
All you need to do is ensure the application is published as a HostedOnDesktop application on the same Desktop Delivery Group as the published desktop.

This feature does not come with any GUI changes in Studio. If you would like to force launching the application in a new session, you can configure this through Powershell by setting the LocalLaunchDisabled property of the application to $true using the Set-BrokerApplication cmdlet. Again, itis enabled by default, so this is only required if you want to explicitily prohibit the feature for a specific published application.

Putting it to the test

As you may have noticed, I have published calc.exe in the example above. This is a local Win32 application so in order to allow the feature, I had to change the default Receiver policy to Enabled – AllApps.

When an end user starts Calc through Receiver (or desktop/start menu shortcut created by Receiver), a local instance of calc.exe will be started instantly.

On the DDC, you can clearly see that only one session, the published desktop, is active for that user:

The workaround for XenApp & XenDesktop 7.x versions < 7.17

To enable session sharing between published desktops and applications in an environment before 7.17, you can use a workaround by adding the prefer keyword to the published application. There are limitations however, as you will need to disable Self Service Mode on the Receiver installed on the published desktop. This method remains valid in 7.17 but the new feature will take precedence.

Here’s how to do it:

  • VDA

Create a folder locally on the VDA or on a network share readable for the user that will contain shortcuts to the applications that need to be launched locally. In this example, we will use notepad. I’m testing with Receiver 4.9 so the feature is not available and there is no need to disable it first.

IMPORTANT: make sure to give the shortcut a different name than the name of the published application!

Configure following registry settings on the VDA. You can also apply them through the Receiver admx-template with the exception of the PreferTemplateDirectory setting:

HKLM\SOFTWARE\WOW6432NODE\Citrix\Dazzle
(for 32bit OS: HKLM\SOFTWARE\Citrix\Dazzle)

  • SelfServiceMode: False (REG_SZ)
  • PreferTemplateDirectory: <path to your shortcuts folder or network share> (REG_SZ)

One of these two settings or both:

  • PutShortcutsinStartMenu: True (REG_SZ)
  • PutShortcutsOnDesktop: True (REG_SZ)

  • DDC

Add the following keyword to your published application’s description field in Citrix Studio:

KEYWORDS:prefer=”<shortcut name>”

In our example, we named the shortcut note.lnk so we use KEYWORDS:prefer=”note”

On the user’s published desktop, the notepad application will be added to the start menu and/or desktop automatically. Note that because we disabled the SelfServiceMode, the user cannot use the Receiver application anymore to start an application as in this mode the published applications and shortcuts are controlled only by the administrator.

However, when the users clicks on the shortcut generated by Receiver on the desktop or in the start menu, a local instance of notepad will be opened within the desktop session instead of starting a new session:

What just happened?

Before starting a new session, Receiver checks if the string following the prefer-keyword matches with one of the shortcuts in the configured PreferTemplateDirectory. If a match is found, Receiver launches the shortcut to the local application instead of starting a new session. Using this workaround, we have managed to start a published application within the same desktop session. Specifying a network folder as the shortcut folder enables centralized management and avoids the need to update the master image when making changes to published applications.

Conclusion: we have achieved the same goal as with the XA/XD 7.17 feature. However, this method takes a lot more configuration to get to the same result and it involves disabling SelfServiceMode. Upgrading your environment to a supported version avoids disabling features and will make the configuration and management of your environment a lot easier.

Additional resources: