Is it possible to use two Citrix client versions in one image? Actually – yes!
The problem
This week Citrix publicized some vulnerabilities in their Workspace App and Receiver clients that potentially would allow an attacker to elevate their privileges. This is a binary planting vulnerability and, whilst not allowing remote code execution per se, is still something that people would look to be patching sooner rather than later.
A customer of mine (who are very security-conscious) were looking to get this addressed as soon as possible, but there was a snag. They had a small number of users (probably ~5% or so) that still needed to launch some applications from an older Citrix farm which required a downstream version of the client (Receiver 4.9 LTSR, to be precise). Whilst we can all say “well they need to remediate their old infrastructure”, many of you well know that getting large-scale remediations underway in enterprise environments can be very challenging.
Of course we could just spin up a silo of servers that had the old Receiver version installed and tie those users to those instances, but this was an environment that was running from a single image and had no wishes to start expanding that number. Also, being a Citrix Cloud environment, silos potentially also meant that siloed servers could end up running with very low user density, which would increase the overall cost of the solution for business units which needed to use the older client version.
So I was asked the question – can we run different Citrix client versions from the same image for different sets of users?
At first thought, this seemed pretty impossible. After all, Citrix Receiver and Workspace App are essentially the same application, and therefore would share Registry keys and filesystem entries. If we chose to use something like FSLogix App Masking, for instance, we’d actually need both client versions installed alongside each other to make it work, and this wasn’t possible.
I’d also seen multiple Citrix clients running using Cloudhouse Compatibility Containers, but that raised the issue of budget – Cloudhouse isn’t free and there was no money available from this customer to pay for some level of remediation.
After a bit of thinking, I wondered whether this would be possible to do via App-V – package the 4.9 LTSR version, and install the 2006.1 version? This seemed feasible – the App-V version would be in its own filesystem and Registry area. However, when I tested this, the packaged version crashed with this error
Clearly, there is still some interplay between a packaged version and an installed version that renders the first unusable.
However, I then had an intriguing thought – what if I loaded a packaged version and an installed version, but leveraged FSLogix to mask them from each other? I know I said earlier to use FSLogix we’d need to have both versions “installed” – but with App-V in the mix, that line blurs a bit. Interesting!
The solution
Without further ado, I set about my testing to see if this could be done.
Pre-requisites
- Download all install files for legacy and current clients
- Ensure you have a sequencer machine with the App-V Sequencer installed
- Ensure that App-V client is enabled on the target devices and images
- Create an AD security group that contains the users you wish to use the legacy client
- Ensure you have FSLogix Apps installed within your image, and the FSLogix Apps Rule Editor installed somewhere you can access it
Step 1 – create the App-V package of your older client version
Now obviously you (hopefully) don’t need me to tell you that you can simply enable App-V by turning on the GPO in Computer Config | Admin Templates | System | App-V. You also don’t need to invest in complicated infra to deliver App-V apps – you can simply install the MSI into your image (as long as you’re using App-V 5.x), or deploy it through a GPO, or use the excellent App-V Scheduler (which has a free edition!) which I am going to be blogging more about in the very near future. In my production environments I use the Scheduler (because it is awesome), but for this test I am simply going to add the package to a GPO Software Installation Policy (no laughing at the back, and I wouldn’t recommend this in an enterprise environment).
Here’s a video of the packaging process for the legacy client (which in this case is the 4.9 LTSR Receiver)
A note about the warning received during packaging – ctxusbm.sys is a Citrix USB monitor driver (not mouse, as I speculated in the video). Bear in mind, like I said, that creating a downstream client in this way is definitely a band-aid and could possibly cause some odd issues. However, I didn’t see any problems within my testing.
Step 2 – create the FSLogix App Masking rules for the older client version
We now need to create the masking rules for the legacy client. What you need is the GUID that your App-V package will use, and the easiest way to do this is simply to read the package ID from the packagename_DeploymentConfig.xml file. Open the file in a text editor and find the highlighted text – the package I created is shown below
Once you have this GUID, you can create a couple of FSLogix App Masking rules that match this. Open the FSLogix Rules Editor from wherever you have it installed, and create two Hiding Rules. The first should look like this (subsitute your GUID for the one shown)
The next rule does not require the GUID, and simply hides the shortcut
Finally, you need to configure the Assignments so that these rules only apply to users which are *not* in the AD group specified earlier
This means that the packaged version of the legacy client will *only* be visible to members of that AD group – every other user will have it hidden from them. Finally, save the rule and rule assignment files into a folder as we will need to access them from the image in a little while.
UPDATE – I forgot to mention that the Assignments rules above also need a Process adding to the assignments, make sure to add the process c:\windows\system32\appvclient.exe to the Assignments list with a NO, otherwise the App-V process won’t be able to read the packages!
Here’s a video of me performing these steps
Step 3 – deploy the legacy client into the image
Next, we need to deploy this package onto our images somehow. As said previously I would recommend the App-V Scheduler, but you could do it in many ways. You could install it manually (particularly if you were baking this into a master image), deploy through SCCM, use full App-V infra, script it, even use a Software Installation Policy GPO – the possibilities are many. In this run-through, I’m going to use a GPO because it is easiest, but in the production environment where I did this I used the Scheduler (which is bloody awesome).
Obviously App-V needs to be enabled in the target image – if you’ve just applied it via GPO, bear in mind the setting needs a reboot.
Here’s a video of me performing these steps
Step 4 – deploy the FSLogix Rules into the image
Next, we need to mask the legacy client from all users apart from the target group. We simply do this by copying the masking rules we created in step #2 into the c:\Program Files\FSLogix\Apps\Rules folder, where they will be processed by the FSLogix driver.
Here’s quick video of this part
Step 5 – create the FSLogix App Masking Rules for the latest client version
In order to create another set of masking rules, you need to make sure the latest client version is installed on the machine where you run your FSLogix Apps Rule Editor from. Once you have it installed, run the Rules Editor and create a new rule, but this time use the option to create rules from the installed programs, and select the latest Workspace Client.
Once this is done, it should have created all the required Hiding Rules for you
You then need to configure the assignment rules almost “in reverse” to what we did in step #2 – mask this client *only* from the AD group that our legacy client users are in.
And as in step #2, save the rules and rule assigments and copy them to a folder where we can access them again in a second.
Again, here’s a video of this part of the process
Step 6 – install the latest client into the image and apply the masking rules
Now we need to flip back to the image where we deployed the App-V package, and this time install the latest client version there. After that, we need to copy the FSLogix App Masking rules from step #5 into the c:\Program Files\FSLogix\Apps\Rules folder. Nice and simple, but I’ve done a video of this step just the same 🙂
Step 7 – setting the FTA for the legacy users
There’s one stumbling block with this – users who are using the App-V packaged version of the legacy client will need their file type association setting correctly for .ica files, otherwise they will be prompted when they launch the application. And believe me, getting the user to pick the right Citrix app to open ica files with isn’t straightforward – so let’s do it for them.
There are loads of ways you can set FTAs for users – pick your poison. You can use Citrix WEM, Ivanti, LiquidWare, you can use SetUserFTA which is an excellent freeware tool from Christoph Kolbicz – choose whichever method makes most sense for you. You need to set the ProgId for members of the legacy AD users group only, and set it to Applications\wfcrun32.exe. There is lots of information about these methods contained in this post.
I’ve done it using SetUserFTA via a startup item, in the interests of quickness. The command I am executing at startup of the user session is
SetUserFTA.exe .ICA Applications\wfcrun32.exe "Receiver 4.9 LTSR Users"Obviously, you need SetUserFTA in your image to use this method, and the group name targets the FTA to members of that group only.
Obligatory video…
Step 8 – testing time!
After all of that, let’s see if it works. We have a Citrix Virtual Apps environment running that we can connect to, and some test users configured. Can one use the old client and one the latest client from the same image?
Naturally, let’s look at a video to see if it works 🙂
Wow, just glad to say after all that effort – it seems to do what we want it to 🙂
Summary
Now if you find yourself wanting to use this method, there’s a good chance the farms or infrastructure you are connecting to are unsupported anyway, so I wouldn’t worry too much about the “OMG unsupported!” outburst that many feel with regard to this. But having said that – this is a band-aid method, and not something I’d want to see used as a key component, because some things could break.
However, as a stopgap method of giving users from the same image access to legacy client versions, I think it works great, and it’s a great advert for how App-V married to FSLogix can do awesome stuff.
I did have the thought that you could maybe mask the legacy client version from a specific process, so that users would only expose the old version if they used a particular browser, for instance, to access the published resources. This is certainly possible, as FSLogix allows you to configure masking rules based around processes, but I didn’t go so far as to have a look at this angle – I may do an update to this next week.
