File Type Association with WEM and SetUserFTA
Conquering nasty file type association challenges with SetUserFTA
Intro
I am sure many of you have had the enjoyable experience of dealing with user FTA (File Type Associations) within Windows 10 and Server 2016 (Windows 8 onward is a jerk really..)
For those that aren’t aware, Microsoft made a nice little change for us which made FTA assignment on a per user basis almost impossible without loads of hacks and cracks. James Rankin has a good write up here. Sure, there are ways to pre-populate the FTA’s and app associations etc, but its stored in a computer context not user, and just isn’t a solution that addresses the required flexibility that most organisations with SBC environments have.
Luckily, there are some clever cookies amongst the ranks of those that don’t like to be told “no”, such as one Mr Christoph Kolbicz. He has managed to successfully reverse Microsoft’s decisions to block our ability to control this nicely, and has written a cracker utility called SetUserFTA. You can find his blog, his explanation and his tool (which he offers to the community) here.
WEM has great ability to control FTA natively, however with the latest releases of Windows 10 and Server 2016, I am finding that the behaviour is not as smooth as it once was with older Operating Systems, and settings either aren’t honoured by Windows, or result in far too many prompts for the user.
I find the easiest way to drive this magical new utility, is of course however, via WEM and there are two options for control here.
Option1. Create an external Task in WEM, point it to the SetUserFTA.exe and assign it to all users. SetUserFTA allows you to specify a configuration file, which includes the ability to specify FTA settings per Active Directory group. This, from a WEM perspective means simply launching the SetUserFTA.exe and passing the assignment component back to the Config File.
And the config file:
Option 2 (my preferred) is to bring the visibility back into WEM, utilise multiple external tasks, and assign to your users based on your normal WEM processes. This option keeps visibility within WEM around your assignments for those that like single pane of glass and don’t like the black hole of multiple configuration points in the environment.
It’s important to note that for some applications, you will need to create the associated HKCU\Classes key for the application. This of course, can also be actioned with WEM by creating a registry action (Thanks Munro for the nudge)
Standard WEM assignment process for User 1:
And a second assignment for User 2:
Below you can see the results in action. This is the same server with the 2 different user sessions active Left hand side has User2’s association set, and right hand side has user 1’s association set:
And what happens if you accidentally add someone to two methods of association?…last write wins :)
Hats off to you Mr Kolbicz, well played.
