Fixing default file type associations in Windows 10 – Login VSI Tips & Tricks
Welcome to the first Tips & Tricks article! We’re reviewing the most common questions asked of our support engineers, and forum posts, and providing these articles to make deploying, managing, and testing VDI easier. Today we are explaining how to fix default type associations in Windows 10.
Update July 28, 2016:
Specifically, relevant to those running stateless desktops, or those experiencing issues with the .XML import method failing.
A file at %windir%System32 called “OEMDefaultAssociations.xml” will set the defaults for the OS before the explorer loads, and policies process.
We recommend that this file is backed up before modified. Reference.
Below you will find the steps to implement the workaround:
- Open/load the golden image to edit it; the one intended for use of testing by Login VSI
- Edit the FTAs in the golden image to what you want them to be (for example, setting the .pdf FTA to Adobe Reader)
- Navigate to %systemroot%system32 and locate the OEMDefaultAssociations.xml file. Make a backup of it just in case.
- Open the original OEMDefaultAssociations.xml file and keep it open.
- Run the DISM command in PowerShell, exporting the output to xml (let’s call this appassoc.xml)
- Open appassoc.xml with Notepad
- Copy the entire contents of appassoc.xml and replace the content of OEMDefaultAssociations.xml
- Save OEMDefaultAssociations.xml
- Do a sanity check that this process worked by opening a .pdf directly from the Login VSI and ensuring it opens with Adobe
- Save the golden image and do whatever you have to do to push this updated image down to Login VSI testing in your infrastructure
The default workloads in Login VSI includes launching and using Adobe Reader as part of its user simulation. Because Login VSI doesn’t know which version of Adobe Reader is installed, or where it’s installed, the workload relies on the file type association (fta) for .pdf documents to be associated with Adobe Reader.
The Login VSI workloads just send a command to open [somefile].pdf and then wait for Adobe Reader to become active. This method has worked great… until the recent versions of Windows. In Windows 10 the fta for .pdf defaults to the Microsoft Edge browser and breaks the default Login VSI workloads.
You could go in and manually change the fta for each user but that’s going to take a lot of time, especially if you have hundreds of Login VSI virtual users to repeat it for.
The preferred method then, is to create a Group Policy (GPO) setting and apply it to the Login VSI user OU. Starting in Windows 8, the default fta settings include not just the app to open with, but a hash to prevent malicious apps for getting swapped in and launched. The new process is to export the correct fta’s from a system, then apply those settings in a GPO.
The first step is to export the correct fta’s from a properly configured machine. This is done with the DISM command. Here’s an example of the command, and the resultant XML:
More information on this command can be found here.
You don’t need to include all the fta’s, you can edit this file to just the ones you need, in our case, just the .pdf viewer.
Once you have this fta config file, you create a new GPO and link the XML file to it. You’ll want to copy it to a location accessible from a DC:
Once you’ve set the GPO, delete the existing user profiles for Login VSI users, otherwise their personal settings will overwrite these machine settings.
Then run a Login VSI test with the ProfileCreate checkbox enabled. This will log in each user and use these settings as the basis for the per user settings, using the fta’s that are in the XML file.
Thanks to Jeff, Josh, Omar, Brian, Josh and Jasper from Login VSI support for their contributions and review of this article. The following references were used to create this article: