AVD – Mailto File Association Not Persisting After Reboot

Hi Cleon Russell,

The issue your customer is encountering stems from a built-in Windows security feature designed to prevent unauthorized programs from hijacking file associations. Windows generates a unique cryptographic hash for protocol handlers like MAILTO, which is stored in the registry at HKCU\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\mailto\UserChoice. Because this hash is partially tied to the specific hardware or OS instance, an FSLogix profile roaming that registry key to a different AVD session host will fail the hash validation. When Windows detects this mismatch, it automatically reverts the MAILTO association to the system default to protect the user environment.

To resolve this reliably in a multi-session environment, you must move away from roaming user-level associations and instead enforce them at the computer level. This is achieved by creating a default association configuration file. You can generate this XML by manually setting Outlook as the default on a reference host and running the DISM /Online /Export-DefaultAppAssociations command. Once generated, place this XML file on a central network share where all AVD hosts have read access.

Finally, you must apply this configuration using the Group Policy setting located at Computer Configuration > Administrative Templates > Windows Components > File Explorer > Set a default associations configuration file. Enter the UNC path to your XML file in the policy setting. This approach ensures that every time a user logs into any AVD host, the MAILTO protocol is mapped to Outlook before the UserChoice hash check can trigger a reset. This method is the Microsoft-recommended standard for non-persistent environments and effectively bypasses the profile-roaming conflicts inherent in FSLogix.

Hope this answer brought you some useful information. If it did, please hit “accept answer”. Should you have any questions, feel free to leave a comment.

VP