In this Blog-Post I describe, how to apply restricted Edge based on Chromium Policies like
HomepageLocation, NewTabPageLocation, RestoreOnStartupURLs, DefaultSearchProvider, SmartScreen and several more without domain-joining the Devices by using a “Fake-MDM-Provider”. You need this solution, if some of your policies show up in
edge://policy overview to be “blocked”.
Several Microsoft Edge (based on Chromium, Version 77 and newer) Policies are described as follows: This policy is available only on Windows instances that are joined to a Microsoft Active Directory domain or Windows 10 Pro or Enterprise instances that are enrolled for device management.
This means, that this policies are not respected and therefore not successfully applied to Edge when configured locally by gpedit.msc (Group Policy Editor) as local registry keys on devices, which are not managed by Active-Directory Domain-Join or an Mobile-Device-Management-Solution.
But: there is an easy workaround to achieve a successful honored configuration of this restricted policies by configuring a “Fake-MDM-Provider” (= enrolled for device management without actually using MDM).
This blog-post is a rewrite of an older blog-post I initially published in April 2018. The difference between my older blog-post and this newer version is, that:
1. This one covers Edge based on Chromium (Edge v77 and newer), the older Blog-Post covers Edge v44 (the now called “Edge Legacy” which was shipped with Windows 10 Releases up to v1909).
2. This one is written in english, my older one was published in German. As so many people in Microsoft-TechCommunity are asking about this restriction I decided to blog this one in English to reach a broader audience.
Local Group Policy Restrictions
As already described, several Microsoft Edge Policies are restricted to be only honored and applied when the device is Domain-Joined or managed by MDM. You can find those restricted Policies by searching for the String “This policy is available only on Windows instances that are joined to a Microsoft Active Directory domain or Windows 10 Pro or Enterprise instances that are enrolled for device management” in the Microsoft Edge Policy-Documentation. If you use gpedit.msc (the Local Group Policy Editor) this restriction is well documented even in the comments of the Policy-Description (but you have to scroll down to see it, as you can see on the next Screenshot):
Mobile-Device-Management-Solutions like Microsoft Intune, BlackBerry UEM, Cisco Meraki, Airwatch, MobileIron, etc… allow you to use a lightweight Device-Management by applying some assorted policies to MDM-managed-devices. Most of these solutions are not free of charge, but there are even some cloud-managed, free of charge solutions like Miradore Online to run some cost-free experiments. To “enroll” a Windows-Device to a MDM-Solution the Mobile Device Enrollment Protocol is used.
What I did is, I traced all modifications (tons of registry Keys etc…) on a Windows Machine, when enrolling a Win10-device to an MDM-Solution. Then I traced those Registry Keys checked by Microsoft Edge, to decide if the Device is MDM-Managed or not. I narrowed down the ton of registry keys to only a few of them really needed to successfully let Edge detect “this device seems to be MDM-Managed” without actually having a connection to an MDM-Provider.
As a result I can provide you a minimal-set of Registry-Keys you have to add to make Edge on a Win10-Machine “feel” like it is MDM-Managed and honors to apply the restricted Policies like HomepageLocation, NewTabPageLocation, RestoreOnStartupURLs, DefaultSearchProvider, SmartScreen and several more without domain-joining the Devices.
Download the needed reg-Files
I provide you a single zip-File which contains 3 Files:
1. MDM-FakeEnrollment-Win10.reg … the Registry-Keys you have to add to let Edge “feel” like the Win10-Machine is MDM-Managed.
2. EdgeChromium-Policies-Mandatory.reg … some sample policies like configuring Google as Search-Engine, Homepage, New-Tab-Page etc… – this works after the MDM-FakeEnrollment is applied. If you set “Mandatory” Policies these Settings cannot be (re-)configured by users themselves.
3. EdgeChromium-Policies-Recommended.reg … some sample policies configured not “Mandatory” but only as “Recommeded”, these Settings can be changed by users themselves, they are just a default.
4. EdgeChromium-UpdatePolicy-SideBySide.reg … this (fully optional) Policy you may like to set to keep old EdgeLegacy available when installing EdgeChromium. Now in Year 2022+ this is obsolete, as the old EdgeLegacy is not available on current Windows 10 Systems any more.
Just import the 1st one (MDM-FakeEnrollment-Win10.reg ) to enable the “Fake-MDM-Provider”. Use the 2nd one (EdgeChromium-Policies-Mandatory.reg) to import my sample configuration (like shown in the next screenshot) or use your gpedit.msc (Local Group Policy Editor).
When using the Group Policy Editor you need the admx-Files for Edge based on Chromium from Microsoft, you can download them here: https://www.microsoft.com/en-us/edge/business/download (Link: “Get Policy Files). Configuration then looks like this: Computer Configuration => Administrative Templates => Microsoft Edge. Be aware: it is NOT “Windows Components => Microsoft Edge” (this would be the old Edge Legacy Browser!).
- Test in January 2020: I successfully tested my solution with all currently Microsoft-supported Windows 10 Releases: v1709, v1809, v1903, v1909, 2019 LTSC and all currently (January 2020) available Edge based on Chromium Versions: v79, v80 (Beta), v81 (Dev).
- Test on 09.02.2020: Successfully tested with Edge v80.0.361.48 (Stable) up to v82.0.418.0 (Canary)
- Test on 20.05.2020: Successfully tested with Edge v81.0.416.77 (Stable) up to v84.0.520.0 (Canary) on Win10 v1909 as well as Win10 v2004 (by InplaceUpgrade from Win10 v1909)
- Test on 22.05.2020: Successfully tested with Edge v81.0.416.77 (old Stable) as well as v83.0.478.37 (new Stable) up to v84.0.520.0 (Canary) on Win10 v2004 (Fresh Install, Build 19041.264)
- Test on 12.10.2020: Successfully tested with Edge v86.0.622.38 (Stable) up to v87.0.658.0 (Dev) on Win10 v1909
- Test on 21.10.2020: Successfully tested with Edge v86.0.622.48 (Stable), v87.0.664.12 (Beta), v88.0.673.0 (Dev), 88.0.677.0 (Can) on Win10 v2009 / 20H2 Build 19042.572
- Test on 13.11.2020: Successfully tested with Edge v86.0.622.68 (Stable), v87.0.664.30 (Beta), v88.0.692.0 (Dev), v88.0.698.0 (Can) on Win10 v2009 / 20H2 Build 19042.630 (Professional, Education, Enterprise)
- Test on 14.12.2020: Successfully tested with Edge v87.0.664.60 (Stable), v88.0.705.18 (Beta), v89.0.723.0 (Dev), 89.0.731.0 (Can) on Win10 v2009 / 20H2 Build 19042.685 (Professional, Education, Pro Education, Enterprise)
- Test on 11.06.2021: Successfully tested with Edge v91.0.864.41 (Stable), v92.0.902.9 (Beta), v93.0.910.5 (Dev) on Win10 v21H1 Build 19043.1052 (Professional, Education, Pro Education, Enterprise)
- Test on 13.08.2021: Successfully tested with Edge v92.0.902.73 (Stable), v93.0.961.18 (Beta), v94.0.975.1 (Dev) on Win11 Preview v21H2 Build 22000.132 (Professional, Education, Pro Education, Enterprise)
- Test on 20.04.2022: Successfully tested with Edge v100.0.1185.44 (Stable), Edge v101.0.1210.19 (Beta), Edge v102.0.1227.0 (Dev+Canary) on Windows 10 v21H2 Build 19044.1620 (Professional) all Patches applied. There was a Bug in the “early” v101-Beta-Releases which was fixed starting with v101.0.1210.19.
- Test on 05.09.2022: Successfully tested with Edge 105.0.1343.27 (Stable & Beta), Edge 106.0.1363.0 (Dev) on Windows 10 v21H2 Build 19044.1889 (Professional, Enterprise) all Patches applied.
- Test on 12.09.2022: Successfully tested with Edge 105.0.1343.33 (Stable & Beta), Edge 107.0.1375.0 (Dev) on Windows 11 v21H2 Build 22000.918 (Professional, Pro for Workstations, Pro Education, Education, Enterprise) all Patches applied
- Test on 22.09.2022: Successfully tested with Edge 105.0.1343.42 (Stable), 106.0.1370.17 (Beta), Edge 107.0.1387.2 (Dev) on Windows 11 v21H2 Build 22000.1042 (Professional, Pro for Workstations, Pro Education, Education, Enterprise) and Windows 11 v22H2 Build 22621.521 (Professional, Pro for Workstations, Pro Education, Education, Enterprise) – all Patches applied
- Test on 30.12.2022: Successfully tested with Edge 108.0.1462.54 (Stable), 109.0.1518.26 (Beta), 110.0.1556.0 (Dev) on Windows 10 Pro v22H2 and Windows 11 Pro v22H2 – all Patches applied
Supported Windows Editions:
- Windows 10 Home => NO! Does not Support MDM, not supported by Fake-MDM-Provider
- Windows 10 Pro Education => Bug identified on 13.11.2020, does not work with MDM or Fake-MDM => I reported this issue to Microsoft => It is fixed in Edge Stable 87.0.664.53+ or Edge Canary v88.0.704.0+
- Windows 10 Pro => YES! tested Win10 20H2, 21H1, 21H2, 22H2
- Windows 10 Pro for Workstations => Bug identified on 11.06.2021, does not work with MDM or Fake-MDM => I reported this issue to Microsoft => It is fixed in Edge starting with Version 93.0.930.0+ => YES!
- Windows 10 Education => YES! tested Win10 20H2, 21H1, 21H2, 22H2
- Windows 10 Enterprise => YES! tested Win10 20H2, 21H1, 21H2, 22H2
- Windows 10 IoT Enterprise LTSC 2021 21H2 => Bug identified in 03/2022 => Reported to Microsoft => Result: YES, works starting with Edge v100+
- Windows 11 Professional => YES! tested with Win11 21H2 and 22H2 on 22.09.2022
- Windows 11 Pro for Workstations => YES! tested with Win11 21H2 and 22H2 on 22.09.2022
- Windows 11 Pro Education => YES! tested with Win11 21H2 and 22H2 on 22.09.2022
- Windows 11 Education => YES! tested with Win11 21H2 and 22H2 on 22.09.2022
- Windows 11 Enterprise => YES! tested with Win11 21H2 and 22H2 on 22.09.2022
After successfully applying the Fake-MDM-Registry-Keys for example the Open page on start-up Setting is successfully configured and locked:
All Edge Policies applied can be viewed by opening edge://policy
Side-Effect: Defender Tamper Protection turned off on MDM-managed Devices
When a Windows-Machine is MDM-managed the Windows Defender Tamper Protection is “Managed by Administrator” and shows turned off. This is not intentionally caused by my Fake-MDM-Provider, it is generally behavior by any MDM-managed Device as you can read here. Thanks ¡Firedog for bringing this to my attention.
hi and thank you so much for this. unfortunately it looks like either the new win 10 May RTM is blocking this fake MDM or something else is.
if i update a working PC from1909 to rtm 2004 fake MDM still works.
but if i start fresh with an image base of may rtm 2004, the registry keys get blocked.
IF possible can you build a new image off of 2004 and chormium edge v81.0.416x and check if you can tarce again the modifications needed?
Successfully tested with Edge v81.0.416.77 (old Stable) as well as v83.0.478.37 (new Stable) up to v84.0.520.0 (Canary) on Win10 v2004 (Fresh Install, Build 19041.264) as well as Inplace-Upgraded Win10 v2004 (WindowsInsider Build, Updated from v1909). Both work!
Maybe your fresh Win10 Release 2004 Installation is a “Home Edition”? As far as I know you need at least an Professional Edition for using Management-Functionality like MDM or AD-Join.
i rebuilt from scratch and this time used win 10 pro instead of win 10 pro N. I had recently switched to use ‘N ‘ because i dont need any of the media features. I then realized after encountering issue with my activation key, i could register win 10 pro N builds. So i reverted back to regular build and activation worked.
Then i decided to check my Edge chromium GPOs and they were now working!!
what i dont understand is why would the ‘N’ build have impact on :
-edge GPO/MDM status
i rebuilt N image twice and always the same
on a side note, have you ever tried https://uupdump.ml/
its is an online script/repository to asses required windows 10 components from MS server and create the newest bootable builds on your computer. Sure beats using MS iso bases and manually integrating updates. you can choose from the following target builds: retail/insider:slow-fast ring/release preview
I think what might have happened in my issues is that i generated a windows 10 pro N built using uupdump script(i had been using regular win 10 pro 2004 perfectly fine before) but the image indexes had all windows version from home to enterprise and all N image indexes as well. I decided to cleanup and remove all indexes but leave only PRO N.
anyway, its working now.
have a good day
I always use the official ISO-Files from https://my.visualstudio.com/Downloads, the official Image “Windows 10 (business editions)” contains all Windows 10 Pro/ProN/Education/Enterprise/Enterprise N/… Releases. I guess the MDM-Feature is tied to the Business-SKUs, so for finding out what happened the detected SKU would be interesting.
Anyway, as you solved your problem I guess it is not worth to dig into this further.
Tested with Windows 10 2004 and Edge Chromium 83.0.478.45 and it’s not working 🙁
i use the reg file.
NewTabPageLocation Value https://hitco.at/ Error This policy is blocked – its value will be ignored.
I don’t know what to do… any suggestion?
Which reg-File did you use? You have to apply the Fake-MDM-Enrollment.
Which Windows-Edition are you using? Professional? I already successfully tested Version 2004 with Edge v83.
I used “EdgeChromium-Policies.reg” after having applied “MDM-FakeEnrollment-Win10_v1809_v1909.reg”.
I have a Windows 10 home edition, thats why I don’t have the local group policy editor (gpedit.msc).
The Policy-Documentation (I cited in the beginning of this Blogpost) says, that this policies are only applicable for Windows 10 Professional, Education, Enterprise with AD-Join or MDM-enrolled. My Fake-MDM-Enrollment makes it available without actually being MDM-enrolled. But I never tried to fool Edge on a Windows Home Edition.
OK thanks. It’s a pity we don’t have a lot of ouf-of-the-box customization possibilities in Edge Chromium as we have in Internet Explorer 11.
I’ll try it @work using Windows 10 Enterprise.
Der regitryhack funktioniert immer noch, auch unter Windows 2004 = 20H1
Getestet an mehreren Maschinen in mehreren Umgebungen virtuelle und ‘richtige Maschinen’ und mit mehreren Win 10 Versionen (Pro, Education, Enterprise).
Es liegt definitiv am Edge Browser Code ab Dev Kanal ab 85.0.538.0 und betrifft noch mehrere Einstellungen in den GPO’s.
Die admx-Version ist egal, ob Richtlinien für Dev 85.0.531.1 (die Browser Version die als letzte funzt)
oder für Browser Version 85.0.538.0 funzt nicht oder als letztes Browser Version 85.0.545.0 funzt nicht.
Hier eine kleine Auflistung der Einstellungen die nicht funktionieren:
Thanks for your comment. I just checked and can confirm your test-result.
Win10 v2004 (2020H1 Release) with most current Edge Chromium Stable v83.0.478.45 Release works fine.
But when using most current Developer Release Dev 85.0.545.0 it seems not to Work with FakeMDM Provider.
I will try to figure out if there is a solution or maybe it is a bug in the Policy-System of the Dev-Release.
ich antworte auf deutsch mein englisch ist mehr als dürftig.
ich glaube es liegt am nicht an den Admx-Vorlagen der jeweiligen Browserversion
oder an dem FakeMDM-Provider Hack. Das Verhalten ist in AD-Umgebungen bei mir dasselbe.
Ich bin eigentlich zum Schluß gekommen, das es irgendwas im Browser Code ist. Aber dazu bin
nicht genug Spezialist dafür.
Ich werde mal untersuchen, ob sich Google Chrome auch so verhält.
Hi again Dette,
I checked this behavior with Edge Developer Release Dev 85.0.545.0 again on a Machine which is REAL MDM-Managed (so no Fake-MDM but Real MDM Provider Miradore used). And it doesn’t work with Dev 85.0.545.0 – so I guess there is a Bug in most current Dev-Release.
Ich hoffe nur das MS diesen Code nicht weiter bis in den stable-Kanal schleppt., wenn der mal bei 85 angekommen ist. Habe das zwar schon an MS gemeldet
aber ich habe wenig Hoffnung auf Besserung.
Wir installieren in AD’s immer bei 5 Prozent der User den Dev-Kanal, um später nicht auf Überraschungen zu stoßen wie jetzt zum Beispiel.
I can confirm there is a Bug in Edge Dev and Edge Canary, but Stable and Beta still work. It is proven to be a bug because it doesn’t even work with true Microsoft MDM (Intune / Microsoft Endpoint Manager Admin Center / AzureAD joined Windows 10 Enterprise 2004 Device). I opened an issue in Microsoft TechCommunity to report this.
I reported this bug through Edge Support, Edge Insider Forum and other channels.
I’m glad to confirm it is fixed in todays Edge Canary 86.0.580.0 – my Fake-MDM-Provider Configuration works as expected again.
Update on 22.07.2020: Microsoft fixed it in Edge Dev 85.0.564.13 too, so now all up to Date Versions of Edge 84, Edge Beta, Edge Dev 85 and Edge Can 64 are tested and compatible with Fake-MDM-Provider.
I’m on 86.0.622.63 and .68 Official Build x64 with fake MDM and it does still not work.
This is what I Used and it did work with the newly installed Windows 10 Pro Education Builds 2 weeks ago.
There is no known problem with my Fake-MDM and Edge Version 86.0.622.68 – just tested it for you, works fine!
What does edge://policy show? Any Errors?
I just re-tested with Windows 10 2009 = 20H2 and Edge 86.0.622.68, works as described.
See here, no “ignored”, works: https://pastebin.com/yzugPiyy
You are sure the registry-Keys for the Fake-MDM-Provider are set as I provided them?
You said you are using “Windows 10 Pro Education” – I can confirm it works with Windows 10 Pro, Education and Enterprise. It does not work with “Home Edition” as this edition is not MDM-Join-able. Is this “Pro Education” Edition you are using MDM-join-able? Microsoft says that “Pro Education” is just a Pro with some pre-configured settings. So I guess it should work.
I copied this directly from the registry https://pastebin.com/C03hdew4
The script i wrote actually did work a few weeks ago on our devices. I was just installing a new one and then this occured. On Windows 10 Pro Education 20H2, Build 19042.630
Your Registry-Config of Fake-MDM seems OK. So to sum up:
Get-WmiObject -Class Win32_OperatingSystem | format-list Caption, Version, BuildNumber
I have no access to the old devices for today and I can’t say for sure which Edge version it was, it still had the old icon and the old settingsinterface (not the chromium ones)
I set up a “Windows 10 Pro Education” VM and you are right – the Policies which require MDM do NOT Work!
Just applied another Activation-Key to Upgrade to regular “Pro” (not “Pro Education”) => Fake-MDM Works!
Applied another Activation-Key to Upgrade to “Education” (not “Pro Education”) => Fake-MDM Works!
Summary: Works with Win 10 20H2 “Pro”, “Education” and “Enterprise”
Does NOT work with “Home” or “Pro Education”
(Tested with Edge 86.0.622.68, Updating my Blog-Post)
=> I reported this to Microsoft, it should get fixed soon!
=> This Bug is fixed in Edge Canary v88.0.704.0 (19.11.2020)
Will this trick also work for Google Chrome? Also can this trick stop working at any time?
Just checked Google Chrome 85.0.4183.83 and I can confirm, my “Fake MDM Provider” also works for Google Policies like RestoreOnStartupURLs
Thank you so much for your deep knowledge and sharing it to the public.
Your guide explains what exactly I needed – how to apply Chromium-based browser policies to my PC.
As much help as your suggestion provides, I’m just a little curious about any side (or unwanted) effects it might cause, and possible ways to avoid them.
For example, I found out that after importing your “Fake-MDM-Provider”, my lock screen image has changed to its default one, regardless of my Settings.
This particular issue wouldn’t bother me at all, but just to make sure all my settings and preferences are not affected.
Thank you again for your effort and sacrifice you have put into all the testings!
I have no Idea why your “Lock Screen Image” changes. This is not a behaviour which is expected. My best guess is, that you set a policy to configure your Lock-Screen – please check HKLM\Software\Policies\Microsoft\Windows\Personalization Key if there are any “lockscreen” Policies set.
Thank you for your suggestion! Using “regedit”, I found that there is no such directory
(directories until “Windows” do exist but “Personalization” doesn’t)
I also found thay my issue occurs only on startups – the lockscreen works according to my settings (web images) after locked again.
I wonder if it has anything to do with internet connection on startups.
Thank you again for your comments!
If you think your problems are caused by “Fake-MDM-Provider” you can easily remove the added registry Keys to find out if this assumption is true.
I expect no changes in behavior, but a simple timing coincidence that your observed problems started at the same day you enabled “Fake-MDM-Provider”.
My guess would be that this trick also activates some policies that require domain-join to be active. Specifically, I know that Windows10 restricts certain lockscreen policies to enterprise or domain-joined machines only. This is actually kinda neat 😉 I wonder how long it’ll take M$ to plug this particular loophole.
Great job. When we apply this policy, Users can’t change any settings in browser (you browser is managed by your organization message). Is there a way to allow users to change some settings while lock other settings?
Only those settings which are configured by a “mandatory policy” are locked. Everything else is still configurable. And there are “recommended policies” to configure defaults and allow the user to alter the settings too. So your assumption that the label “is managed by your organization” means everything is locked is just wrong.
Yeah, I was actually thinking to allow users to change settings that we configured. How to make some settings that we configure to not mandatory is the right question
As I said, just configure them as “recommended” and not as “mandatory”.
In my screenshot above you see the policies listed as “Microsoft Edge”, just one click below there is “Microsoft Edge – Default Settings” and the same policies. Configure them in “Default settings” makes them recommended, as described in the Documentation – edge://policies then shows then as “recommended” and not “mandatory” any more. Almost all policies are available in both sections – so you can chose exactly what behaviour you like for each policy.
Ah, I see your point. But I want to accomplish that via registry settings instead of using group policy if that is possible?
As well-described for every single policy in my linked Policy-Documentation the mandatory policies are placed in HKLM:\SOFTWARE\Policies\Microsoft\Edge … and the Recommended ones are in HKLM:\SOFTWARE\Policies\Microsoft\Edge\Recommended
I think I got it. I found https://docs.microsoft.com/en-us/DeployEdge/microsoft-edge-policies#defaultsearchprovidername and I can find path for recommended settings.
Yes, already found it. Great job again 🙂
Thanks Gunnar for spending the time to solve this riddle. Thank you more for sharing your work. It is truly appreciated
Thanks, this is absolutely great work! I would also like to confirm that this is working properly with the latest 20H2 update from November.
Really very grateful link,
I have one query
I need to set the home page on startup and as well as to add the new pages also
how can add new page after allowing the below key
I’m not sure what exactly you are asking,
but let’s try an answer:
I suggest you read the Microsoft Edge – Policies Guide.
There you find the Information how “RestoreOnStartupURLs” and “NewTabPageLocation” Settings work in detail, have a look on:
Great work. This is going to help a lot for about 80% of our computers which are on a workgroup as of now. However, in the near future, sometime in 2021, these 80% computers and the 20% that are domain joined will be Managed by MDM Intune. We need to be able to transition to MDM without any conflicts.
To put things into perspective, we have almost 10,000 computers scattered across the entire USA. Some are in remote areas and not all are on LANs. I would like to know if anyone has tried to join a domain or enroll in MDM while the MDM-FakeEnrollment registry is still configured. Would I need to remove these registry keys first when its time to enroll in the Microsoft Intune MDM? Again, it might be a huge challenge to locate and prepare these machines when it’s time to enroll them in Intune which is what I am trying to avoid.
I don’t have an MDM environment where I can test this. Any feedback would be much appreciated. Thank you
The “Fake-MDM” Provider doesn’t show up in “Settings -> Accounts -> Access work or school”. I didn’t test with Intune, but successfully with free Miradore-Online. I would expect there is no problem with co-existance, but there are free (time limited) Microsoft Intune / Azure Accounts too, so you can test this straight forward if you are worried about.
thank a lot.
is there a way like with edge legacy, to define a default search provider , but also a list of additional providers, so users get a default, but can change from a list afterwards?
Yes, you can preconfigure DefaultSearchProvider (see my Blog-Post about Google as DefaultSearchProvider) as “Recommended” but use the Policy ManagedSearchEngines to add other custom Search-Providers which are selectable by user or jump in when the user types a given “Keyword”.
Danke für diesen großartigen Artikel. Das war bestimmt eine Menge Arbeit die Registry Keys zu finden.
Die Keys funktionieren einwandfrei. Jetzt laufen auch die selbst gebauten Edge GPO’s ohne Probleme.
First of all, thank you for sharing your solution, it’s really help me.
I used FakeMDM reg and via gpedit edited policies: AutoOpenAllowedForURLs, AutoOpenFileType. This policies I need to open citrix workspace.
Windows 10 pro 1909 and v89 stable
Not working on Windows 10 Pro for Workstations 21H1 x64 (Edge 91.0.864.41 Stable). Any solutions available?
I can confirm it works with Windows 10 release 21H1 (Enterprise, Pro, Education), with current Edge v91.
Tried on multiple installs, it worked on exactly zero of them. System language and activation status don’t make any difference…
Thank you Pieter for reporting this Issue regarding “Windows 10 pro for Workstations”. There is a bug in Edge, those MDM-Policies don’t work running on “Windows 10 pro for Workstations”, I can reproduce this issue and have reported it to Microsoft to get it fixed. All other supported Win10-Editions (Pro, Enterprise, Education, Pro Education) are working as expected with Win10 20H2 and 21H1. I updated my blog-post today (11.06.2021) to point this out.
Microsoft fixed this issue with the “Pro for Workstations” SKU starting with Edge Version 93.0.932.0
windows 11 22000.282
works very well finally thanks
Works with Windows 10 LTSC N 2021 21H2.
Not working on Windows 10 IoT Enterprise LTSC 2021 21H2.
I already reported to Microsoft that the IoT LTSC 2021 Release is not recognized, see Microsoft TechCommunity – this SKU should be supported starting with Edge v100 which currently is in Beta.
Thank you for the feedback!
your MDM Fake worked for us like a charme. But no we have a problem with Win10 21H2 and Edge v100.
Old Windows 10 machines which where upgraded to 21H2 and Edge v100.0.1185.29 (via WSUS) -> works
Fresh Windows 10 21H2 install and Edge v100.0.1185.29 (via WSUS) -> dont’work
Can you verify that?
Test on 08.04.2022: Successfully tested with Edge v100.0.1185.36 (Stable) on fresh installed Windows 10 v21H2 Build 19044.1620 (Professional) from Microsoft provided original Media de-de_windows_10_business_editions_version_21h2_updated_march_2022_x64_dvd_eccaea10.iso (fresh installed and applied all available Patches then activated FakeMDM)
Thanks for Testing. We found the problem. It is not working with the Windows 10 Prof N Edition. Reverting back to the normal Edition solved the problem.
I reported the Problem with Windows 10 Pro N Edition to Microsoft, let’s see if it gets fixed in upcoming Edge-Releases.
Do the ADMX files change with every Edge update?
I just tried reusing my month-old download on a new install, and nothing was happening until I redownloaded the files for the newest build.
If the answer is yes, then I guess the logical follow up is do the definitions auto-update as new ones get released, or do you need to manually download and override them every time?
As Microsoft adds new Policies with each Edge-Version as well as some old Policies are phased out there are updated ADMX-Files regularly (each month). But there is no need to use this ADMX-Files and there is no need to update those with every new Edge-Version, especially if you don’t need those new policies or just configure the Policies not via MMC/GPO-SnapIn but just using Registry-Keys like I demonstrate in this blog post. The documentation for Microsoft Edge – Policies gives you all Information you need, the exact registry-Key as well as the Minimum Edge-Version for each policy to be supported.
Thanks for the response. I want to retract my previous statement that the older ADMX files weren’t working. They were! But I was transferring the comment.cmtx files in addition to the Registry.pol files which apparently makes the policies not stick on the new install. Now that I just transfer the Registry.pol files (i.e. actual GPOs) everything works!
One of the side effects of the Fake MDM patch is that Windows Defender/Security Real-time protection can no longer be turned off. Any ideas on how to prevent or fix this problem?
I had this issue on multiple systems and removing the MDM entries from the registry allowed me to change the Real-time protection setting again, so I’m sure it’s not caused by something else.
May you please check if you have any Defender Policies set (Registry-Tree: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Defender).
Is the account you are using a local account and member of the local administrators group?
No, I haven’t set any Defender Policies. The problem appears as soon as I apply the MDM entries and disappears as soon as I remove them.
I’m not aware of any side effects on Windows Defender/Security. Just re-tested to turn off Windows Defender Real-time protection: works as expected. I tried both common methods, interactively by mouse-clicking in Start -> “Windows Security” as well as using the Powershell “
Set-MpPreference -DisableRealtimeMonitoring $true”
(Both Methods like described in Detail here).
Both methods don’t work. I can click the button and execute the PS command, but nothing happens. The button immediately turns back to enabled and the command doesn’t do anything at all. These problems disappear as soon as I remove the MDM patch.
It happens to me in both Windows 10 and 11, no matter what version or language I use. One thing to note is that I apply the patch during Windows Setup, maybe that could have something to do with it?
Interesting. On my systems Fake-MDM-Provider Registry-Keys are applied after Windows Setup has finished, I cannot see a side-effect regarding the ability to turn off Windows Defender/Security Real-time protection. The only Side-effekt regarding Defender I’m aware of is that Defender Tamper Protection ist turned off on MDM-managed Devices (see last paragraph in my Blog-Post and Link to Microsoft Documentation).
I figured it out! My way of applying the registry keys during setup turned out to be the problem. My original approach was to edit the registry of the install.wim file directly, but then the problem as mentioned occurred. I solved it by applying the reg file with setupcomplete.cmd instead and now the problem no longer occurs.
Thank you very much for reserve engineering & documenting this, great work!
But it’s really outrageous that M$ won’t officially let us control all policies, not even in Enterprise edition unless you are using AD/MDM… As if it were not bad enough that they made more and more GPOs non-functional in Pro edition just to basically force all organizations to get Enterprise…
Crazy enough that I had to set up a WSUS server at home just to avoid my “production” systems from receiving “Preview” updates… This excellent work of yours at least “saved” me from having to set up a full blown AD domain at home as well 🙂
I’m so looking back to the good old Windows 7 time where even Home Edition was usable out-of-the-box without having to disable all of the spyware, call-home and more or less forced upon Cloud features that nowadays even the Enterprise version is infested with…
Is it possible if you can get this to work with Windows 11 Pro?
Yes, my Fake-MDM-Provider works with Windows 11 too.
Just to add: Tested on brand new Windows 11 v22H2 Build 22621.521 (Professional, Pro for Workstations, Pro Education, Education, Enterprise) on 22.09.2022 … successful.
Thank you so much for sharing this technical tip with the community! Would you happen to know how to make the native Google Chrome browser behave the same way as Edge with local group policies?
I don’t use Google Chrome, but as far as I remember at least up to v85 I could confirm it works with my FakeMDM-Provider. So just give it a try.
Thank you from Poland! I was looking for this everywhere … You should post this on Reddit and Microsoft QA websites, there are lots question about “new tab” -> blank page
Thx for this awesome trick, really appreciated 😉
Keep up the good work.
So very greatful for this great work. I have been looking for simmilar for a while now.
It is well discribed and works like a treat.
Sadly doesn’t work in my environment Win10 22H2 & Edge 108.0.1462.42
Edge browser still blocks MDM policys ㅠ.ㅜ
Did something change?
oh i see, my windows is Win10 Home T.T
Anybody help me, please
i must use this version…
As already described in my Blog-Post it is not possible to use these “sensitive” Policies on Home-Editions. There is no “workaround” or “trick” as this is check is coded into Edge.
chromium uses Shlwapi that uses NetGetJoinInformation to get the enrolment sate. One possible route is to make NetGetJoinInformation spit “true”.
erstmal vielen Dank für die vielen Tipps.
Ist es möglich, die Meldung: Your browser is managed by your organization zu entfernen?
Gibt es hier evtl. noch einen Registry Eintrag, den man setzten kann, damit diese Meldung nicht zu sehen ist?
Nein. Genau das, dass der Browser das Management als solches “anerkennt” ist ja Zweck dieses Fake-MDM-Providers.
danke für die schnelle Antwort.
Diese Meldung ist leider etwas unschön und verwirrend.
Ist es denn möglich, die Einstellungen zu setzen, ohne dass diese Meldung auftaucht?
Ich kann den Anwendungsfall wo das sinnvoll wäre gerade nicht ganz erkennen. Was ist daran “unschön” oder “verwirrend”? Verwirrend wäre es doch viel mehr, wenn der User nicht erkennen kann, warum diverse Einstellungen nicht durch ihn änderbar sind. Die Nutzung der genannten Policies erfordert ein MDM oder einen AD-Join (wie im Blog Post erläutert). Um welche “Einstellungen” geht es denn konkret? Man kann als Anwender ja ohnehin auch alles selbst konfigurieren, wird im JSON-Format in der Datei “Local State” im Edge-Profil persistiert. Wenn es also nur darum geht gescriptet einmalig ein paar Einstellungen zu setzen (die der Anwender dann aber jederzeit ändern kann) wäre das auch eine Möglichkeit.
Your registry settings have worked very well to allow home page settings. Thank you for your time and effort. I did find another side effect. That is the settings for DNS over HTTPS / Secure DNS are now blocked (greyed out) within Edge.
Thanks for this interesting finding.
Seems that Microsoft decided it is not a good idea to let End-Users configure DNS-over-HTTPS settings itself on a managed machine.
You can set DNS-over-HTTPs by policy, just tested – works:
This settings for example configure Cloudflare DNS-over-HTTPs, you can test the working configuration for cloudflare here: https://220.127.116.11/help
Hello, I found that if I boot WinRE and change TamperProtection in registry [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender\Features] from 0 to 5, it’ll turn back on.
Gunnar – I tried using this in hopes to test a PS script that checks MDM enrollment. No matter how I change EnrollmentType it still thinks my system is not MDM enrolled. It could be my script. Do you think its beyond the scope of fooling my script?
Mit den besten Grüßen
As I have no Idea what your script does I don’t can give any useful comment on this. Is your Script published on GitHub or anywhere else to have a look at it? My Fake-MDM-Provider doesn’t fake a “real MDM-Enrollment” but just the Minimum necessary to let think Edge the device is MDM-Enrolled.
Gunnar – This is the script. It checks the same MDM keys you set in an attempt to determine if a device is MDM enrolled. I figured your reg settings would be enough which is why I was surprised. https://github.com/wponder11/scripts/blob/main/get-mdmstatus.ps1
First your Script is missing a final closing “}”.
Second: If you like to change my Fake-MDM Provider to be recognised by your script just set following registry-Keys:
BUT: I don’t think checking EnrollmentType Value = 6 as “MDM” is correct. I have no Idea why your script does this. I just tested a “real MDM managed” Device, EnrollmentType is set to 0 on this device too. So your script would even answer “Not enrollen” on a real MDM managed device. So I suggest to just check for the existence of the UPN… but I really don’t know what you like to achieve.
Thanks, great contribution, it works! I’m running Edge 100.0.1185.50 Enterprise and plan to update to Microsoft Edge 110.0.1587.50 Enterprise soon, Windows 10 Enterprise IoT LTSC 2021 (version 21H2).
BTW after joining fake domain I experience occasional lag when moving icons on computer’s Desktop like described here: https://community.spiceworks.com/topic/2262807-windows-10-pro-desktop-icons-lag-when-moving The lag is not related to number of icons moved (happens even with one icon), and it gets back to normal after a while (30 sec). Maybe there’s a known fix for that? P.S. Happens also when Windows Defender is turned off completely.
I cannot see any connection between MDM/Fake-MDM and any “lag when moving icons”. Your link points to a post which dates back to year 2020, so it uses totally different OS & Kernel-Version. Never saw such “lag when moving Icons”.
Tested on Windows 2016 server with Edge 113.0.1774.50, Fake MDM still works.