Edge Stable 103.0.1264.37 breaks group policy management of the browser - Critical

[AlexandrosAP]

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.

[#2]

Issue continues on Dev channel version 104.0.1293.5 .

[#3]

I 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

[#4 · Accepted solution]

@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

[#5]

Oh God! Ok, the break-team again.

[#6]

The Edge team is aware of this issue and working to release a similar update as quickly as possible.

[#7]

This sounds like it may be related to my problem as well. For me, the "Configure favorites" policy reload causes edge to crash.

[#8]

@tcbscep we also use this policy and it does not lead to browser crashes.

[#9]

This issue is unrelated to a crash. Please share the "Uploaded Crash Report ID" from the edge://crashes page?

[#10]

@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"
}

[#11]

Thanks Eric, please post as soon as one is available!

[#12]

I hope to have something helpful to share tomorrow.

[#13]

@AlexandrosAP 

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.

[#14]

For us they are all system hive policy settings.

[#15]

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.

[#16]

The 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?

[#17]

I can confirm the same issue with this build and group policies, specifically extentions defined in the policy that are no longer working. A rollback to the 102 stable version has been the workaround for us until fixed. I have created a case with microsoft and am awaiting their solution. Still no word yet!

[#18]

Only extensions configured by ExtensionInstallForcelist policy are affected or also those by ExtensionInstallAllowlist policy ?

[#19]

Allowed extensions definitely are for us @DanielJasiak 

[#20]

Yes, the fix is checked in and awaiting the next respin/release (103.0.1264.44).