Windows 10 MDM vs Group Policy: 4 Risks You Cannot Ignore

Windows 10 MDM allows for management by 3rd-party services using the built-in MDM protocol. As more organizations consider a Windows 10 MDM solution, an obvious question arises: does Windows 10 MDM replace Group Policy? Can we do everything with Windows MDM that we did with Group Policy? How do we evaluate the risks of moving to MDM from Group Policy? After all, both of these tools deliver managed settings and can deploy applications. This blog post intends to compare Group Policy with Windows 10 MDM and demonstrates how both systems can work together effectively to manage Windows 10 endpoints.

Do You Need Windows 10 MDM and Group Policy?

There is some confusion concerning the roles that Windows 10 MDM and Group Policy play. Before we dive into the risks, we’ll review some basic principles.

What is MDM?

MDM stands for Mobile Device Management. You can use MDM to manage client devices. Using MDM, an administrator can deliver and enforce desired configuration settings and security policies, and deploy applications. MDM also gives you the ability to remotely wipe a device if it were lost or stolen. While its name implies that it only applies to mobile devices such as phones, tablets, and laptops, MDM can also manage traditional desktops.

What is Group Policy

Group Policy is a mechanism to deliver bundles of settings to users or computers. Group Policy requires Active Directory (an on-prem directory service which contains USERS and COMPUTERS).

Comparing MDM vs. Group Policy

Group Policy has been used to manage domain-joined computers for almost two decades. By creating Group Policy Objects (GPOs), you can deliver settings, enforce security, restrict software, deploy applications, and assign printers and network drives. In short, you can do a lot with Group Policy.

On the surface, it looks like MDM and Group Policy accomplish the same goals. The major difference between Windows 10 MDM vs Group Policy is that they each work in different environments. For example, Group Policy only supports domain-joined machines in a traditional Active Directory environment. Conversely, a Windows 10 MDM provider like Intune only supports MDM-enrolled machines that reside in a cloud tenant like Microsoft Azure. With MDM, machines can be non-domain-joined, or hybrid domain-joined (on-prem Active Directory vs Azure Active Directory).

MDM and Group Policy cannot be substituted for each other exclusively. Your IT department can have traditional domain-joined desktops and servers and MDM-enrolled devices. Smaller organizations with fewer resources may be a cloud-first enterprise and host everything in Microsoft Azure. However, larger organizations with legacy infrastructure may continue to manage Active Directory–only environments.

Risk #1: Windows 10 MDM Settings for the Control Panel Are Weak

Managing the Windows 10 Control Panel is critical for security and desktop standardization. Today, Microsoft Intune only manages 16 Control Panel Settings, while Group Policy manages 50 settings. Group Policy allows you to manage key components like “Add or Remove Programs,” “Printers,” and “Programs.” Windows 10 MDM software does not provide the same functionality.

Windows 10 MDM Control Panel Group Policy

If you plan to manage the Windows 10 control panel with MDM exclusively, you risk gaping security holes. MDM alone will not allow you the same granularity and flexibility as Group Policy.

Risk #2: Windows 10 OMA-URIs Are Limited and Difficult to Configure

When you configure a setting in Windows 10 using the Intune GUI, that setting is delivered through a corresponding configuration service provider (CSP). A CSP is a component of the Windows 10 operating system and gives MDMs the ability to apply device-specific settings. Now there are more CSP settings available than are currently covered by Intune, which means that there are more possible settings to configure than there are clickable options within the Intune interface.

So how do we configure settings on a CSP that doesn’t appear within Intune? Well, that is where the role of custom profiles comes into play. Custom profiles are necessary when you want to manage device settings and features that aren’t built into Intune. Customer profiles can be created for multiple platforms including Android, iOS, and Windows 10. Windows 10 MDM custom profiles use something called the Open Mobile Alliance Uniform Resource Identifier (OMA-URI) to configure settings and features. These settings, for the most part, are provided by a special CSP called the policy CSP. To create a custom OMA-URI Intune Windows 10 setting, you need to provide the following information:

  • Name for the customer setting (this can be anything)
  • Description of the setting’s purpose/li>
  • The OMA-URI path for the setting
  • The data type used by the setting
  • The designated value for the setting

Examples of OMA-URI Challenges

For instance, let’s say you want to disable the cameras of the Windows 10 laptops used by some of your staff. While there is a clickable setting within Intune to deny apps access to the camera, there isn’t a clickable setting to outright disable the camera. There is, however, a CSP setting within Windows 10 that allows you to do that. The setting is registry-based and uses a 0 or 1 to disable or enable. The following image shows how you would create OMA-URI settings for windows 10 MDM.

So how do you know what the Windows 10 OMA-URI path is for each customized setting you want to deliver?
Well, you don’t know without performing some research.

While Microsoft does have plenty of documentation concerning available CSP settings, it isn’t a process that Group Policy admins are required to do. There is also a significant shortcoming concerning the use of custom OMA-URI profiles, in that you cannot target them based on conditions, which you can do with any of the included clickable Intune settings.

Additionally, when it comes to removing or revoking custom URI policies, you must write another profile which undoes the setting. In Group Policy, well-behaved items will typically do this automatically.

Risk #3: Windows 10 ADMX Templates Don’t Play Nice with Windows 10 MDM

Starting in Windows 10 version 1703, something new happened in MDM. Group Policy admins have been working with it for a long time. You could say that, with 1703, MDM brought in something old and made it new. That new old thing is ADMX-backed policies.

In an earlier screenshot, you may have seen the Windows 10 ADMX Template (Preview) option available in the Profile Type menu. Unfortunately, you cannot view the available settings when selecting this profile type like you can when choosing the “Device restrictions” option. You can only review the available settings after creating the profile and then accessing it.

At this writing, there are around 270 available settings (again, curated, guaranteed settings). Most of these are dedicated to Office, Internet Explorer, and OneDrive. The following screenshot shows some of the available settings listed in alphabetical order, and there is no hierarchal view. You must know the setting you are after by using the “Search to filter items…” bar seen in the image.

Windows 10 MDM ADMX Template

Importing Windows 10 ADMX Files

What about Microsoft and non-Microsoft third-party Windows 10 ADMX files? Currently, Intune does not offer the ability to import Windows 10 ADMX files with the ease that Group Policy offers. Importing Windows 10 ADMX templates into Group Policy is as simple as placing the designated Windows 10 ADMX file into the central or local store.

For Windows 10 MDM, you have to perform a procedure that Microsoft calls, ADMX ingesting. In order to ingest a Windows 10 ADMX you must open the file in some type of editor such as Notepad. For this example, I’m going to use the OneDrive Windows 10 ADMX file. I’m not going to show what the entire file looks like in Notepad, but here is what the first part of it looks like:

<?xml version="1.0" encoding="utf-8"?>
<policyDefinitions xmlns:xsd="" xmlns:xsi="" revision="1.0" schemaVersion="1.0" xmlns="">
 <target prefix="OneDriveNGSC" namespace="Microsoft.Policies.OneDriveNGSC" />
 <using prefix="windows" namespace="Microsoft.Policies.Windows" />
 <resources minRequiredRevision="1.0" />

To use it, you then need to create a custom profile for the new Windows 10 ADMX. The next step is to define it as a custom setting (known as a custom Windows 10 OMA-URI settings block). Then, you need to copy the contents of the Windows 10 ADMX file into the text box. An example of this is shown next.

OMA-URI Settings

ADMX Ingestion Challenges

As you can see, this can be an arduous process and is intimidating for some. And this is just the first part. After the configuration Windows 10 ADMX is uploaded you need another custom Windows 10 OMA-URI just to manipulate the actual setting you want… one by one. One can hope that the ADMX import process will be simplified over time.

Additionally, note that when Windows 10 ADMX files are upgraded over time, Windows will not erase the ADMX files when they’re placed upon the machine or block new ADMX files.

This point is counterintuitive, but apparently, the MDM engine cannot handle this situation. When you attempt to completely replace the ADMX definitions for a custom application, it just doesn’t work.

The “fine print” reasoning is in the PolicyCSP docs (

Do you see the problem? This part of Windows 10 MDM “. . . does not support Delete.”

When you’re using an upgraded Windows 10 ADMX the result is (at least) an error in the Microsoft | Windows | DeviceManagement-Enterprise-Diagnostics-Provider logs, which you can see here in event 454.

Event 454 Windows 10 MDM Error

Options for Windows 10 ADMX Templates

So how do you get out of this jam when you upgrade a Windows 10 ADMX file? You have a few choices:

  • Choice 1: Create a new profile expressly for the newer application
  • Choice 2: Run some custom cleanup PowerShell script beforehand to scrape the data out of the registry manually. Your goal would be to remove the HKLM\Software\Microsoft\PolicyManager\AdmxDefault\{GUID} data which stores the ADMX contents
  • Choice 3: Use PolicyPak MDM to deliver the setting using PolicyPak Admin Templates Manager, PolicyPak Preferences Manager, PolicyPak Application Manager, or PolicyPak Preferences. When the value needs to change, PolicyPak changes it

Risk #4: Windows 10 MDM Has Fewer Settings Available than Group Policy

So as of this writing, Intune has about 300 curated Windows 10 MDM settings you can select, plus approximately 300 available via Intune’s Administrative Templates function.

We are using the word curated to indicate that the MDM team at Microsoft has indicated that these settings are guaranteed to work in cloud-specific scenarios.

You might be interested to know how many settings are covered:

  • By Intune and not Group Policy, and
  • By Group Policy and not Intune

MDM vs Group Policy

Description Count
Windows 10 MDM Settings exclusive to Intune (and not in Group Policy) 48
Computer Side Windows 10 ADMX Settings shared by Group Policy and Intune 655
User Side Windows 10 ADMX Settings shared by Group Policy and Intune 232
Computer Side Windows 10 ADMX Settings only in Group Policy 1,813
User Side Windows 10 ADMX Settings only in Group Policy 1,499

So in an Intune-only world, you are missing out on 3,312 Group Policy ADMX settings.

Keep in mind, too, that many of the Windows 10 ADMX settings that are available in Intune are not existing settings, but only become settings if you create custom policies.

Moreover, there is Group Policy Preferences, as shown in the following image. When you consider Group Policy Preferences, the number of missed settings grows to about 10,000.

How is that possible?

Well, let’s look at some commonly used Group Policy Preferences setting categories.

Group Policy Preferences vs MDM

Category Has Group Policy Preferences Coverage Has MDM Settings Coverage
Data Sources Yes No
Printers Yes No
Drive Maps Yes No
Folder Options Yes No
Registry Settings Yes No
Services Yes No
Shortcuts Yes No
Scheduled Tasks Yes Yes (Partial)
Local Users and Groups Yes Yes (Partial)

Windows 10 MDM has a total void in these valuable setting categories. What about Scheduled Tasks? Well, you can schedule a reboot for your MDM-enabled devices in Intune, because there is a CSP called Reboot CSP. In other words, you can only create the few scheduled tasks for which there is a designated CSP. Of course in Group Policy Preferences, you have the freedom to create any scheduled task you want.

What about Security Settings, which you can see in the following image?

While Intune includes just as many Password settings as Group Policy, it has none in other categories.

Intune Settings

Category Name # of Group Policy Settings # of Intune Settings Settings
Password Policies 6 7
Account Lockout Policies 3 0
Kerberos Policies 5 0
Audit Policies 45 0
Security Settings 106 0


Windows 10 MDM doesn’t come close to the extensive coverage that Group Policy offers. With Group Policy, administrators can manage some 4,000 Windows 10 ADMX settings. Then, if you factor in Group Policy Preferences, which have around 10,000 unique combinations and settings, you’re up to about 14,000 Windows 10 ADMX settings.

The additional benefit of Group Policy Preferences is that it also provides a GUI interface that emulates the component you are configuring. A lot of the Windows 10 ADMX settings utilized by Group Policy are legacy settings from years ago, and MDM is only thinking forward. We can only assume that Microsoft will extend the clickable setting coverage of Intune and the coverage gap will close as time goes on.

Windows 10 MDM or Group Policy: Final Thoughts Summary

When contrasting MDM and Group Policy, there is no right or wrong answer. Group Policy continues to serve as a staple in the Domain Admin’s trusted tool kit. At the same time, MDM is drawing much interest, and rightly so, since so many organizations are choosing to host some of their devices, users, and applications in the cloud.

MDM is most definitely a useful tool that will play a more significant role as time goes on. However, MDM and Intune have definite limitations for the time being.

Those who are used to the extensive setting and feature coverage of Group Policy need to bridge the gap in some way. This action can be done the hard way with custom OMA-URIs and PowerShell scripts, or the easy way using PolicyPak MDM.

MDM and Intune are also not trying to solve some more significant, common Enterprise desktop management problems. For instance, removing local admin rights, managing multiple browsers and Java environments, as well as dealing with making a dynamic Start Menu or dealing with Windows 10 default file associations.

The good news is that it doesn’t have to an either-or scenario. We suggest you check out PolicyPak MDM Edition.

Use PolicyPak to Deploy Group Policy Settings via Your Windows 10 MDM Service

PolicyPak MDM edition works alongside your MDM solution like Intune. Its major features are:

  • Delivering almost all Group Policy, Group Policy Preferences, and Group Policy Security settings through Intune. Just export the GPO settings and go (see the image below)
  • Removing local admin rights and ensure users can bypass UAC prompts
  • Blocking malware before it gets on the machine
  • Managing Windows 10 Start Menu and Taskbar
  • Managing Windows 10 File Associations

And more.

Remember: PolicyPak MDM isn’t an MDM service. You create policies using Group Policy then export them. It then works alongside your Intune or other MDM investment to add more horsepower where your MDM service needs it.

Hundreds of companies use PolicyPak MDM to take their existing on-prem Group Policy settings and deliver them with Intune. And so can you.

With PolicyPak, it doesn’t have to a domain-joined or non-domain-joined world. You can deliver PolicyPak’s unique settings plus real Microsoft Group Policy settings to all of your Windows computers.

To get started with PolicyPak MDM Edition, click here.

With PolicyPak MDM, you can indeed have it all.

Jeremy Moskowitz

Founder & CTO, Microsoft MVP in Group Policy, Enterprise Mobility, and MDM

Jeremy Moskowitz founded PolicyPak Software after working with hundreds of customers with the same problem they couldn’t manage their applications, browsers and operating systems using the technology they already utilized.

Ready to Get Started? Register for Our Demo.

Our PolicyPak Demos explain everything you need to know to get started with the software. Once you've attended the demo, you'll be provided a download link and license key to start a free trial.