Forum Discussion
Edge Stable 103.0.1264.37 breaks group policy management of the browser - Critical
Going from version 102.0.1245.44 (June 16) to 103.0.1264.37 (June 23), we started experiencing the following issue.
Our AD Domain Joined machines running Edge and being managed via Group Policy, unload their policy set on every gpupdate (foreground or background).
To reproduce this, just go to edge:\\policy and see your policies. Then, do a gpupdate and once it completes, visit that page again. It will show an empty set of policies (Although the policies are there in the registry).
The only way to re-apply the policies is to:
1. Wait for the browser itself to do it (Reload Policy), could take any number of minutes
2. Click the Reload Policy button on Edge:\\policy
This results in all Externsions being re-installed, the centralized boomarks re-applied etc and it is both a problem raised by our end users because they see their extensions being re-installed on every gpupdate and we no longer are sure that our endpoint browsers are managed.
- AlexandrosAP Its a issue within Chromium its self. https://bugs.chromium.org/p/chromium/issues/detail?id=1338586&q=extensions&can=2
Looks like Chrome was updated today, so just need to wait for MS to do the same with Edge
- AlexandrosAPBrass Contributor
Issue continues on Dev channel version 104.0.1293.5 .
- AlexandrosAPBrass ContributorI can reproduce this as it works properly up to version 102.0.1245.50 (Official build) (64-bit) and starts failing on 103.0.1264.37
- Thirdno3Copper ContributorAlexandrosAP Its a issue within Chromium its self. https://bugs.chromium.org/p/chromium/issues/detail?id=1338586&q=extensions&can=2
Looks like Chrome was updated today, so just need to wait for MS to do the same with Edge- Eric_LawrenceMicrosoftThe Edge team is aware of this issue and working to release a similar update as quickly as possible.
- tcbscepCopper ContributorThis sounds like it may be related to my problem as well. For me, the "Configure favorites" policy reload causes edge to crash.
- AlexandrosAPBrass Contributor
tcbscep we also use this policy and it does not lead to browser crashes.
- Eric_LawrenceMicrosoftThis issue is unrelated to a crash. Please share the "Uploaded Crash Report ID" from the edge://crashes page?
- tcbscepCopper Contributor
Eric_Lawrence Just uploaded a report, but I don't see an upload ID in the output. I can provide the debug file if needed.
{
"Local ID": "e3439499-acb6-4fe3-bcff-fdafaf5d7187",
"Upload ID": "",
"Capture Time": "Tuesday, June 28, 2022 at 4:31:13 PM",
"Upload Time": "Tuesday, June 28, 2022 at 4:31:13 PM",
"State": "uploaded"
}
- John TracyCopper Contributor
got .37 here, and I can’t replicate the problem. Both mandatory and prefererred settings are working. Including a filter proxy on public-facing PCs. It might be worth mentioning that they are all user-policy settings.
- AlexandrosAPBrass ContributorFor us they are all system hive policy settings.
- Eric_LawrenceMicrosoft
This issue is caused by a race condition.
Group Policy update works by
1) Deleting the old policies from the registry
2) Writing the current policies to the registry
3) Chromium reloading new policy data out of the registry
In v103, a regression was introduced by new registry-monitoring code. This code would detect that the keys had changed at [point 1] and the browser's in-process policy would be refreshed before the current policy data had been fully written to the registry by the GP Update. As a consequence, the browser process could end up with a "partial" (or empty) set of policies applied.
The problem's reproducibility will vary depending upon how short the time gap is between old policies being deleted from the registry and new policies being written. The visibility of the problem also varies-- only policies that support Dynamic Refresh are impacted, and many policies do not have side-effects that are immediately user-visible.
The fix is to stop monitoring the registry keys directly.- AlexandrosAPBrass ContributorThe issue is caused by the changes on Microsoft Edge version 103.0.1264.37. Prior to that there was no race condition issue and the machines are the same.
Is there a fix on the way or should we find an alternate solution?
- abiurruncCopper ContributorHi Guys.
In theory it was fixed by 103.0.1264.44 (June 30,2022) path.
Can someone check it?
Thanks in advance.