[German]When upgrading a system to Windows 10 20H2 via WSUS there is a nasty trap that a blog reader pointed out to me. When upgrading, an existing Chromium Edge browser of the old system is forced to upgrade to an older Edge version. And Edge is not automatically updated afterwards. Update: Some additional comments appended.
Advertising
Some Background
Administrators can upgrade Windows 10 clients to newer builds via Windows Server Update Services (WSUS). For Windows 10 20H2 (October 2020 Update), there are two options:
- When upgrading from older Windows 10 versions, the multi-gigabyte feature update is rolled out via WSUS and installed on the clients.
- When upgrading from Windows 10 2004 to the 20H2, only a several hundred KByte Enablement Update is needed to unlock the features of the new Windows 10 20H2.
With the first mentioned variant of a complete upgrade, the old operating system is replaced by the new variant from the installation image. This is the variant that causes trouble.
Microsoft Edge downgrade during the upgrade
German blog reader CJ drew my attention the days in this comment to a problem when upgrading to Windows 10 20H2. He told me his experience when upgrading to Windows 10 20H2 from 1809 or 190x:
I am distributing the new Edge via MSI in the company. Latest [Edge] version 86.0.xxx on 1909 and 2004 is distributed and up everywhere, updating via WSUS. So far, so good.
If I do the Windows 10 update to 20H2 via WSUS now, the update will iron the [old] Edge 84.0 over it. Both EDGE versions in the program directory, but only 84.0 available.
It does a downgrade so to speak! You have to manually reinstall the MSI with the 86.0 version again, because the GPO can't do that by itself. And the WSUS doesn't help either… And a downgrade lock I could not (yet) find?
It's already clear that a feature update will take the content of the respective installation image and set an integrated edge to an older version. Microsoft does not seem to provide daily updated installation images as feature updates on their update servers. And then it comes to the described scenario that after the upgrade the older Edge 84.0 instead of the actually previously existing Edge version 86.0.xxxx lands on the machine.
What surprises me is that the browser does not update itself automatically, but a new MSI installation has to be used for the upgrade. Of course, this only happens with a feature upgrade from Windows 10 version 190x (or 1809) to Windows 10 20H2, because only there the installation image is used. Can anyone confirm these experiences? Is there a remedy?
Advertising
Additional remarks about the issue
Meanwhile, there are two comments below to this blog post that should be noted.
Old MSI installer with issues
Blog reader EP points out in the this comment that you should use the MSI installer from this URL, because Microsoft included an "outdated" Chromium Edge installer in the KB4562830 20H2 enabler package and not the new ones from either September or October. Thanks for this comment.
Answer from the Edge Product Manager
Andy Zeigler, product manager Edge, has posted this comment, explaining how the downgrade may happens (thanks for that). How it behaves with the update KB4584642 (see Microsoft Edge available as update KB4584642 for WSUS), we have to see.
Addendum: See also the 2nd comment, dated November 10,2020, from Andy Zeigler, promising a fix soon.
Advertising
just download & run the latest MS Edge enterprise MSI installer from here:
https://www.microsoft.com/en-us/edge/business/download
I right-click on the newest MicrosoftEdgeEnterpriseX64.msi installer file and choose Uninstall – that would actually remove the existing versions of Edge from 20H2. after a reboot I then use the newest MicrosoftEdgeEnterpriseX64.msi installer file again and select Install to install the recent version.
Microsoft included an "outdated" Chromium Edge installer in the KB4562830 20H2 enabler package and not the new ones from either September or October. I hope Microsoft 'revises' the KB4562830 package again to include the newer Edge installers.
Hello,
In general, the 20H2 update will not downgrade a newer version of Edge, however this can happen if system being upgraded had a user-level installation. This can happen if you for, for example, decline the elevation prompt at Edge installation time. Most devices have a system-level installation.
Generally when you do MSI deployments, you also disable Edge's native updater so that you can control the version, which probably explains why the 84->86 update didn't take place.
Please feel free to reach out to me with further questions — happy to help.
Many thanks,
Andy Zeigler
PM, Edge Team
Thx for your insight, I've added it to the German blog post too.
In my case, the issue occurred on 3 different systems upgraded from 1909 to 20H2 which had Edge installed as a per-system installation using Configuration Manager. It's a significant problem when it occurs since the version of Edge installed by the 20H2 upgrade is configured as "non-removable", so the option to uninstall it using Programs and Features is unavailable, making it difficult to remove and get the client back up to date.
In our case, we use Configuration Manager to upgrade Edge using Software Updates. With 1909 clients I've been able to downgrade Edge on a client and verify that it gets successfully upgraded again by SUP; however, with 20H2, MECM failed to update the 20H2-installed instance of Edge 84 to a newer version, requiring the instance installed by 20H2 to be removed prior to reinstalling Edge 85/86 using MECM.
Hi All,
Thanks again for all of the detail — we have reproduced this issue locally and are working on a fix as quickly as we can. I'm really sorry for the inconvenience.
One thing that you can do is redeploy your version of Edge once the device is on 20H2 by adding a couple of extra arguments:
msiexec /i MicrosoftEdgeEnterpriseX64_85.68.msi REINSTALL=ALL REINSTALLMODE=A
Also, the next time a new version is available (typically we publish Stable updates ~weekly), the next update will install suscessfully, e.g. if delivered via WSUS.
I recognize that this is not a great workaround for all scenarios — we are working on a solution to prevent the downgrade from occurring. I'll let you know as soon as the fix is available.
Thanks again,
Andy
Andy, thanks for your comment. I've added it to the German blog as well to a discussion within a German administrator site, that has covered the case.
Any sign of a fix for this yet?
It's a bit annoying as the older version that lingers doesn't support roaming the user profile etc which is a problem for enterprises.
can we get any updates on this issue?
ATM all our machines that are upgraded to 20H2 has Edge 84 and all ugly vulnerabilities included for free… all computers are marked RED in our security systems…
Is there any reason why an installed version of edge is preventing an upgrade from 1909 to 20H2. This is using the latest 20H2 media on vlsc, basically the upgrade TS rollsback after installing and only error message is about microsoft edge. Forcing a uninstall of an edge installed prior to upgrade then reapplying edge after the upgrade works but is a workaround, only seems to happen on multilanguage (en-gb and de-de as a reddit user has discovered)
Any update? This is made worse by virtue of version 84, the one it downgrades to, not supporting roaming edge profiles. Our users upgrade to 20H2 and their saved passwords etc aren't available from azure sync. How was this issue missed, it's pretty basic like. And what's the proposed fix and timeline? I'm attempting to trigger the install of the upgraded version of edge as the final step in a set of custom actions but limited success so far and not ideal.
Hi. Have you found a workaround for this? We are also in the same position and lots of machines show vulnerabilities as a result.
I'm not aware of a workaround.
We've been doing it using the custom action scripts for the feature update. If you're not familiar with it, it's straightforward enough.
Drop the latest version of the Edge installer to the PCs in advance via whatever method. Put it in a location like c:\programdata. For us, we're not that bothered with the latest latest version as it'll actually update pretty quick afterwards, we just needed it to be at least version 86 i think it was, that introduced azure based roaming profile support for passworsd / favorites etc.
You have a success.cmd file in a specific location in the windows subfolder tree. That calls a powershell script you place elsewhere e.g. in c:\programdata as well. In that script, you call the install of the latest edge – we're doing an install rather than a repair as such. That script executes if the upgrade succeeds. So when the updating windows bit hits 100% and the next step woudl be the logon screen, this script kicks in, does its stuff and blocks the login screen from showing until it appears. We're using it to do other stuff like generate log info, send an email for success, fix language packs, and language settings, remove cortana (we're coming from 1809 and it was the only store app that got reintroduced), and then do a final restart to ensure policies kick in.
Happy to share all the scripts etc, with you it'd help, my gmail is my name as per this post, without space obviously, no dots etc.
Late February 2021 and this is still a problem. It's also a serious security flaw as we are exposed to Edge 84 until we can reinstall Edge 88 after the OS update to 20H2.
At no point was this a user driven installation. Edge has only been installed from SCCM or WSUS updates. We need Microsoft to update the 20H2 Feature update to include Edge 88.
Any update on this issue? Just discovered this gem today :)
None of our Edge deployments have ever been "user based", always deployed via SCCM, so I think there are other scenarios possible why this occurs.
Any update on this issue?
There have this status post from Microsoft, as I read yesterday.
Hi guenni, I'm aware of that article but AFAIK it's not related to the issue posted here.
If we better understood the root issue, we could take an action before the 20H2 upgrade is performed to avoid it all together.
Seems like this isn't even fixed yet even tho it is a security flaw.
We've just done a 1909 to 20H2 update in our enterprise and have come across a problem with Edge afterwards. I've not been able to check if an old version of Edge has been installed but the issue we are having is that Edge will just not open after the upgrade, which is a major issue you can imagine. We have found out ourselves that doing a reinstall of Edge fixes the issue. Now I've read this I am going to check the next that is reported to see if the Edge executable has been rolled back to a prior version. We push out Edge updated via WSUS so prior to the 20H2 upgrade the devices will have been on the latest Edge version. The 20H2 update that is in WSUS is dated November 2021 and seems to be the latest.