Windows10 1909 Upgrade - An App Default Was Reset

Question

My org is using WIn10 Pro (volume license) build 1809. We want to upgrade to 1909. We use PDQ Deploy to download the install.wim and run this command to install:
start /wait c:\UpgradeInstall\1903\setup.exe /auto upgrade /Compat IgnoreWarning /installfrom c:\UpgradeInstall\1903\sources\install.wim /dynamicupdate enable /showoobe none /quiet

As a background we use a default associations configuration file (we've named to win10-default-associations.xml) which is applied via GPO.

After the windows upgrade when a user logs in they are assaulted with a flurry of about 15-30-ish messages that a app default was reset. And the default apps are all reset generally to MS products, PDF's are switched from adobe to edge, etc. There have been a number of exports done with DISM and in all manner of testing the upgrade to either 1903 or 1909. This is holding up my beta testing of 1909. Does anyone have any info or a solution?

I've been following this thread, in which by word of mouth supposedly there is supposed to be a fix of some kind in this month's patch tuesday.
https://social.technet.microsoft.com/Forums/en-US/ad37cd15-315e-4f9b-ba34-bcbd987981fc/quotan-app-default-was-resetquot-error-newly-sysprep-windows-10-ltsc-2019-enterprise-image?forum=win10itprosetup

Does anyone happen to have any inside info, more specifics, or anything at all? If there is a hotfix, patch, etc, would love to get my hands on it, or at least know what it is so I can open a case with MS and request it.

Answer 1

Hi,
I noticed you are using PDQ deploy which is not supported by Microsoft. I would recommend to use Sysprep to check the issue again.
As we have encounter same issue with your referred thread, I would provide my knowledge here for you and other similar issue customers' reference.

When using copyprofile true, the current user's profile gets copied over to the c:\users\default and is used as the default template for a new user creation by windows
For this default user account the following entries already exist
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FileExts\<fileextensions>\userChoice\Hash
However the hash is based off the SID of the user account in whose context the sysprep was run
So now when a new user logs on OEMDefaultAssociations.xml gets applied, the Hash that is already present is detected as invalid causing a application notification storm of app resets.

Based on discussion with feature team for FileExts, Sysprep copyprofile in unattend.xml is not fully supported for this scenario. Incase copyprofile option still needs to be used, then the end user/Deployment admin, needs to ensure before the copyprofile runs, to copy the target profile as the default profile,

The source profile really should not have anything in either of these locations either:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts
HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations
Also delete the entry
FileAssociationsUpdateVersion
from HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations

The above steps will ensure that the default profile is not seeded with the old user's file extension choices. and regular user defaults get applied as per OEMDefaultAssociations.xml

Please feedback your action result here.

Bests,

Answer 2

I have two default app settings were changed messages, one for holographic something, and another for xbl-something. These are probably because I don't have the extensions defined in my defaultappassosciations.xml file (which now works after the march disc update!). I don't intend on fixing those. What the march update doesn't fix is win10's inherant angryness with changing the default browser.

I will say if I do a upgrade task sequence with MDT it does some extra steps natively. I"m not sure what all it does, but if you change the unattend.xml to copyprofile:false, you don't get the app default change messages, but you do get the default browser changed to edge message. (We have https/s/etc defined via appassociations.xml so they still function). We've decided to install using the cmd line upgrade and install.wim method, and will live with the 3 warning messages it now gives.

Note - if you use Policypak there is a add you have to do for msra to exploitprotection.

Answer 3

This update seems to fix the issue. Tested it today... No more strange App Default Reset messages
https://support.microsoft.com/en-us/help/4550945

Answer 4

Did you just inject that update into your 1909 upgrade media?

Answer 5

Tested on 1909, can confirm KB4550945 resolves this issue, I can't believe it took 1 year to fix this.