Enable application setups to change file type associations

by | Feb 26, 2021 | Technology | 0 comments

This article is contributed. See the original author and article here.

Tested with Windows 10 1609 up to 20H2


 


Hey community, this is Helmut Wagensonner, a Customer Engineer for Windows Client platform. Today I show you a way to make file type associations more enterprise ready.


 


I heard many of my customers complaining that it’s no longer possible to assign file types programmatically to an application (i.e. during the installation of an application). An example: You install Adobe Reader as your desired default PDF reader in your environment. Former, the Adobe Reader setup was able to register itself as default handler for all .PDF files. With Windows 10 this has changed. Applications can add themselves as an optional file handler, but it is no longer possible to programmatically change the default file handler for a certain file type. The final decision of which app opens which file type needs to be made by the user. On one hand this can prevent malicious software from inadvertently registering themselves as a default file handler but on the other hand it can cause inconvenience in Enterprises.


 


But we didn’t forget about enterprises and added an option to Windows 10 to manage file type associations (FTAs) in an administrative way. In fact, there are two options.


 


You can create an XML file containing the desired FTA’s and import it using DISM. Those settings are applied during the user profile creation process and allows users to change the settings afterwards. However, this method does not work for existing user profiles. You can find more details here: https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/export-or-import-default-application-associations


 


The second option is to apply this XML file using a Group Policy setting. In this case also existing user profiles are affected from the settings within the XML. That’s pretty much what we need. The only thing remaining is to provide a way for application setups to change this XML file. And this is where this blog post and the attached script can help.


 


The script I’m providing here adds a bit of dynamics to the file type associations. It supports adding, removing and updating values in the XML file. Here are more details and quick instructions.


 


Prepare your environment



  • Your clients need to be joined to an Active Directory, where GPOs can be applied to computers.

  • Create an empty default file type association XML, which should look like this:

    <?xml version="1.0" encoding="UTF-8"?>
<DefaultAssociations>
</DefaultAssociations>​


    You can also use a predefined XML, which works with your standard client. In that case make sure that your configuration file only contains extensions you want to modify. You will find examples of how to create association XMLs
    <https://docs.microsoft.com/de-de/archive/blogs/windowsinternals/windows-10-how-to-configure-file-associations-for-it-pros> here.


  • Use your preferred deployment method to push the configuration file to your clients or add it to your master image. Select a local folder, which is readable but not changeable for users. The C:ProgramDataYourCompany folder would be a good place.
    Note: This solution does not work if your configuration XML file is located on an UNC path. It must be stored locally.

  • Create a GPO which affects all Windows 10 clients and change the setting as shown in the picture. Point the path to the location, where you copied your XML file in the step before.
    Bild1.png

  • Add the script provided in this blog post to your desired software installations. You find examples of how to use the script further down the page.


 


Add script to application deployments


Let’s assume you deploy a video player application, which handles the “.AVI” files. You want the application setup to change the default app for .AVI to this application. To accomplish this, simply run the Powershell script attached to this article after or during the application’s setup, i.e. as a custom action or a script that is triggered in your install.cmd/.ps1).


 


The following command modifies the local application association XML file. It changes .AVI to the new AppId or adds a new line, if AVI is not yet assigned in the configuration file.


 

Modify-AppAssocXml.ps1 -Path "C:ProgramDataYourCompanyAppAssoc.xml" -Extension ".avi" -ProgId "VLC.avi" -AppName "VLC Media Player"

 


Please note that it requires GPO foreground processing for the settings to take effect. This means that users need to log off/on after the FTA XML has changed.


 


Command line options


Path is straightforward. It’s the path to your local FTA config file.
Extension is the file type(s) you want to modify or set. You can either specify a single extension or multiple extensions, separated by comma (i.e. “.avi,.mp4,.mpeg”).
ProgID is the path to the application’s ProgId registry key without HKEY_CLASSES_ROOT. Most times this is the path to the open handler in the registry, relative from HKEY_CLASSES_ROOT to the key name before ShellOpenCommand. An Example: The open handler for “notepad.exe” can be found in HKEY_CLASSES_ROOTApplicationsnotepad.exeshellopencommand. The ProgID for Notepad would be Applicationsnotepad.exe.
AppName is the file description property of the corresponding EXE file. However, this value does not affect the file type association, but it must be set.


 


Verification and troubleshooting


After running the script and logging off/on the user, you can check the registry for verification. If you changed, for example, the assignment for .AVI files, you should find a registry value HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionExplorerFileExts.aviUserChoiceProgId. The data of this value should be the same as the ProgId specified in your XML. And of course .AVI files should open with the application you assigned it to. If this is not the case, check the event log Microsoft-Windows-Shell-Core/AppDefaults for errors.


 


 

Disclaimer
The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.

 


 

Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.

Submit a Comment