Apply all Edge Policies like HomepageLocation, DefaultSearchProvider, … for non-Domain-joined Devices

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”.

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):

Local Group Policy Editor, Edge Policies – some of them resticted to AD-joined-Machines

Fake MDM-Provider?

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 an honors to apply the restricted Policies like HomepageLocation, NewTabPageLocation, RestoreOnStartupURLs, DefaultSearchProvider, SmartScreen and several more without domain-joining the Devices.

Some of the Fake-MDM-Provider Registry-Keys

Download the needed reg-Files

I provide you a single zip-File which contains 3 Files:
1. MDM-FakeEnrollment-Win10_v1809_v1909.reg … the Registry-Keys you have to add to let Edge “feel” like the Win10-Machine is MDM-Managed.
2. EdgeChromium-Policies.reg … some sample policies like configuring Google as Search-Engine, Homepage, New-Tab-Page etc… – this works after the MDM-FakeEnrollment is applied.
3. EdgeChromium-UpdatePolicy-SideBySide.reg … this (fully optional) Policy you may like to set to keep old EdgeLegacy available when installing EdgeChromium.

Just import the 1st one (MDM-FakeEnrollment-Win10_v1809_v1909.reg ) to enable the “Fake-MDM-Provider”. Use the 2nd one (EdgeChromium-Policies.reg) to import my sample configuration (like shown in the next screenshot) or use your gpedit.msc (Local Group Policy Editor).

Local Policies for Edge (based on Chromium)

When using the Group Policy Editor you need the admx-Files for Edge based on Chromium from Microsoft, you can download them here: (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).
  • Update 09.02.2020: Successfully tested with Edge v80.0.361.48 (Stable) up to v82.0.418.0 (Canary)
  • Update 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)
  • Update 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)
  • Update 12.10.2020: Successfully tested with Edge v86.0.622.38  (Stable) up to v87.0.658.0  (Dev) on Win10 v1909
  • Update 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

Edge Releases

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

Edge-Policy Overview edge://policy

You May Also Like


  1. 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?



    1. Hi Phil,
      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.

      1. Hi Gunnar,

        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 :
        -pro activation
        -edge GPO/MDM status

        i rebuilt N image twice and always the same

        on a side note, have you ever tried
        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

        1. I always use the official ISO-Files from, 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.

          best regards,

  2. Tested with Windows 10 2004 and Edge Chromium 83.0.478.45 and it’s not working 🙁

    i use the reg file.

    NewTabPageLocation Value Error This policy is blocked – its value will be ignored.

    I don’t know what to do… any suggestion?

      1. 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).

        1. 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.

          1. 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.

  3. Der regitryhack funktioniert immer noch auc unter Windows 2004h1
    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:
    DefaultSearchProviderEnabled (Standardsuchanbieter aktivieren) = True
    Richtlinie blockiert, dadurch funktionieren auch die folgenden Einstellungen nicht:
    (als Admin möchte ich schon eigentlich eine einheitliche Suchmaschine vorgeben können)
    noch eine sehr wichtige Einstellung die blockiert ist und nicht funzt
    MetricsReporting Enabled = false (Meldung von nutzungs und absturzbezogene Daten aktivieren) Richtlinie blockiert. Ein Schelm, der Böses dabei denkt.
    HomepageIsNewTabPage (Neue Tab Seite als Startseite festlegen) = true Richtlinie blockiert
    HomepageLocation (Homepage URL konfigurieren) Richtlinie blockiert
    NewTabPageLocation (URL für die neue Tabseite konfigurieren) Richtlinie blockiert
    RestoreOnStartup (Aktion, die beim Start ausgeführt werden soll) = 5 (neue Tabseite öffnen) Richtlinie blockert
    RestoreOnStartupURLs (Websites, die beim Start des Browser geöffnet werden soll) Richtlinie blockiert.

    1. Dear Dette,

      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.

      1. Hallo Gunnar,

        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.

    2. 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.

  4. 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.

    1. 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.

    2. 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.

  5. Dear Gunnar,

    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!

    1. 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.

      1. 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!

        1. 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”.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.