File associations in Windows 8.1 for applications on a network location

Hi,

From Windows 7 to Windows 8 it has been done alot of changes regarding file file assocations. It seem that the main reason was security and was "patched" by having Windows read the hash for the applications instead of where the application was located.

but there seem to be some major hicups and there is limited info on the web covering these issues.

First issue: when running:  Dism /Online /Export-DefaultAppAssociations:\\Server\Share\AppAssoc.xml and then creating a GPO configuration pointing to thi XML file.  With this feature only common file extensions is supported and when users are changing to another computer, these settings is not possible to syncronize using roaming profiles.

Second issue: In the appassoc.xml file applications must be either appid(metro app) or common application on local harddrive to be registered and not a .EXE file on a network location.

It seems a little strange if this is the case and if there is no other options for administratos to set file associations in more flexible ways. Does anyone have some more info on this topic other than these link:

https://technet.microsoft.com/en-us/library/hh825038.aspx?f=255&MSPPError=-2147217396

http://blogs.technet.com/b/mrmlcgn/archive/2013/02/26/windows-8-associate-a-file-type-or-protocol-with-a-specific-app-using-a-gpo-e-g-default-mail-client-for-mailto-protocol.aspx

https://keithga.wordpress.com/2013/11/13/file-associations-in-windows-8/

March 22nd, 2015 1:39pm

I have seen this some time ago, and i can tell you if you are planning to put some associations like .log point to smstrace etc, it's not going to work.

 
Free Windows Admin Tool Kit Click here and download it now
March 22nd, 2015 3:25pm

Hi Primeid,

I tested all issues you mentioned and find that when you import this xml file, it only modified the default user profile.  So any users that already existed before the DISM command was executed will continue to have the associations that were created in the image. That is also reason why these settings is not possible to syncronized by using roaming profiles.

For your second issue, the network path wont be shown in XML file, it is shown like a local application as following.

As you mentioned that Windows read the hash for the applications instead of where the application was located, modify registry entry by using group policy is not an option which is a security consideration.

Regards

D. Wu

March 26th, 2015 4:22am

Hi Primeid,

I tested all issues you mentioned and find that when you import this xml file, it only modified the default user profile.  So any users that already existed before the DISM command was executed will continue to have the associations that were created in the image. That is also reason why these settings is not possible to syncronized by using roaming profiles.

For your second issue, the network path wont be shown in XML file, it is shown like a local application as following.

As you mentioned that Windows read the hash for the applications instead of where the application was located, modify registry entry by using group policy is not an option which is a security consideration.

Regards

Free Windows Admin Tool Kit Click here and download it now
March 26th, 2015 10:25am

Hi Primeid,

You could use Group policy for file associations or you could deploy the xml file during image deployment. However as you mentioned that the file associations only applies to common application on local hard drive or metro app.

http://blogs.technet.com/b/mniehaus/archive/2014/01/10/configuring-file-associations-in-windows-8-1.aspx

http://blogs.technet.com/b/mrmlcgn/archive/2013/02/26/windows-8-associate-a-file-type-or-protocol-with-a-specific-app-using-a-gpo-e-g-default-mail-client-for-mailto-protocol.aspx

We understand your confusion about this, but we hope you understand that using network location for file association deployment is highly insecure and it is out of our recommendation since the content in that network location could be changed without any notification or permissions constraint.

Thanks for your understanding.

Regards

D. Wu

March 29th, 2015 10:22pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics