How to Set Default File Associations with Group Policy on Windows 10 and 11

If you have ever tried to set the default PDF reader, browser, or image viewer across a Windows domain, you will know that the obvious approaches do not work. Editing the registry directly does nothing. Group Policy Preferences quietly fails. Users end up with whatever they clicked last, and you end up visiting desks.

There is a supported way to do it, and once it is set up it is reliable. This guide walks through deploying default file associations with Group Policy on Windows 10 and Windows 11.

Why the registry approach does not work

Since Windows 8, the per-user file association is protected by a hash. When a user picks an application from the “Open with” dialog, Windows writes the choice to:

HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.pdf\UserChoice

alongside a hash calculated from the user’s SID, the extension, the ProgId, and a timestamp. If you write a new ProgId into that key without a matching hash, Windows detects the tampering and resets the association. This is deliberate, and it exists to stop software silently hijacking file types during installation.

Group Policy Preferences under Folder Options has an “Open With” item, but it writes the legacy association only. Modern Windows ignores it when deciding the actual default. It looks like it worked in the GPO, and nothing changes on the desktop.

The supported method: a default associations configuration file

Microsoft’s answer is an XML file, referenced by a Group Policy setting, that Windows reads at every user logon. The policy lives here:

Computer Configuration
  > Administrative Templates
    > Windows Components
      > File Explorer
        > Set a default associations configuration file

Set it to Enabled and give it the path to your XML file. Note that this is a Computer Configuration setting. There is no User Configuration equivalent, so the scope is “every user who signs in to these PCs” rather than “these users wherever they sign in”.

Step 1: Find the correct ProgId

Do not guess the ProgId. They vary between application versions, and a wrong value means the policy applies but nothing opens. Set the association manually on one reference PC, then read it back:

Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.pdf\UserChoice' | Select-Object ProgId

Alternatively, export the full set of associations from that machine:

Dism /Online /Export-DefaultAppAssociations:C:\temp\assoc.xml

You can check that the ProgId resolves to the application you expect:

Get-ItemProperty "HKLM:\SOFTWARE\Classes\AcroExch.Document.DC\shell\open\command" | Select-Object '(default)'

Step 2: Build the XML file

Include only the extensions you actually want to control. Anything you leave out is untouched, so you can set the default PDF viewer without disturbing anyone’s choice of web browser:

<?xml version="1.0" encoding="UTF-8"?>
<DefaultAssociations>
  <Association Identifier=".pdf" ProgId="AcroExch.Document.DC" ApplicationName="Adobe Acrobat Reader" />
</DefaultAssociations>

To point PDFs at the Microsoft Edge built-in viewer instead, the ProgId is MSEdgePDF. For other common types, export from a reference machine rather than working from memory.

Step 3: Publish the file somewhere every PC can read

\\server-name\published-files\DefaultAssoc.xml

A read-only share works too, but the computer accounts need read access, not just the users.

Step 4: Link the GPO and apply it

Link the policy to the OU containing your workstation computer objects. Two refreshes are involved:

1. A computer policy refresh writes the pointer to the XML. Run gpupdate /force, reboot, or wait for the standard refresh cycle.
2. The user then signs out and signs back in. The XML is processed at logon, and the new default is live.

A full reboot is not required. A sign out is enough, provided the computer policy has already landed. Verify on a test machine after logon by reading the UserChoice key back.

Worth knowing

Windows only reprocesses the file when it changes

If the XML content is identical to what was applied last time, Windows skips it. When testing, change something real, or add a comment line so the file genuinely differs.

Unlinking the GPO does not revert anything

Removing the policy stops it enforcing, but it does not restore the previous association. Everyone stays on whatever the policy last set. To roll back, edit the XML to point at the original application and let it apply again, then unlink once you have confirmed every machine has been through a logon.

Per-user targeting is not supported

Because the setting is machine scoped, you cannot vary it by user through Group Policy alone. Loopback processing does not help, as it applies user settings based on the computer rather than the reverse. The practical options are to target by computer using separate OUs or security filtering on computer accounts, or to use Dism /Online /Set-DefaultAppAssociations during imaging to seed defaults for profiles that do not yet exist.

Third party tools exist that calculate the UserChoice hash and can be run from a logon script. They work, but they depend on an undocumented algorithm that a Windows update can change at any time, at which point they stop working without any obvious error. We avoid them on for that reason.

Test on a pilot group first

File associations are one of those changes that looks trivial and turns out not to be. A PDF viewer swap that saves licensing and patching effort can still fail because a handful of people rely on a feature the replacement does not have. Pick two or three PCs, live with it for a week, and ask the users before you push it to everyone.

Need a hand with this?

AGGIA IT provides IT support in Bicester, Oxford and across Oxfordshire for small businesses, typically between 5 and 50 users.

If you are dealing with Group Policy, Windows deployment, Microsoft 365 or anything else on your network and would rather it was someone else’s problem, get in touch.