Forcing Citrix/RDSH users to open files in either Visio or Visio Viewer

On RDSH or other shared platforms, you often find users who may need to open files either in a full editor or a cut-down viewer, dependent on whether they need to edit or just view the files in question. Adobe Acrobat is a common application that exhibits this behaviour (where the power users edit the PDFs in Acrobat, and the ordinary users simply view them in Reader), but another one that often crops up is Visio. Some users need to edit and save them using the full Visio client, whereas other users simply need to be able to view them using Visio Viewer. Whereas Acrobat/Acrobat Reader is often quite easy to set up for different groups of users, Visio/Visio Viewer is a little more challenging, as the Viewer is integrated into Internet Explorer and doesn’t integrate particularly well with the full-fat client – especially on shared systems like RDSH/Citrix/etc.

This article discusses how to configure your system and users so that a particular group can open files using the full version of Visio, whereas all other users will simply be directed to the Visio Viewer app.

Pre-requisites

There are a few things you will need to get sorted out before you start.

Don’t disable Internet Explorer!

I know it is tempting to remove Internet Explorer as you can do in newer versions of Windows, but the Visio Viewer still depends on it (as it is technically an IE add-on), so don’t give in to that temptation.

Install Visio

Firstly, you need to install the full version of Visio. This used to be a little tricky on RDSH platforms, as there was a Terminal Server-specific version of Visio that had to be used, but more modern versions of Visio should be fine as long as the licensing is in hand. Bear in mind there are considerations around KMS/VLK as well as the 32-bit and 64-bit Office versions – this is a bit out of scope for this article but will need to be thought about.

Install Visio Viewer

Also make sure you install Visio Viewer! You can find the download at this link

Create an AD group

Next, create an Active Directory group to drive the Visio entitlement. The idea is that all users who are in the AD group will be allowed to use and open files with Visio, and all users who are not in the AD group will default to Visio Viewer. Populate the group as necessary with entitled users.

Install FSLogix

We are going to lean on FSLogix App Masking to handle the relevant file type associations for each set of users, so make sure you install the FSLogix Apps agent as well prior to starting this process.

The hard yards

Now we need to move on to the specific bits of configuration required to get this to work properly.

Custom Registry keys

Firstly, Visio Viewer, because of its integration with IE, relies particularly on the HKLM\Classes area of the Registry to decide how to open. If these keys are set to the “full” version of Visio rather than the Viewer, then even if the user cannot see the Visio application, it will try to download the file rather than render it in the browser and get stuck in a loop like the image shown below.

The interplay between HKLM\Classes and HKCU\Classes is discussed separately in my FTAs article here, should you require some more background.

You need to make sure that the HKLM\Classes Registry keys for the Visio file types (usually .vsd and .vsdx) are set to open with the Viewer by default. Also, we need to create some custom Registry keys which we can redirect the “full” version users onto so they get the right FTAs. Run the commands below on your gold image to enable both of these requirements (or inject them in some way):-

reg add "HKLM\Software\Classes\.vsd" /ve /d VisioViewer.Viewer /f
reg add "HKLM\Software\Classes\.vsdx" /ve /d VisioViewer.Viewer /f
reg add "HKLM\Software\Classes\.vsd" /v "Content Type" /t REG_SZ /d application/vnd.ms-visio.viewer /f
reg add "HKLM\Software\Classes\.vsdx" /v "Content Type" /t REG_SZ /d application/vnd.ms-visio.viewer /f

reg add "HKLM\Software\Custom\FSLogixRedirection\Visio\.vsd" /ve /d Visio.Drawing.11 /f
reg add "HKLM\Software\Custom\FSLogixRedirection\Visio\.vsd" /v "Content Type" /t REG_SZ /d application/vnd.visio /f
reg add "HKLM\Software\Custom\FSLogixRedirection\Visio\.vsdx" /ve /d Visio.Drawing.15 /f
reg add "HKLM\Software\Custom\FSLogixRedirection\Visio\.vsdx" /v "Content Type" /t REG_SZ /d application/vnd.ms-visio.drawing /f

Note – dependent on your version of Visio, you may need to edit the Visio.Drawing.xx version numbers supplied here; these were done using Visio 2016 Standard.

These commands will set the default HKLM\Classes entries so that users will open .vsd and .vsdx files using the Viewer, and will also create some custom Registry keys in HKLM\Software\Custom\FSLogixRedirection\Visio that we can point users at our modified values.

FSLogix Hiding Rules

Next, we need to create an FSLogix Hiding Rule to stop Visio being accessible to users except those in the Visio group. Open up the FSLogix Rules Editor and create a Hiding Rule as below

The Hiding Rule will hide the executables, the shortcuts and the uninstall information. As far as assignments go, ensure that this rule applies to the Everyone group but does not apply to the Visio AD group, as shown below.

FSLogix Redirection Rules

Next for the tricky bit. Let’s configure some FSLogix Redirection Rules so that the users in the Visio AD group get redirected from the “real” HKLM\Classes area (that points to Viewer) to our “custom” HKLM\Classes area (that points to Visio).

Open up the FSLogix Rules Editor again and create another rule, this time make it a Redirection Rule. Configure the settings as below

For the assignments this time, ensure it does not apply to Everyone, but does apply to all the groups, users and processes specified below. The reason msiexec is included is because sometimes Visio, when launched, will try to do a repair of the FTAs Registry values, so including it in the rule means that it would only ever do this on the “custom” Registry values rather than the “base” ones which point to Viewer.

Create a GPP or WEM Action to set HKCU values

In order to avoid the “repair” we specified earlier, it also helps, for the Visio AD group, to forcibly write some Registry values into HKCU for the FTAs. You can do this with Group Policy Preferences, Citrix WEM, Ivanti UWM, a logon script, in fact any way that takes your fancy.

We simply need to set the following values, which we have done via GPP in User Config | Preferences | Windows Settings | Registry

And make sure that they are each applied via an Item-Level Targeting (or equivalent filter) to the AD group you created earlier.

Apply FSLogix rules

The final thing to do is to apply your FSLogix rules to your target machines, by copying the files down into the Rules folder on the local device. Obviously there are many ways you can achieve this, so pick whatever is best for your environment.

Testing

So everything should now be in place. Firstly, let’s log on as a user who is in the AD group for Visio, and try to open .vsd or .vsdx files.

Looking good – they open up promptly in Visio, which is what we were expecting.

Next, let’s log back out and open up a session as a user who is not in the AD group for Visio.

When this user opens a .vsd or.vsdx file, it opens up embedded in Internet Explorer, using the Visio Viewer add-on. They also can’t see Visio or run it, because of the FSLogix Hiding Rule we created.

Summary

This provides an easy and seamless way to use FSLogix to drive group-based utilization of Visio or Visio Viewer for users on RDSH platforms. The method described above can easily be adapted to other similar software if required.

It is worth noting that this method might possibly be able to be used for Visio licensing compliance, but it’s a bit of an open-ended question and you’d need to confirm with Microsoft based around your version. If you were on the old device-based licensing model, though, you can also get around this with FSLogix – see here.

A further benefit I find from using this method is that you don’t get the “choose an application to open this file” dialog box – the user is simply directed straight to the app you have specified. If you do get issues with the dialog box, you may need to look into setting the UserChoice values that are discussed in my previous article.

This is not intended to be a hard-and-fast guide to multiple app FTAs on RDSH – there are many ways you could skin this particular requirement, although I did find that using SetUserFTA didn’t seem to work for Visio Viewer, hence why I ended up down this route.

Credit due to Aaron Parker for tipping me off to the fact that using FSLogix would make this nice and easy ? – originally I was disappearing down a rabbit-hole of Ivanti, FSLogix and SetUserFTA together.

Stay tuned for some logons goodness, hopefully dropping by the end of the week!