Recently I did some work in an environment where users had been migrated from a thin-client environment where they used hosted applications through Citrix Storefront, onto a Windows 10 fat-client environment with a number of their applications locally-installed. The challenge we faced was getting users to use the local copies of applications rather than the ones hosted on Citrix XenApp, as they’d grown quite accustomed to using Storefront during the years of thin client technology.
Now, I hear you say, this isn’t a technical issue, it’s a training one. As the venerable Ed Crowley once said, “there are seldom technological solutions to behavioural problems”. I agree – to a point. However, Citrix Storefront (and many other methods of application presentation, to be fair) are an excellent way of delivering applications to users, particularly in mixed environments where some are hosted and some are installed locally. It fits nicely into the “app store” model that users are intimately familiar with due to their use of similar interfaces on Apple, Android and (dare I say it?) modern Windows devices (I should also give honourable mentions to products like the VMware View Portal, Software2 Hub and RES IT Store that do an excellent job of very similar functionality). If users are used to using this model for discovering, provisioning and launching applications, we shouldn’t discourage them away from it.
So, in this situation, shouldn’t we try to find some way of launching (if available) the locally-installed copy of certain applications when invoked from the Citrix Storefront interface? Particularly for this example, it offered a way of reducing load on the Citrix XenApp servers and improving user experience quite seamlessly.
The solution to this is the use of Keywords within Citrix Storefront, so let’s explore it a bit here.
Keywords
Keywords are a kind of tag that you associate with published applications or desktops within the properties of the resources in XenApp or XenDesktop. When launched or enumerated, the keywords invoke specific behaviours that you can use to customize the delivery solution.
The one we are interested in is the Prefer keyword. This works by iterating through the local Start Menu and searching for a string that is specified along with the Prefer keyword. If a match is found, then that local application is launched instead of the published application. If no match, then the original published resource will be launched.
Naturally, this means you can search for partial matches or folder paths, but bear in mind that the first one matched will be launched. If you’re searching for specific versions (and bear in mind that Microsoft Office is notorious for changing the shortcut name strings from version to version), it’s best to be as precise as possible so as to avoid possible screw-ups.
Testing
We are going to do this with some Windows 10 1703 clients and both a XenApp 6.5 and XenApp 7.x server (7.13 at the time of writing, it’s Friday and I can’t be bothered with a 7.14 upgrade just now). The Storefront session we’re using is actually installed on the XenApp 6.5 server but it doesn’t matter where it sits.
Personally I’d use Storefront 3.x for this. I think it can be done with 2.x but I’ve read a number of articles saying it was a bit hit and miss and upgrading to 3.x solved the issues. If you’ve got a 6.5 environment, you can easily upgrade to Storefront 3.x, although if you’ve got 1.x Storefront you will need to uninstall it and then reinstall the latest version, as there is no upgrade path from 1.x to anything except 2.0, which is notoriously difficult to find for download (at least in my efforts).
We are going to publish an instance of Outlook 2007 on XenApp 6.5 and an instance of Internet Explorer on XenApp 7.13. The idea is that Outlook 2007 should launch locally rather than from XenApp, as it is installed on the Windows 10 clients, but Internet Explorer should launch on the XenApp server for one client (which we’ve removed IE from), and launch locally on the other (which, unsurprisingly, we haven’t removed IE from). If you’re wondering why I used Office 2007 – I don’t want to use my entitlements for Office 2016 for testing, and I happened to have an old copy of 2007 lying about 
The principles remain the same, though!
Also, if you’re wondering how we removed IE from one of the Windows 10 instances, this video should tell you what you need to know.
Preparation
Firstly, let’s publish the applications and set them up with the required keywords. You need to check the Start Menu of the client desktop for the string you’re trying to match. For Outlook 2007 on Windows 10, this appears to be “Microsoft Office Outlook 2007”.
So if we’re being precise (and it generally pays to be), we will add the string “Microsoft Office Outlook 2007” as the prefer keyword to our Outlook 2007 published application on XenApp 6.5. If you’re just looking for any locally-installed version of Outlook, you could just use “Outlook”. Test thoroughly though if you’re using partial matches. The keyword on XenApp 6.5 sits as part of the application properties under Name.
Note also the use of the second keyword “Mandatory”. This is to ensure that a user with an entitlement to this application gets it added to their Receiver subscriptions without having to search for it themselves.
Now we are going to do the same on the XenApp 7.13 server, for our Internet Explorer published application. This time, of course, the search string will be “Internet Explorer”. But we need to bear in mind that on Windows 10, a shortcut to Internet Explorer doesn’t exist on the Start Menu by default, so firstly we will need to add one. The problem with this is you can’t add shortcuts to C:\ProgramData\Microsoft\Windows\Start Menu\Programs unless you elevate, and doing so directly from Explorer is difficult. The solution is simply to log on, create one on the desktop, then move it to the Programs folder. It should then show in the Windows 10 Start Menu (as below). Ideally you’d want to do this in your base image or through Group Policy or another tool to make sure it is there, otherwise the search will fail!
Then we simply need to change the keywords setting on the published application on XenApp 7.13 to match our shortcut for Internet Explorer.
Now, simply access the Citrix Receiver on the Windows 10 clients. IMPORTANT NOTE – this only works with the native Receiver, the one you can install. The Receiver for Web, at this current moment, doesn’t support keywords.
Once I’ve logged in to the Citrix Receiver (or accessed it through pass-through authentication), I can now see the two published applications presented to me. And yes, I did brand my Receiver with the VMware logo. Don’t you know yet that I’m a complete child?
Another key point to make here is that if a user had an existing subscription to one of these published applications before the keywords were added (i.e. they had added it into their Favourites list within the native Receiver), the keywords will not take effect until the subscription is removed and re-added. You can do this manually or remove it through a script (more on this later this week), as I think subscription data is not stored within the user profile (but as I said, more on this later).
Once the user has successfully subscribed to the application with the keywords (and if you’ve used Mandatory, it should be done automatically for them once any existing subscriptions are removed, if there were any), they can now test and launch it. When the user invokes the Outlook 2007 application from Storefront, you should see that instead of running it on the XenApp session host server, it launches locally
And the same for the browser, if we launch it on the machine with IE installed…
…but then if we jump to the machine with IE removed, we can see it runs a hosted version (the lack of the “launch Edge” tab shows it is a non-Windows 10 version that is running)
Naturally, if the user logs on to a machine where the Outlook 2007 app and shortcuts aren’t present, it also runs the hosted copy. So this is an ideal solution for users that roam around lots of different and disparate devices but need access to the best-performing available version from a single pane of glass. I like it! Main drawback is having to remove subscriptions each time you edit the keywords, but if you make them Mandatory this should only bite you once.
Summary
I think doing things like this is cool – allowing users to use a single interface to launch all of their apps. It’s a shame it only works through native Receiver currently – Receiver for Web support would make it really neat. What would be ultra-cool is detecting the user state and tailoring an application launch type specifically to that – think using hosted apps when at a site with a poor connection and the like. I’m going to have a look at this in a few days, work permitting.
I’m also going to record a video of how to do this and a few other XenApp bits, as well as a follow-up article about editing subscriptions and maybe have a look at branding the Receivers. I think Citrix has been a bit neglected around here in favour of Windows 10 recently – let’s bring it back to parity.
The post Launching locally-installed applications from Citrix Storefront using keywords appeared first on HTG | Howell Technology Group.