- Under certain circumstances, uninstalling older versions of Receiver for Windows may leave some files behind on the computer and in the registry.This article can also be used as reference to completely clean a system after uninstalling a legacy ICA Client or Citrix Online Plug-in version.
- Citrix Terminal; Reset My Password; Password Reset Registration; Media Center Code of Conduct; Mover's Glossary; Budd E System; Budd E System JIRA; Budd Van Lines.
- Under certain circumstances, uninstalling older versions of Receiver for Windows may leave some files behind on the computer and in the registry.This article can also be used as reference to completely clean a system after uninstalling a legacy ICA Client or Citrix Online Plug-in version.
Is it possible to use two Citrix client versions in one image? Actually – yes!
The problem
Note: Citrix recommends that you download the latest version of Citrix Workspace app version 1904.1 or later and Receiver for Windows to LTSR 4.9 CU6 version 4.9.6001 or later that contain critical security fixes.For more information, see the Knowledge Center article CTX251986. Downloading Citrix Receiver. Click Run to install Receiver. Follow the steps to set up Receiver and get your apps, data.
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:windowssystem32appvclient.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 FilesFSLogixAppsRules 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 FilesFSLogixAppsRules 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 Applicationswfcrun32.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
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…
Citrix Receiver Legacy Mac
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.
3,578 total views, 18 views today
Version 4.8 of Citrix Receiver for Windows comes with automatic update functionality which is enabled by default. There are a couple of different ways to control the behaviour of the auto-update feature.
Note: Receiver for Mac 12.6 also has the auto-update ability.
You may want to use auto-update but adjust the default behaviour. The ways to configure auto-update related settings are described below.
Things to note
- Outbound proxies must be configured with an exception to the Receiver auto-update Signature service https://citrixupdates.cloud.com and the download location https://downloadplugins.citrix.com
- By default auto-update is disabled on Session Host, Remote PC and VDI VDA machines.
- Auto-update is disabled on machines that have Desktop Lock installed.
- Machines must be connected to the internet for auto-update to work
- Receiver for Web users cannot download the StoreFront policy automatically. You have to add or refresh the StoreFront account manually through Receiver.
The first method is GPOs. Download the Receiver for Windows ADMX templates from Citrix and import them on to your Domain Controllers. Edit/create a GPO and navigate to Computer Configuration -> Policies -> Administrative Templates -> Citrix Components -> Citrix Receiver -> AutoUpdate. You have two configurable settings.
The first setting Set the Delay in Checking for Update can be set to Fast, Medium or Slow. This allows for staged upgrade rollouts. Fast means an update is pushed out as soon as it is available. Slow means the update will be pushed out after it has been available and tested for a period of time. Medium is somewhere in between.
The second setting Enable or Disable AutoUpdate Policy is used to set auto-update to disabled, auto (default) or manual (user checks manually for updates). You can also specify if only LTSR Receiver versions are offered for upgrade and set a defer count. The defer count can be set as a value of -1 to 30. -1 means no limit is set on the amount of defers a user can perform. A value of 3 would allow 3 maximum defers for example. A value of 0 means the remind me later option is not displayed.
Citrix Receiver Legacy Download
The second method is to disable auto-update via command line when installing Receiver. A couple of new switches exist to control the behaviour of the auto-update feature.
- /AutoUpdateCheck – Configure auto-update to be on, off or manual. Values accepted are AUTO, MANUAL and DISABLED.
- /AutoUpdateStream – Control if auto-updates are for LTSR versions only or Current Release versions. Values accepted are LTSR or Current.
- /DeferUpdateCount – Allows you to specify the number of times you can defer an update notification. Values accepted are -1 to 30. -1 means the user can defer any number of times.
- /AURolloutPriority – Specify the speed of which a rollout of an upgrade will be performed. Values accepted are Auto, Fast, Medum and Slow.
For more information on a command line install of Receiver for Windows see https://www.jgspiers.com/command-line-install-citrix-receiver-for-windows/
The third option is using Preferences. This setting is per-user and user defined settings will be written to HKCU. Right-click on Receiver and click Advanced Preferences.
Citrix Receiver 4.8 Windows 10
Click on Auto Update.
Choose your desired setting.
The fourth option is using StoreFront by modifying the web.config file found in wwwrootCitrixRoaming.Find the text beginning <account id. Scroll down a couple of lines until you see:
Citrix Receiver Legacy
<properties>
<clear />
</properties>
Citrix Receiver Legacy Health
Enter lines as below, modifying to suit your needs.
The fifth option is using CitrixReceiverUpdater.exe after Citrix Receiver has been installed. CitrixReceiverUpdater.exe can be found in %ReceiverInstallLocation%CitrixICA ClientReceiver.