Group Policy has been around for 20 years but as more organizations look to manage an ever-mobile workforce, Mobile Device Management is often better suited to configuring and securing Windows endpoints. In this article, we’ll discover how Mobile Device Management policies are processed in Windows.
Group Policy settings are not tattooed onto the registry
Windows has several different management technologies built in that organizations use to secure and configure servers and end-user devices. Group Policy was introduced in Windows 2000 as part of Active Directory (AD), replacing Windows NT System Policies. Group Policy is a powerful tool that can reduce total cost of ownership by helping IT to maintain standard configuration settings on Windows servers and PCs.
MDM is designed to work without Active Directory
Group Policy is still the tool of choice for managing AD domain-joined devices that spend most of their time connected to a corporate intranet and/or for granular control of Windows settings. But as more employees work remotely and companies move management technologies to the cloud, Microsoft has added support for Mobile Device Management (MDM) to Windows.
MDM is a technology, like Group Policy, for managing configuration settings. But MDM is designed to work without Active Directory.
MDM Configuration Service Providers
MDM Configuration Service Providers (CSP) are similar to Group Policy Client-Side Extensions (CSE). Each CSP is responsible for managing a defined group of configuration settings in Windows. For example, there are Network and Defender CSPs that are responsible for managing network and Windows Defender settings, respectively.
Until recently, most CSPs tattooed settings. Meaning that if an MDM policy was removed from a device or user, the settings were not reverted to their original values. Although there were some exceptions to this rule, like settings configured in Wi-Fi, VPN, Certificate, and Email profiles.
But this behavior has now changed and been rolled back into currently supported versions of Windows 10. According to an article on Microsoft’s website:
When a profile is removed or no longer assigned to a device, different things can happen, depending on the settings in the profile. The settings are based on CSPs, and each CSP can handle the profile removal differently. For example, a setting might keep the existing value, and not revert back to a default value. The behavior is controlled by each CSP in the operating system. For a list of Windows CSPs, see configuration service provider (CSP) reference.
To change a setting to a different value, create a new profile, configure the setting to Not configured, and assign the profile. Once applied to the device, users should have control to change the setting to their preferred value.
When configuring these settings, we suggest deploying to a pilot group. For more Intune rollout advice, see create a rollout plan.
Most CSPs in Windows 10 no longer tattoo settings, making the behavior of MDM profiles similar to Group Policy settings. But you should bear in mind that while Windows 10 now supports non-tattooed MDM settings, this behavior is dependent on each individual CSP.
Now you understand more about how MDM settings are applied in Windows 10, let’s look at how MDM policies are processed.
- The Windows MDM client receives the configuration settings from the MDM service.
- The Open Mobile Alliance – Uniform Resource Identifiers (OMA-URI) in the configuration file define the settings to be configured on the client.
- The OMA-URIs are mapped to the relevant CSPs on the client, which then handle modifying settings if necessary. OMA-URIs are not directly visible in Intune, Microsoft’s MDM solution.
- If a policy changes on the MDM service, the new policy is sent to the client and the CSP updates the setting(s) as required.