QuickPost – Using vPrefer instead of Keywords with Citrix Virtual Apps and Desktops

vPrefer is a little-known Citrix feature that offers you some handy functionality for niche situations. Let’s quickly run through it.

What seems like an age ago (well it kinda was I guess – three years ago!) I wrote a blog about using KEYWORDS:Prefer to launch locally-installed applications when using Storefront. This came around because my users had been migrated from thin clients to laptops, but still were very much in the mindset of using Storefront to invoke their applications. KEYWORDS:Prefer was the usual way to force a locally-installed instance of an application to start rather than the published, server-hosted version, but it was a bit fiddly. You had to alter the descriptions of your published apps to include keywords, you had to make sure the names of the shortcuts matched the published applications, you had to include them in a special folder – it was a real pain to put in place sometimes.

Fast forward to today, and I’m in a similar situation. I have a multitude of users logging on to Citrix Cloud published desktops and from there optionally launching other apps (which aren’t available from the cloud Workspace) from a different, hosted farm. You’ve guessed the issue though – they have Office apps installed on their Cloud desktop, but they are so used to running apps from the Storefront interface they are running Office apps double-hopped….when they could be doing it single-hopped. And naturally, there are some apps they need to run double-hopped from the hosted farm – so how do we tell them to “run the apps locally that you are able to” without getting them all confused? You know the drill with users – a lot of them just want a process to follow without any deviation.

Fortunately, from 7.17 onwards, we now have the option to use vPrefer to invoke this instead. The pre-requisites for this are:-

  • Desktop Delivery Controller running 7.17 or higher
  • Storefront 3.14 or higher
  • Receiver 4.11 or higher on the published desktop

You don’t need to have a 7.17 VDA or higher – as long as the components mentioned above match up, you can still leverage the vPrefer feature.

The vPrefer process flow runs as below:-

The whole process is driven by the Workspace App policies. As long as all of the conditions are met, when vPrefer is enabled the application will be launched locally if it is not explicitly prohibited and the application’s command line can be located on the local device. You can control the specific types of applications that can be launched locally with further GPO options.

Also, this requires the user to be accessing StoreFront through native Workspace App or Receiver – the web versions won’t work. As with KEYWORDS:Prefer, it would be cool to see this extended into the web versions as they are usually much more widespread in their usage.

In order to enable the policy you need the latest receiver.admx and receiver.adml placed within your c:\windows\policydefinitions folder or alternatively the GPO central store. Once present, you should be able to see the vPrefer options under Computer Config | Admin Templates | Citrix Components | Citrix Workspace | Self-Service

Once the policy is Enabled, launching locally is allowed. The following additional options are available:-

  • Allow all apps – every published application will launch locally, if possible
  • Allow installed apps – only “additionally installed” local apps (so anything that has been deployed onto the machine via an installer) will be launched locally. Native Windows apps (such as Calculator, Notepad, Remote Desktop, etc.) will not be launched locally
  • Allow network apps – always launches the published application (which is effectively the same as setting this policy to Disabled)

It is also worth mentioning that this doesn’t have to be used in double-hop scenarios. You can use it for single-hop scenarios as well. So if you have a physical Windows endpoint that users are running Storefront from, you can configure these same policies to force the application to open locally, if possible, when invoked from Storefront.

Compared to the “old” way of doing this, vPrefer is an absolute breeze. Here’s a quick video showing me launching the apps “old-style”, then applying the GPO and seeing the effects straight away. Rather than fiddling with keywords and shortcuts, this is much more simple and straightforward.

So there you have it – vPrefer is an easy way to enable Workspace App-happy users to continue using the full client as their entry point to applications, without putting unnecessary load on the published apps infrastructure. The one drawback is that it requires the user to be using the full client rather than the web client, but if your users are OK with that, then it’s dead quick to set up and does exactly what it says on the tin.

If you’re not at the required software versions to implement this, the KEYWORDS:Prefer method is still perfectly viable. If you have to do it this way, then my previous post still stands.


  1. Very neat function and great post as usual!
    Say you’re on a shared hosted desktop and have the workspace app opened up there.
    What would happen if the specific published app you choose is actually published to another delivery group but also happens to exist on the server you’re presently on? (f.ex. if there’s two published versions of the same application where one is separated because it has a unique requirement for a select group of users – and you want the unique one). Will that be tested for in the ‘allowed to run locally’ I wonder?

Leave a Reply

Your email address will not be published. Required fields are marked *