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.
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:
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:
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.
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.
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 (see Update below on this!). 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
!UPDATE on the tattooing behavior (18-02-2020). Tattooing does not occur in general anymore, the CSP is responsible how to handle the removal:
Quote from Assign user and device profiles in Microsoft Intune:
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.
see my follow up article on the new behavior here:
Changed Intune Policy Processing Behavior on Windows 10
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.
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
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!
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,
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):
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!
Modern IT - Cloud - Workplace 
If we setup a new policy and initiated a manual sync sometimes it takes a time for the policy to land. Can we speed this up by starting the ‘Schedule #3 created by enrollment client’ ? And does this also work for PS scripts?
Great blog post once again, very informative. You get Some of this information from Microsoft (NDA) to make a blog post about 🙂 ?
PS. Do you know something about the implementation status of the option to exclude devices/users from a group from a assigned policy?
Hi RKast,
no it won’t speed up the process. The issue you are describing is just based on the Intune service (maybe load or other factors on the back end infrastructure) and the time it need to deliver policies. The sync is not that different, yes it is different as it enforces values in the regular 8h interval, but the sync is the same and as long as the service side is not providing the policy you have to be patient. PS scripts are not enforced. The enforcement is based on the Policy CSP only. PS scripts are run by the Intune Management Extension (IME), that’s a different path.
These information is in general based on my excessive testings for all kind of cloud-only scenarios. Then you find all these small pieces and build a big picture, triggers, storage locations, processes, architecture and so on. When you do tests then, you are checking a lot of things to understand deeply the process and often you find small changes as well 👍. And of course close contacts to Microsoft helps always and is good to have 😊.
Regarding the mixed include/exclude I do not have further information right now.
best,
Oliver
Have you tried testing by only editing the ‘legacy’ registry location e.g. HKLM\Software\Policies\Microsoft\Windows\DataCollection
Then do a sync. You will prob find that the value isn’t updated.
In testing here, the legacy registry locations are not updated unless the corresponding PolicyManager value is edited as in your example. We have asked Microsoft about this and they have avoided the question everytime.
Wonder if you can delay on applying an oma-uri policy.
i am applying one to remove the local admins, but it interrupt the autopilot with a UAC (i beleive its taken out the default0 autopilot user out of the admin group)
Hey RG,
Sorry for my late response. There is no built in way to delay a policy. The only thing you could build yourself is something like detecting a finished installation and then triggering a Azure function or runbook to add the device to a AAD group which is bound to a profile. This would then result finally in deploying a profile to the device in delayed way. But it would require to find a good trigger on the client side which calls the backend side to finally put the device in a AAD group. …complicated… never heard the requirement to do something like this until now…
best,
Oliver
Great article, very useful
Great post,
One question I have one setting (Delivery Optimisation, download Mode) which is flagging as a conflict, so I would assume i’ve got two policies each trying to set a different value, and i’m trying to identify the two policies, it would appear that the endpoints know nothing of configuration policies only the individual settings?
Hey Huw,
on the endpoint it is quite challenging as you have some traces in the registry but they are mostly based on GUIDs and things like that. So not a clear advice here, look there and there is the name of the conflicting policy. I do typically divide and conquer strategy to isolate the problematic policy. This brings typically quickly results.
best,
Oliver
Thanks Oliver , you are the MAN !
Just want to know when we create any device configuration profile for any platforms ..so when we click on create what exactly happens in the backend ?
Sorry for my delay, sometimes it is hard to keep up. On clicking create you are technically calling a graph endpoint from Microsoft. Microsoft Graph ist the API for the cloud management in the MS ecosystem. So, you call this API with a http POST request (e.g. https://docs.microsoft.com/en-us/graph/api/intune-deviceconfig-windows10generalconfiguration-create?view=graph-rest-1.0) and in this request, there is the configuration you chose in the portal, encoded as a json representation. This will then be processed from the MEM back-end services and your profile is created.
Does this explain what you are looking for?
Hi we are trying to implement Intune in Co manage mode . We recently onboarded some W10 devices and we are applying the default Intune POlicy which I believe it uses the APP locker CSP settings . I found out thru a series of blogs that the APP locker CSP forces a reboot immediately when a device gets added to End point manager.
I have been trying to find the solution to stop this from happening , do you know what CSP can disable the automatic reboot?
Hey,
Windows Defender Application Control does enforce a reboot, so check your config and remove this setting and the reboot should not happen anymore.
best,
Oliver
I have the problem of removing intunes and eas policies from windows 10.
. I got a couple of kiosk machines. which even after leaving the domain and uninstalling microsoft intunes mdm extension
bad behaviour
EAS registry policy. I have to write a powerscript to delete the whole key. it keeps coming back., thus breaking autoadminlogin.
intunes mdm extension keeps being reinstalled even after being uninstalled and everything cleaned up for task scheduler. not sure what is responsible for this.
forcing local admin logon to change password on login. again breaks autoadminlogon. does not appear to be password length or complexity issue. even a long password that is complex gets requested to change on logon.
Hey Chris,
for Kiosk you better exclude your devices form all policies and just apply a dedicated Kiosk policy set. As you already mentioned password policies will break autologon. This includes also a compliance police set with password rule (this policy will also enforce the change). Intune Mgmt extension will be installed over and over again, as long as you ave any Win32 app or PS script assigned.
Since we have filters now you can easily build a Filter to exclude maybe devices starting with hostname “kisok-” to accomplish an easy exclusion (https://docs.microsoft.com/en-us/mem/intune/fundamentals/filters?WT.mc_id=EM-MVP-5003177).
best,
Oliver