Setting Default Apps and File Associations at Scale: the XML That Works, and the Per-User Hash That Defeats Scripting

Someone opens a ticket that reads like a five-minute job. "Please make Adobe Acrobat the default for PDF files on all machines." You have done harder things before breakfast. So you write six lines of PowerShell that set a registry value, you push it, and by the next morning every affected user has a toast in their Action Center that says An app default was reset. Every PDF still opens in Edge. Your script ran successfully. Windows just undid it.

This is not a bug and it is not a permissions problem. Windows deliberately guards the user's choice of default app with a per-user cryptographic hash, and it re-validates that hash every time a user signs in. If the hash does not match what Windows expects, Windows concludes that something tampered with the setting and reverts to its own default. That single design decision is why "set the default PDF handler" is one of the most-asked and least-understood questions in Windows endpoint management. This post walks the whole model from the ground up: what an association actually is, where every piece of it lives, why the hash exists, the supported way to set defaults at scale, and the difference between setting a default once and enforcing it forever.

The problem: the script runs, and Windows undoes it

Let us be precise about the failure, because the symptom is easy to misread.

You want .pdf files to open in Acrobat. You go looking for where that setting lives. You find it quickly, because it is not hidden. It sits in the current user's registry hive, one key per extension, and it holds the name of the program that handles that extension. You write that value. Nothing errors. You sign the user out and back in.

Three things then happen, in this order. First, the association reverts to whatever Windows thinks the default should be. Second, the user gets a notification saying an app default was reset. Third, an event is written to a log channel almost nobody looks at, recording precisely what happened and why.

The important detail is that nothing failed. Your write succeeded. Windows read the value back, ran a check on it, decided the value had not been set by the user through the proper user interface, and rolled it back. Microsoft documented this behaviour in support article KB4001770 as "Reset app default when a registry setting is deleted or corrupted and streamlined notification about the corruption."

That wording is worth reading twice. From Windows' point of view, your hand-written registry value is not a configuration change. It is corruption.

Why it happens: the association model and the hash that guards it

To fix this properly you need the whole model, not just the one key. There are four layers, and they are consulted in a specific order.

Layer 1: the ProgId, which is the name of a handler

A ProgId (programmatic identifier) is a short string that names a way of opening a file. AcroExch.Document.DC is a ProgId. So is ChromeHTML, and so is MSEdgeHTM. Modern Store-packaged apps get machine-generated ProgIds that look like AppX4ztfk9wxr86nxmzzq47px0nh0e58b8fw, which is why the Notepad handler in your registry looks like line noise.

ProgIds are registered under HKEY_CLASSES_ROOT. That subtree is not a real hive. Microsoft documents it as "a view formed by merging HKEY_CURRENT_USER\Software\Classes and HKEY_LOCAL_MACHINE\Software\Classes". Machine-wide registrations go in the HKLM half; per-user registrations go in the HKCU half. Microsoft also states plainly that "in general, HKEY_CLASSES_ROOT is intended to be read from but not written to".

Under the ProgId you find the friendly name in the key's default value, and the actual command line under shell\open\command. That command line is what finally launches when someone double-clicks a file.

Layer 2: the extension key, which is the machine's opinion

Each file extension gets its own key directly under HKEY_CLASSES_ROOT, including the leading period. Its default value holds a ProgId. Microsoft's file types documentation gives the shape as extension=ProgID and adds an important caveat: "Windows respects the Default value only if the ProgID found there is a registered ProgID. If the ProgID is unregistered, it is ignored."

Beside that default value sits a subkey called OpenWithProgids. Microsoft describes it as "a list of alternate ProgIDs for this file type. The programs for these ProgIDs appear in the Open with menu". Applications are supposed to add themselves to this list rather than seize the default. This is the polite, supported way for an app to say "I can also open these".

Layer 3: UserChoice, which is the user's opinion and it wins

Here is the layer that matters. When a user picks a default through Settings, Windows writes it to a per-user key, and that key overrides everything in layer 2.

For file extensions the parent key is:

For URL protocols such as http or mailto it is a different tree entirely, which is the single most common reason a "default browser" script only half works:

Both of those keys carry exactly two values that matter. ProgId names the handler. Hash is a short base64 string that proves the ProgId was written by the shell on behalf of the signed-in user, on this machine, for this extension.

Layer 4: the hash check at sign-in

At each sign-in the shell walks the UserChoice keys and recomputes the expected hash for every one of them. If a stored hash does not match the computed hash, the entry is treated as tampered. Windows resets that association and, depending on the situation, shows the user a notification.

The algorithm that produces the hash is not documented by Microsoft. There is no supported API, no cmdlet, and no published specification for generating a valid hash for an arbitrary ProgId. Community projects have reverse-engineered it, and they generally work, but you are then depending on undocumented behaviour that Microsoft is free to change in any monthly update. Do not build an enterprise standard on it.

The COM interface that used to do this job tells the same story in Microsoft's own words. IApplicationAssociationRegistration::SetAppAsDefault is documented as setting an application as default "provided that the application's publisher matches the current default's", returning E_ACCESSDENIED when it does not, and is flagged in the documentation as "Not intended for use in Windows 8." The programmatic door was closed a long time ago and clearly labelled.

The chain, end to end

Put together, a double-click resolves like this.

1. Explorer takes the file's extension, for example .pdf.
2. It looks for a UserChoice key for that extension in the current user's hive.
3. If one exists, the shell validates the Hash value against the ProgId value.
4. If the hash is valid, the ProgId in UserChoice wins and nothing else is consulted.
5. If the hash is invalid or missing, the entry is discarded, an event is logged, and the association falls back to the machine-level default.
6. With no UserChoice at all, the default value of the HKEY_CLASSES_ROOT\.pdf key decides, provided that ProgId is registered.
7. The winning ProgId's shell\open\command is executed with the file path.

Registry reference for the whole feature area

These are the keys and values involved in file and protocol associations, machine and user. Paths are shown relative to the roots named in each row.

System files and binaries in the flow

How to verify: read the four places that decide

Before changing anything, establish what the device currently believes. There are four sources of truth and they can disagree.

1. Read the live UserChoice values with PowerShell

This reads the per-user default for a handful of extensions and protocols, and reports whether a Hash value exists beside each ProgId. Run it as the signed-in user, not as an elevated different account, because UserChoice is per user.

Protocols live somewhere else, so check them separately. Forgetting this is why half-working default-browser scripts are so common.

2. Look at the keys in Registry Editor

Sometimes you just want to see it. Open Registry Editor and paste the path into the address bar.

3. Ask DISM what the image thinks

DISM reads and writes the image-level association list, which is a different thing from the user's live choice. Both commands below are read-only.

4. Read the AppDefaults event channel

There is a dedicated channel for exactly this feature, and almost nobody knows it exists. Microsoft's own guidance points at it: "You can check the Microsoft-Windows-Shell-Core/AppDefaults event log for clues about file associations reset."

The event identifiers below were read from the Microsoft-Windows-Shell-Core provider's own manifest on a Windows 11 25H2 device, using Get-WinEvent -ListProvider. The strings are Microsoft's, shipped in shsvcs.dll. Microsoft does not publish this table on learn.microsoft.com, so treat the numbers as version-specific and re-read the manifest on your own build before you write an alert rule against them.

Log files

Association handling itself is event-driven rather than file-logged, but DISM keeps a text log, and that is where an XML import failure shows up.

The fix: export the XML, then choose once or enforced

The supported route has three steps: build a reference device, export an XML from it, and then decide how that XML reaches your fleet. The third step is where most projects go wrong, because the two delivery mechanisms behave completely differently.

Step 1: set the defaults on a reference device, through the UI

Install the applications you care about on a clean device of the same Windows version as your fleet. Then set the defaults by hand, in Settings. This is the one place where clicking through the UI is not a shortcut but the actual requirement, because only the UI produces valid hashes.

Two traps here, both documented by Microsoft. First, on a brand-new reference machine the exported XML "may be truncated until the delay-install apps have fully installed", so wait 10 to 30 minutes and open the inbox apps before exporting. Second, if only one application on the device can handle a type, "that application will appear as the default for that type, even though there is no explicit choice in the registry", and "exporting the default applications to XML will not gather these implied settings". To capture an implied default you must select it explicitly, even though the UI already shows it.

Step 2: export the XML with DISM

Run this as the same user account that set the defaults in step 1. Microsoft is explicit that using a different account produces a malformed file.

The result is a flat list of Association elements. Each carries an Identifier (the extension or protocol), a ProgId, and a human-readable ApplicationName.

Step 3a: one-time defaults, by importing into the image

If you want to hand users a sensible starting point and then leave them alone, import the XML into the image. Microsoft's description of the switch is the whole story: "Imports a set of default application associations to a specified Windows image from an .xml file. The default application associations will be applied for each user during their first logon."

Step 3b: enforced defaults, by policy

If you need the association to come back after a user changes it, you need the policy. The setting is Set a default associations configuration file, it takes a path to the XML, and the shipped administrative template describes its behaviour precisely: "If this group policy is enabled and the client machine is domain-joined, the file will be processed and default associations will be applied at logon time." It then adds the sentence that answers the question everyone asks: "If the policy is enabled, users will still be able to override default file type and protocol associations, but on next logon the file will be reapplied."

Group Policy walkthrough

1. Copy your association XML to a location every device can reach. A read-only UNC path such as \\contoso-fs01\NETLOGON\AppAssoc.xml works, and so does a local path you stage with the same package that installs the applications.
2. Open the Group Policy Management Editor on a GPO linked to the target computers. This is a Computer Configuration policy, so linking it to a user OU will do nothing.
3. Navigate to Computer Configuration > Administrative Templates > Windows Components > File Explorer.
4. Open Set a default associations configuration file and select Enabled.
5. In Default Associations Configuration File, enter the full path to the XML. This is a path, not the XML content.
6. Click OK, then confirm on a test device with gpupdate /force followed by a full sign-out and sign-in. A gpupdate alone will not reapply associations, because the work happens at logon.
7. While you are in the same node, consider enabling Do not show the 'new application installed' notification to suppress the toast that fires when an installer registers a new handler.

Intune walkthrough

There are two ways to deliver this from Intune, and they take different input.

1. Go to Devices > Configuration > Create > New policy, platform Windows 10 and later, profile type Settings catalog.
2. In the settings picker, search for Default Associations Configuration. The setting sits under the Administrative Templates > Windows Components > File Explorer category, mirroring the GPO, and under Application Defaults for the CSP-backed form.
3. Enable the setting and supply its value. For the administrative-template form this is the path to the XML, exactly as in Group Policy.
4. Assign to a device group. This node is device-scoped: Microsoft documents the CSP scope as Device, not User.
5. For the CSP form, create a Custom profile instead and add an OMA-URI setting. The node is ./Device/Vendor/MSFT/Policy/Config/ApplicationDefaults/DefaultAssociationsConfiguration, data type String.
6. The CSP data is base64-encoded XML content, not a path. Microsoft's instruction is unambiguous: "The file then needs to be base64 encoded before being added to SyncML." Encode the whole file, paste the result as the value.
7. Sync a pilot device, sign out and sign in, and verify with the companion script below.

What happens to a user who tries to change it

Nothing stops them. The Settings UI still works, the change writes a valid hash, and files open in their chosen app for the rest of the session and every session until they sign out. At the next sign-in the policy XML is processed again and their choice is replaced for any identifier the XML names. Identifiers the XML does not name are left alone permanently.

If you want a default that is a strong suggestion rather than a monthly argument, that is what the Suggested attribute is for. Microsoft documents it as: "The default value is false. If it's false, the Association is applied on every sign-in. If it's true, the Association is only applied once for the current DefaultAssociations Version." Increment the Version attribute on the root element and the suggested entries apply once more, on the next sign-in. Those two attributes arrived in Windows 11, version 22H2.

Proof it worked: real output from a live device

The companion script is Get-FileAssociationState.ps1. It reads the policy value, resolves and parses the XML if one is in force, reads every relevant UserChoice key, resolves each ProgId to its friendly name, counts recent AppDefaults events, and flags any identifier where the policy and the live value disagree. It writes nothing. It never sets a UserChoice value and never calls a DISM import or remove verb. It needs no PowerShell module and runs on both Windows PowerShell 5.1 and PowerShell 7.

The output below is a genuine run on a Windows 11 25H2 device with identifiers replaced. This device has no association policy applied, which is the baseline you should expect before you deploy anything.

Now the interesting run. Passing -PolicyXmlPath compares the live values against a candidate XML without deploying it, which is how you test an XML before it reaches users. This XML asks for Edge on .htm, .html, http and https, while the device is set to Chrome.

Read the verdicts like this. Match means the policy applied and the user has not fought it. Drift means either the user changed the default since their last sign-in, or the policy never reached them at all. NotInPolicy means you deliberately left that type to the user. NoUserChoice means nobody ever chose, which is normal and often means only one handler exists.

Two follow-ups turn a Drift into a diagnosis. Check the AppDefaults channel for events 62440 and 62444 on that device: if they are present, something is writing UserChoice values directly and you have an application problem, not a policy problem. If they are absent and the drift is on every identifier, the policy is not being processed, so check the join state, the XML path reachability from the user's context, and whether the device has actually had a fresh sign-in since the policy landed.

Community deep dives

References

• Export or Import Default Application Associations - Microsoft Learn. The export and import procedure, plus the four tips on truncated exports, implied defaults and upgrade behaviour.
• DISM Default Application Association Servicing Command-Line Options - Microsoft Learn. Exact syntax for the four switches, and the statement that imported associations apply at each user's first logon.
• ApplicationDefaults Policy CSP - Microsoft Learn. The OMA-URI, the base64 requirement, the Version and Suggested attributes, and the Group Policy mapping including the registry key name.
• File Types - Microsoft Learn. The HKEY_CLASSES_ROOT registration model, OpenWithProgids, and the merged-view behaviour of HKCR.
• IApplicationAssociationRegistration::SetAppAsDefault - Microsoft Learn. The publisher-match requirement, E_ACCESSDENIED, and "Not intended for use in Windows 8."
• Windows 10 - How to configure file associations for IT Pros? - Microsoft Learn archive. The tamper-detection rationale, the AppDefaults event channel, and the two-file technique for forcing a subset.
• Change default programs in Windows - Microsoft Support. The per-extension and per-app routes in the Windows 11 Settings app.
• Updates to Windows for the Digital Markets Act - Windows Insider Blog. The exact list of link and file types the browser Set default button covers in the EEA.
• Local sources verified on the device used for this article: C:\Windows\PolicyDefinitions\WindowsExplorer.admx and its en-US ADML for the policy key, value name and behaviour text, and Get-WinEvent -ListProvider Microsoft-Windows-Shell-Core for the AppDefaults event manifest.