Applicable Products

• StoreFront

The Citrix Product Documentation site is the home of Citrix documentation for IT administrators and developers. 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. Citrix provides sample scripts that can be downloaded from one of the Workspace app or Receiver download pages (Workspace app version 2103.1 (Current Release), or Workspace app version 1912 CU3 (aka ) (LTSR), Receiver version 4.9.9002 (LTSR) by expanding Downloads for Admins (Deployment Tools). Citrix Workspace app (CWA) for Windows version 1808 CWA for Windows version 1808 provides improvements in graphics quality for sessions using legacy graphics mode (GDI graphics mode), when DPI Scaling is enabled on the client. To support employees who still need legacy applications, we integrate Citrix Virtual Apps and Desktop in a hybrid cloud workspace. This way, you have the power of Citrix Virtual Apps & Desktop and Office 365 together in one workspace.

Objective

This article describes how to enable/disable workspace control in StoreFront.

Instructions

Receiver for Web Sites

1. Use a text editor to open the web.config file for the Receiver for Web (aka StoreWeb – which is accessed by browsers). This file is typically located at C:inetpubwwwrootCitrix<storename>Web directory, where <storename> is the name specified for the store when it was created.

2. Locate the following lines in the file:
   <workspaceControl enabled=”true”, autoReconnectAtLogon=”true”
   logoffAction=”disconnect” showReconnectButton=”false”
   showDisconnectButton=”false” />

3. Change the value of the enabled attribute to false to disable workspace control for the site.

There is also a system wide WSCReconnectMode key taking the same values, default is on launch and Refresh. By default, reconnection is to all sessions, you can tune to just disconnected by setting the WSCReconnectAll (REG_SZ, same locations) to “false”. The future intention is that it will be possible to specify the values of these settings from the Account document.

Legacy / PNAgent Sites

1. The config.aspx file is tpically under C:inetpubwwwrootCitrixStoreViewsPnaConfig).

2. Search for the below:
   <ReconnectOptions>
   <ReconnectFromLogon forcedefault='false' modifiable='true'>
   <Disconnected>true</Disconnected>
   <Active>true</Active>
   </ReconnectFromLogon>
   <ReconnectFromButton forcedefault='false' modifiable='true'>
   <Disconnected>true</Disconnected>
   <Active>true</Active>
   </ReconnectFromButton>
   </ReconnectOptions>

3. Change the highlighted values to false.

Store Sites (Receiver Based Access)

You will have to upgrade StoreFront to StoreFront 2.6 to use workspace control for store services.

You can enable workspace control for Store URL (/Citrix/store) for Receiver access by using either PowerShell or by editing web.config file.

1. To edit the web.config file, go to C:inetpubwwwrootCitrixstore.

2. Locate the following lines:
   <resourcesSource id=”f01f7dc4-7f28-4bc1-b8fb-7c0db9570d20”
   storeLockedDown=”false”
   anonymousStore=”false” allowSessionReconnect=”true” />

3. Change the value of 'allowSessionReconnect' to false to disable workspace control for the site. It is enabled by default.

For more information refer to Citrix blog - How to Disable Workspace Control Reconnect.

Windows Receiver Clients

1. Go to the registry key: HKLMsoftwareWow6432NodeCitrixDazzle.

2. REG_SZ WSCReconnectMode controls when reconnects are attempted. Set to number which has bits set per the following values:
   OnLaunch = 0x1, (any time Receiver is launched)
   OnRefresh = 0x2, (App Refresh in UI)
   OnReceiverOpen = 0x4, (Opening Receiver UX)
   OnWindowsLogin = 0x8, (On First launch)

3. By default it will be set for OnLaunch | OnRefresh.

Citrix Workspace For Mac Legacy

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

Citrix Workspace Download Older Version

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

Citrix Workspace Old Version

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…

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.

Citrix Workspace 2012 Download

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.

Citrix Workspace App Legacy Download

3,573 total views, 13 views today