Bug: Edge 104 on FirstRun: This policy is blocked - its value will be ignored.

[Gunnar Haslinger]

With current Edge 104 (Win10 x64, Edge Version 104.0.1293.54) I realize there is a new Issue on FirstRun regarding the "sensitive Policies".

What do I mean with "FirstRun"? It affects both types of FirstRun:

• a "real FirstRun" (user has no Edge UserProfile)
• as well as a "FirstRun of Version 104.0.1293.54" (user already has an Edge UserProfile, but EdgeUpdate updated to this new Version and its the first run of this new version).

What's the Issue?

On FirstRun of Edge 104.0.1293.54 all Policies which are documented as "This policy is available only on Windows instances that are joined to a Microsoft Active Directory domain, Windows 10 Pro, or Enterprise instances enrolled for device management." do not work on Edge 104.0.1293.54. All other Policies still work as expected, but Policies like HomepageLocation, DefaultSearchProvider, RestoreOnStartUpURLs etc... which need an MDM-Enrolled or AD-Joined Device don't work. 

Edge 104 shows on FirstRun Browser-Start: ErrorThis policy is blocked - its value will be ignored.

(I currently only have a Screenshot in German language, but screenshot looks the same like this issue we had in April 2022 - so if you like to see a screenshot just look at the policy-Screenshot there).

When Exiting Edge 104 and Restarting Edge 104 everything works fine, all further Edge-Starts after the FirstRun the Policies are loaded correct!

Comment: When running "kiosk-style configured Machines" where the Edge-UserProfile is deleted regularly and the Policies "HideFirstRunExperience", "SyncDisabled", "AutoImportAtfirstRun" are used to just directly jump into a fresh Edge-Browser-Profile on FirstRun this new Bug makes the Usage of v104 unusable!

Please @mkruger, @Kelly_Y  I need your help to find out if there is any workaround and to get this fixed soon.

[#2]

I found out what Edge is looking for to identify the Situation of a "FirstRun of Version 104.0.1293.54" (user already has an Edge UserProfile, but EdgeUpdate updated to this new Version and its the first run of this new version):

JSON-Settings in this File:

 %USERPROFILE%\AppData\Local\Microsoft\Edge\User Data\Local State

The affected User-Profiles before Updating have this settings configured:

"management":{"platform":{"azure_active_directory":0}}

And after FirstRun of Edge 104.0.1293.54 this ist changed to:

"management":{"platform":{"azure_active_directory":0,"enterprise_mdm_win":4}}

A workaround to avoid this bug when Updating Edge and the UserProfiles already exist is, to patch the "Local State" File and add "enterprise_mdm_win":4

But for New-Userprofiles I still have no workaround despite exiting Edge and starting it again.

[#3]

Thanks Gunnar for this report and the details. The details are very helpful and we will look into this.

[#4]

May I kindly ask @mkruger if there are any news regarding this issue?

I see this Bug at least on all current Versions of Edge on Win10x64:

• Canary 106.0.1354.0
• Dev 106.0.1349.1
• Beta 105.0.1343.7
• Stable 104.0.1293.54, 104.0.1293.63

Those old Versions are affected too:

• Stable 103.0.1264.77
• Stable 102.0.1245.62
• Stable 102.0.1245.30 (which was the first v102 available)

This old Versions are NOT affected:

• Stable 101.0.1210.53 (which is the last v101 available)
• Stable 101.0.1210.39

=> so we can assume this Bug seems to exist since

• Stable 102.0.1245.30

As I service our Image for internal usage only once in 3 month I didn't notice this Bug appeared in v102 and see it now in v104. The JSON-Setting "enterprise_mdm_win":4" in "Local State" File seems to be a new property in v102, it wasn't there in v101.

[#5]

@Gunnar Haslinger sorry for delays in replying.

With your information, I was able to reproduce the problem and am testing a fix. When successful, I'll work to get it patched to the current releases.

[#6]

Checked the recently released new Stable 104.0.1293.70 today, Problem on FirstRun is still there.

[#7]

Checked the recently released new Stable 105.0.1343.25 today, Problem on FirstRun is still there.

[#8]

This should be fixed in 106.0.1365.0 and later.

There is a slight performance tradeoff to browser start time with the fix that we are investigating before we can port to 105.

[#9]

@mkruger re-tested this on brand new, fresh installed Windows 11 v22H2, result as follows:

• Edge 105.0.1343.42 (Stable) ... Problem still there, so seems to be not backported yet
• Edge 106.0.1370.17 (Beta) ... Is fixed, works now even on FirstRun as expected
• Edge 107.0.1387.2 (Dev) ... Is fixed, works now even on FirstRun as expected

[#10]

Re-tested today: v105.0.1343.53 (Stable) ... Problem still there, so seems to be not backported yet

But as Edge v106 gets Stable this Week (Week of 29th September 2022) backporting gets irrelevant soon.

[#11]

@Gunnar Haslinger I apologize for not being able to get this backported, but with 106 coming soon, I hope that alleviates things for you soon.

[#12 · Accepted solution]

Today Edge 106.0.1370.34 released as stable and I can confirm this Issue is solved.