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 was also suffering from 11 notifications when each new user logs in after installing a system prepared with Sysprep.

In my case I finally discovered this was caused by the single account I am required to create when installing the virgin copy of Windows prior to customising it and sysprepping it. By going into sysprep audit mode and deleting that account before doing Sysprep generalise, the problem has gone away for me.

Answer 3

I just tested the April patch and on my first random device the pop ups have gone from 12 ton1, so clearly there was an issue with windows 10, this was only tested on 1909

Answer 4

I did find an answer. Copyprofile must have some functionality because if you add copyprofile: false then in my test env I was able to get things to function - even with my 1809-based defaultapps.xml

In MDT this means (in x64 bit) download the WSIM 1903 fix, open the unattend (in the share under control, then the task squence) and open the unattend file and save it. If you save with the updated WSIM you will be able to edit the file within MDT (new task sequences do not generate properly for some reason, WSIM fixes them with the fix applied). From there you can add copyprofile: false (just search for copyprofile, add to phase4). This seemed to do the trick for me. I'm not sure how you would otherwise modify a install.wim.

MS released an updated 1909 install disc, I think it was on 3/27 via the Volume License center. This version appears to have the fix as running without copyprofile: false (just default) seems to do the trick, though I'm pretty early in my initial testing.

Answer 5

No change for me. Same 3 pop up errors as before.
It's really frustrating that I'm holing up the release of 1909 to our fleet.