Well, this started out as a blog post about FSLogix Apps. But - we ran into a problem pretty quickly. Namely, that from Windows 8.1/Server 2012 R2 onward, you can no longer deploy per-user file type associations (FTAs). So if you've got multiple users on XenApp/RDS platforms and you want to give individual users different FTAs, you're going to be up against it.
Firstly, why would you want to do this?
Well, let's imagine a XenApp environment where you might want users to open files from the same server but with different apps, possibly for licensing reasons. You might want some users to open Visio files in Visio, and others in Visio Viewer. Or you might want some to open PDFs in Adobe Reader but others in the full version of Acrobat. Prior to this, you could simply use Group Policy Preferences Folder Options to deploy an Open With item. Each user would get a particular application associated with a particular file extension. Nice, easy, uncomplicated.
Whilst writing a post on FSLogix, it became blatantly obvious that something had changed under the hood (it's IE10 all over again! Urgh!) The Group Policy Preferences method I wrote about previously simply flat-out doesn't work any more. Normally, user FTA settings are written to a specific Registry area - HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts, with subkeys for each filetype (e.g. .PDF). But Microsoft appear to have changed something. Now, when you write a new filetype using the Default Programs part of Control Panel (or the Default Programs context menu), the Registry settings are changed in a very different way.
To show you what I mean, I've logged on to a Server 2012 XenApp system with three different PDF readers installed locally, and I'm going to select FoxIT Reader as the application to use. The way I trigger this is by right-clicking a PDF file and choosing Open With | Choose Default Program, but you can also access this through the Control Panel.
Once I select FoxIT Reader as the default program, we can see the Registry changes we'd expect - but there are some additions we haven't seen previously
Note the Hash value. Apparently, this is a hash generated from the application, the computer name and the username, and which needs to be unique. So if I export these values into the user profile and roam them to another XenApp server, the FTA will be lost. If you export, roam, save or persist this Registry key, when you move to another server system, you are prompted to choose the default program again, because the hash doesn't match. Apparently this was done to reduce tampering by malware, but it's very short-sighted because it doesn't take into account multi-session systems like XenApp and RDS.
Even more annoying, is the fact that the action of setting a default program in this way also writes a permissions change to the UserChoice key. See below
Note the Deny set for the user account that made the change (in this case I was logged on as Administrator). This means that you can't set the values in this key through a script or such like without altering the Registry permissions first. But even if you do alter the permissions, you need the Hash value to match the server system - and without knowledge of the algorithm in use, you're not going to get very far.
However, Microsoft have handily made a function available for setting the file associations. This involves setting the file association(s) for a user, and then exporting it(them) out to an XML file using the following command
Once you've exported the XML file with your configured file associations (you can edit it by hand to just get the FTAs you need), you can then deploy this at logon by using a Group Policy Object. This all sounds good so far...
...until you realize that the GPO that sets the FTA is Computer Configuration only. That's right, it writes to a Registry key in HKEY_LOCAL_MACHINE. Making it a royal pain in the proverbials for deploying to multi-session environments such as XenApp. If you don't believe me, check it out - it's to be found only in Computer Config | Policies | Admin Templates | Windows Components | File Explorer
So somehow, we need to set this HKLM value for each user individually. The Registry value appears to be read at logon and the FTA is set at that point (meaning that the values are then written to the HKCU FileExts key) - so maybe we can get around this if we can find some way of deploying a HKLM value based around the user context?
Just for posterity, here's a diagram detailing how I believe that this now works (based on my own research and observations)
This is how it seems to work in practice - so maybe we can leverage Group Policy Preferences again to make it operate on a per-user basis. Alternatively, you could use AppSense, RES or any other software that allows you to set HKLM entries on a user-based condition, but GPP seemed the most logical to choose given that most environments have access to it.
Not that we're not going to use the actual Group Policy Object to achieve this - we will use the Registry value that the GPO sets. This is because as a Computer Config GPO, filtering based around user-based conditions is very difficult, if not impossible, but if we do it as a GPP Registry Item we can use Item-Level Targeting on the user level.
So, first we need to log on as a user and set the default associations (in this case, for the PDF file extension) to each of the required applications. Once we've set each one, we need to export the associations out using the following command (note that the file path must exist prior to running this)
Dism /Online /Export-DefaultAppAssociations:filepath\filename.xml
When you've done this, you should have an export file that looks something like this
You can now strip this down by hand to get the file associations you require, such as shown below
Repeat as necessary for however many FTAs you need to set up.
Now you need to put these files on the local machine. Yes, you can't use a network share - increasing further the overhead and unwieldiness of this solution. You could use GPP or AppSense EM to copy files from a network share, but you must have the XML files local to the machine. In our case we've created a directory c:\Assoc - it's up to you how you attack this part.
Next we need to set up the Group Policy Preferences. We will create a single GPO and add three sets of preferences to User Configuration | Preferences | Windows Settings | Registry, one for each of our PDF readers.
Each preference item points to the same Registry value (the one from the GPO) - HKLM\Software\Policies\Microsoft\Windows\System\DefaultAssociationsConfiguration - but writes a different value, each of which corresponds to a different XML file. Below is the one for Adobe Reader
As we are writing to an HKLM key, the "Run in logged-on user's security context" option must be unchecked
And finally we will use Item-Level Targeting to direct the Preference item to a specific user-based condition. In this example, we've used the user's OU, but you can use any user-based condition you deem necessary (or combination of such, should you desire)
Finally, we link our new GPO with the Preference items to the XenApp server OU, and ensure that we also have a GPO that enables Loopback Policy Processing so that user items can be executed in the machine context
And then it's time to test.
In my lab, this worked very well, even with multiple users logged in to the same system at the same time. It seems apparent that the HKLM value is read at logon time and then applied to the HKCU area as stipulated in the XML file. Each set of users from each OU could access the configured PDF reader when double-clicking on a common PDF file on their desktop.
If you wanted just to set the default file association at first logon and then roam the user's preference from XenApp server to XenApp server, this is a little more tricky. The Hash value we mentioned in the UserChoice key is unique to the system it was generated on. However, this is unlikely to be an issue except in non-persistent VDI environments, as this form of "enforced" FTA is normally a product of licensing restrictions rather than user selection. I will, though, be looking at the roaming of these settings as part of a future update to this article.
Summary
It's getting like Groundhog Day with Microsoft. We had the whole IE10 debacle that they seem to have backtracked and fixed somewhat (update to the articles coming soon! I promise!), but this is again a case of something that worked perfectly adequately being unnecessarily broken.
The whole idea of having to set an HKLM key which then is read into HKCU is utterly backward. Why can't we just have an HKCU setting or User Configuration GPO to manage this? Although this method works, I can't help but think that a logon storm to a XenApp server, with all the XML file paths being written, read and committed from the same HKLM value at the same time, could potentially cause some issues. Add to this the fact that the XML files have to be maintained locally, and you get the feeling that you just took a load of backward steps from a management perspective. The old "Folder Options Open With" in GPP worked absolutely fine. Why change it? Some have speculated that it's something to do with the Modern interface and FTAs that can cross both application areas, others that it's a security setting - but I think it's just completely stupid. At the very least, give admins a way to manage it. Microsoft do have a product called Remote Desktop Session Host, last I checked, and you'd think they'd want people to use it.