Intune Policy Processing on Windows 10 explained

In this post I will dive into the Intune policy processing on a MDM managed Windows 10 client. Intune is an MDM system and has the ability to deploy so called device configuration profiles to managed Windows 10 endpoints. We will have a look at the architecture, the settings, and the actual processing including the refresh behavior. I cover the current technology and what has changed with Windows 10 version 1903.

To better understand the processing, we first need to understand the components involved in the process. There is the MDM system (Intune) and the MDM client on the Windows 10 OS. The roots of the MDM client are based on Windows Mobile. Today Microsoft provides us the MDM client also on Windows 10. The MDM system and the MDM client are working together to exchange data based on the Open Mobile Alliance Device Management (OMA-DM) protocol (more from Microsoft here). This is a common defined standard and uses a XML-based SyncML format to push the information to the client. As transport layer HTTPS is used. This is vendor independent and is used for Android and iOS management as well. This builds the architecture to transfer instructions in a standardized way to the endpoints. On the client side there are so called Configuration Service Providers (CSP’s). These components are responsible to read, set, modify, or delete configuration settings on the device.

Interesting, sounds somehow familiar!?

Yeah, right as it is basically the same architecture as we had in an on-premises domain. There was the domain controller (DC) (compare: MDM server) and the DC provided the sysvol folders with policy files. On the client side we had the group policy service (compare: MDM client) which simply used a SMB connection (compare: HTTPS) to get the files from the sysvol folders (okay there was a little bit more involved in that process like authentication, GPC lookup, etc, but for this comparison I simplify it a little bit). The Windows client had so called Client Side Extensions (CSE’s) (compare: CSP) to process the input files and finally do the configuration. So, this is basically the same approach but with MDM it is standardized and designed to work perfectly over the air. You can think of the MDM stack as a logical evolution of the domain group policy processing.

The input files on a domain client may be different depending on the CSE. Often a .pol file, sometimes a .ini, or a .xml file. In the modern MDM stack, this input was standardized (XML) and the instructions are built up in a tree structure.

Configuration service profider tree structure CSP

This makes it possible to transfer commands in so called OMA-URI’s (Open Mobile Alliance – Uniform Resource Identifier) which is basically a path to a specific CSP and setting. For example below, the path to enforce a Logon screen image via the Policy CSP:

./Vendor/MSFT/Policy/Config/DeviceLock/EnforceLockScreenAndLogonImage

The complete architecture is now demonstrated in the figure below:

MDM architecture and client side CSP's

In Intune the OMA-URI’s are hidden in nice configuration interfaces to make the daily life simpler, but in the background the management interface will use OMA-URI’s to configure the settings on the device. Here the example of an UI build for the specific “Locked screen picture URL” setting:

Intune device restriction profile Locked screen picture URL

The same setting can be set directly by using the OMA-URI:

./Vendor/MSFT/Policy/Config/DeviceLock/EnforceLockScreenAndLogonImage

Intune does provide us the ability to configure custom OMA-URI’s, but if a separate UI element is available, I would use that instead of dealing with OMA-URIs. This make it easier for management and review.

Intune custom profile OMA-URI EnforceLockScreenAndLogonImage

The nice thing about the ability to configure custom OMA-URI’s is, that we are able to control settings as soon as they are introduced on the client side (Windows 10) and we do not need to wait for Intune to build an UI explicitly for it.

In addition to native CSP implementations in Windows 10, Microsoft uses a technique called ADMX-backed policies. This is a clever move to make important policies shipped with Windows 10 accessible by compiling them into MDM policies during OS-build time. In addition to that, it is even allowed to ingest new policies and compile them to new MDM policies (e.g. Google Chrome ADMX policies). This allows us and Microsoft to easily make policies available for MDM configuration. During usage of ADMX-backed policies we need to take special care about the configured values, they follow a specific notation. Especially for ingested policies we need to be careful about the OMA-URI’s. To dive into that topic I really recommend to carefully read the article here Understanding ADMX-backed policies, which provides great details on the whole process. For custom ADMX ingestion read carefully this article Win32 and Desktop Bridge app policy configuration. One advice here: ADMX ingestion is not very easy and intended for third party ADMX ingestion. There are a lot of pitfalls in the process (false OMA-URI construction, case-sensitive URI’s, wrong value referenced, etc).

The architecture behind the MDM stack and configuration profiles (settings) in Windows 10 should be clear now, but what about the actual processing of the configuration settings. Let’s have a look into that in the next section.

What about the actual processing?

This is actually very simple process. The client receives the configuration settings via the SyncML document data push and the transferred OMA-URI maps to the corresponding CSP. The targeted CSPs are responsible for configuring the settings. For example, if the setting controls a registry value, the value will be set according to the definition in the policy. Following an example for the Policy CSP configuring the setting AllowDeviceNameInDiagnosticData, which controls the transmission of the device name to Windows Analytics (more regarding this setting in my article Windows Analytics onboarding with Intune). This setting results in a registry value AllowDeviceNameInTelemetry set to 1.

registry AllowDeviceNameInTelemetry policy setting

If the policy changes on the MDM server, the updated policy is pushed down to the device and the setting is set to the new value or the old value is enforced. If a setting should be the default value again the setting must be configured to the default value again. Removing the assignment of the policy from the user or device does not revert the setting automatically to the default value. If we compare this with GPOs, we would call this tattooing. The setting stays there until it is configured to a different value, even after removing the assignment of the policy.

There are just a few profiles currently, which are removed after the assignment is removed or the profile is deleted. These profiles are:

  • Wi-Fi profiles
  • VPN profiles
  • Certificate profiles
  • Email profiles

All other profile types are not removed.

Settings will remain on the device, they are tattooed!

More information regarding troubleshooting can be found here: Troubleshoot device profiles in Microsoft Intune

What about a policy refresh?

Until Windows 10 version 1809 there is essentially no real policy refresh like we know from the GPO, where security policies are enforced regularly without special configuration. GPO registry policies are enforced every 90+offset minutes (when the group policy registry processing is configured accordingly). So, MDM policies are only enforced when a change occurs on the Intune service side.

Wait, no policy refresh?

What happens if someone changed a value? The answer is simple, it is not enforced and reverted to the configured value, as long as the policy does not change on the Intune service side. As long as an enterprise uses standard user permissions on the clients, this does not introduce a big problem, as the settings can’t be changed by the users. Remember that the MDM stack has its roots back from Windows Mobile. There was no administrative user and the MDM channel was the only authority to change settings on the device. Nevertheless, settings enforcement is something most people want to have. Not every enterprise is running their clients with standard user permissions. Luckily Microsoft addressed this and changed the behavior with Windows 10 version 1903. Starting with Windows 10 version 1903 the policies are regularly refreshed (enforced) on the device.

Windows 10 version 1903 enforces MDM settings regularly!

So, there should be no settings drift anymore after upgrading to Windows 10 version 1903. Currently the Policy CSP is the only CSP which is enforced regularly. This might change in future but that’s the current state.

The interval when the enforcement is done, is the regular 8h device sync interval (see here for more sync interval details).

My test setup was Windows 10 version 1903 July update and I picked two Policy CSP settings. One located in the PolicyManager hive which is the MDM settings hive and the other one in the Policies\Microsoft GPO hive. I wanted to see if settings, located in various places are tracked and reset accordingly.

MDM PolicyManager hive setting - ConfigureTelemetryOptInSettingUx
MDM PolicyManager hive setting – ConfigureTelemetryOptInSettingUx
GPO Policies hive setting - AllowDeviceNameInTelemetry
GPO Policies hive setting – AllowDeviceNameInTelemetry

I changed both values from the configured value 1 to 0. Then I tested the reset behavior.

  • Restart of the device -> no reset, still values of 0
  • Manual Sync -> no reset, still values of 0
MDM manual sync Windows 10
MDM manual sync via Windows 10 Settings

Triggering the scheduled 8h interval manually via Computer Management > Task Scheduler Library > Microsoft > Windows > EnterpriseMgmt > GUID > Schedule #3 created by enrollment client, I see instant reset to the policy configured values!

Windows 10 task scheduler MDM sync 8h interval

This is really great news, as this is the behavior most people expect.

Some basic troubleshooting advice?

For troubleshooting of MDM policies, I recommend to have a look at the MDM Advanced Diagnostic report. It can be generated via Windows 10 settings and will be stored under: C:\Users\Public\Documents\MDMDiagnostics\MDMDiagReport.html,

MDM Advanced Diagnostic Report Windows 10 Trigger

This report can give you detailed insights if a policy is received, what the default value is, which value is set (Current Value), and which value should be set (Config Source):

Windows 10 MDM advanced diagnostic report html

I hope this drives general understanding of MDM policies and processing of them on a Windows 10 device. The change in Windows 10 version 1903 is more than welcome in my opinion. I think Azure AD joined devices, correctly configured to ensure proper cloud and on-premises resources access, is the way forward. For me it has less complexity then hybrid joined devices and taking GPO’s out of the game and moving on to MDM policies is more than a logical step for me. Focusing on “light management” and concentrating on the important settings you really need to configure. These settings are in general the security settings and mostly some corporate identity settings (same lock screen). In the meantime, Microsoft is adding more and more settings to cover all enterprise setting requirements with MDM policies. Lastly they added support for additional 2500+ Windows and Office settings via Administrative templates in Intune.

The idea of zero trust networking, no dependency on any network location, but the ability to configure via MDM and monitor all your endpoints around the globe (in all possible network situations like public Wi-Fi, cellular, home network, corporate network, etc.) is a great thing. As a cloud solution this comes without complex on-premises infrastructure setups. In fact, with Intune we did that for the mobile devices all the time before. Start thinking of your Windows 10 clients like a real mobile device, like an iPhone or Android device. Establish the idea of unified endpoint management and configure them wherever they are.

Happy modern management!