I have been working on some unattended installation scripts for applications to be deployed through an SCCM OSD task sequence that builds our Windows 10 workstations. Happily, many of the lessons learned with Windows 7 are directly applicable to Windows 10. However, Windows 10 has made a significant change to the way applications are able to set themselves as the default application for handling certain file types.

Recently, I’ve been working on migrating our Adobe Acrobat XI package from Windows 7 to Windows 10. Among the first things we noticed was that in Windows 10, Microsoft Edge remained the default handler for the .PDF file extension, even though we had configured Acrobat to be the default handler through the Adobe Customization Wizard. This discovery led to much investigation about the changes in Windows 10 that are purportedly intended to protect a user’s choice of applications. I’m not altogether sold on this as a way of protecting user choice, as it seems more like it’s trying to force users into using the application of Microsoft’s choice rather than the one the user has installed.

A good technical explanation of the changes to the registry employed by Windows 8 and later to protect certain file extensions can be found in this post: http://appsensebigot.blogspot.co.uk/2015/10/deploying-per-user-file-type.html. To quickly summarize, since Windows 7, Microsoft has added a new registry subkey, named “UserChoice”, to certain file extensions under HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FileExts, and the contents of the UserChoice subkey dictate the default application for opening the file type. The contents of the UserChoice subkey are protected from modification by a Deny permission applied to the current user’s account. Unfortunately, the workaround for Windows 8/Server 2012 R2 described in the post does not seem to work in Windows 10.

Let’s use Regedit to look at the registry entries for the .PDF file extension at HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.pdf. Out of the box, Windows 10 will set the contents of the UserChoice subkey to have the Progid value point to Microsoft Edge, referenced by its Windows application ID. The Hash value will contain a data that seems to be generated from the current user’s username, the computer name and the application, meaning that it will be unique for each user/computer/application combination. Thus, it would be difficult, and foolish, to try to calculate that value ourselves. You’ll also notice that you cannot change the data of the Progid or Hash values through Regedit. If you right-click the .pdf key and choose Permissions, you’ll see that the current user has special permissions assigned. Clicking on the Advanced button will show you that the current user is prevented from setting values under the UserChoice key by way of a Deny permission entry.

All of this makes things look pretty bleak.

But Microsoft has not forgotten about us system administrators. They have provided a way forward!

The best description I’ve found of Microsoft’s horrible, short-sighted method for system administrators to get around the UserChoice keys and set default application file associations can be found at this TechNet blog post: 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. There are many reasons why this method is unusable, but a very obvious one is that it isn’t graceful for deploying different combinations of default applications to different users. It’s completely unwieldy for configuring a multi-user XenApp server where users may have different default applications for the same file extension. It’s also clunky when it comes time to deploy a new version of an application that has been previously configured, as we would need to know which other extensions have been configured for that computer in the past before we change the handler to new application. Read the comments if you are curious about how your fellow sysadmins feel about this method.

A better method would avoid these problems and enable us to configure default applications per-user. So let’s engineer something.

The first thing we need to do is somehow deal with that UserChoice key. While we are not able to change the values under the key, the permissions allow us to delete the UserChoice key itself, with a catch. The catch is that we can’t use a simple REG DELETE command to delete the UserChoice key as it returns an “ERROR: Access is denied.” response. Trying REG DELETE against the parent subkey, .pdf, will delete everything except for the UserChoice key. Watching this process with Sysinternals Process Monitor shows that reg.exe tries to open the UserChoice key while requesting “All access”, which it won’t receive. But we can use REG IMPORT to import a .REG file that deletes the key. So far, it appears that deleting the key one time prevents it from returning at subsequent logons, so long as you have a local Windows profile to log on to. If you are using a mandatory profile, I expect that the key will be created at each logon and you’ll need to delete it at each logon.

I have found that when the UserChoice key is absent, the settings under the file type key are honored.

Once we’ve dealt with that UserChoice key, setting the remaining registry values under the extension key that configure the default application is straight-forward and familiar.

An example of the registry method for Adobe Acrobat Pro DC

By way of example, below is a .REG file that I am using to configure Adobe Acrobat Pro DC (also known as Acrobat 2015) as the default application for .PDF files. This file will delete the entire .pdf subkey to get rid of the UserChoice key and any other values that would set Microsoft Edge to be the default handler and then configure the values under the OpenWithList and OpenWithProgids keys to make Acrobat Pro DC the default handler.

Windows Registry Editor Version 5.00

;Delete the .pdf key under FileExts to clear the Microsoft Edge application association (which is the default handler for .pdf) and the UserChoice subkey.
[-HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.pdf]

;Configure the .pdf key under FileExts to set Acrobat as the default handler.
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.pdf]

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.pdf\OpenWithList]
"a"="Acrobat.exe"
"MRUList"="a"

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.pdf\OpenWithProgids]
"Acrobat.Document.2015"=hex(0):

One way of deploying these settings would be to drop this .REG file onto the computer or a share on your network, then create a GPP Registry item, set to “Apply once and do not reapply”, that creates a value under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce to launch the command C:\Windows\System32\reg.exe IMPORT <path-to-REG-file>. At the user’s next logon, the RunOnce key will cause reg.exe to import the .REG file that deletes the UserChoice key and configures the default application. A nice advantage to using using the GPP Registry item is that it can be item-level targeted to a situation, for example, to an AD security group of users or to users logged onto computers with a certain application installed.

In my experience, the end result is that the user sees the correct Adobe Acrobat icon for .PDF files and double-clicking a .PDF file launches it in Adobe Acrobat without any prompting to set Acrobat as the default application for opening PDFs.

This Windows Event Viewer query looks through the Network Profile/Operational log for network connection events (EventID=10000) where the “Category” equals “2”, which equates to “Domain Authenticated”. The neat part about this XML query is that it looks into the event details for additional criteria, which isn’t available through the filter GUI.

<QueryList>
  <Query Id="0" Path="Microsoft-Windows-NetworkProfile/Operational">
    <Select Path="Microsoft-Windows-NetworkProfile/Operational">*[System[(EventID=10000)]] and *[EventData[Data[@Name='Category'] and (Data='2')]]</Select>
  </Query>
</QueryList>

I use it as the custom query trigger for a scheduled task that initiates a few actions each time the computer is powered on/woken up while on the domain network, or has its network connection reestablished. A similar query without the Category=2 criteria would be triggered twice each time the computer is powered on: once when the network connection is established but on the public firewall profile (or something like that), and a second time when the connection changes to use the domain firewall profile (again, I’m not exactly clear).

For a good explanation of how to construct custom queries with examples, see the TechNet blog post at Advanced XML filtering in the Windows Event Viewer.