By: Oliver Kieselbach
Articles, Enterprise Mobility, Intune, Modern Management, Troubleshooting, , , ,

Changed Intune Policy Processing Behavior on Windows 10

A year ago I explained the policy processing in Windows 10 with Intune with the following article:

Intune Policy Processing on Windows 10 explained

At the time of writing the behavior of most Configuration Service Providers (CSPs) followed a tattooing model. Meaning once a setting got applied it wouldn’t change until you explicitly set a new value for it. Just the simple removal of the policy resulted in a tattooed setting, still active on the device.

This behavior changed lately (Windows 10 version 1903, 1909 and 2004 partially verified) and we do not have tattooing in general with all the CSPs anymore.

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.

This is an important fact to know and really worth a post to make everyone aware of this. The behavior of MDM policies now is more or less the same like the GPO policy processing. We got all missing parts which were not available in the first implementations of MDM management on Windows 10. Especially we have enforcement as shown in the previous article and removal on un-assignment. Keep in mind that every CSP is responsible for the new behavior and there is not a compiled list which CSP supports and implemented the new behavior. Maybe we can compile one as a community. I started a list in the end of the article.

To demonstrate this new behavior, I picked 3 different CSPs which are commonly used and checked if they are removed from the system after un-assignment. I’ve chosen the Policy CSP, Network CSP, and Defender CSP to verify the behavior on a Windows 10 version 1903, 1909 and 2004 device. Other Windows 10 versions still need to be verified. Will be interesting how far this is backported, my guess is max to Version 1903.

Let’s start by configuring settings from each CSP. I’ve created a Device Restriction profile and configured to hide Ease of access from the Settings menu which utilizes the Policy CSP in the background:

Intune device restriction profile - Ease of access Block setting

Just for reference, this is how the ease of access looks like before applying the policy on a Windows 10 Version 2004 device (same device is used for all screenshots):

Windows 10 Version 2004 Ease of access settings default

Then I’ve chosen to configure the Network Proxy setting to disable auto detect of proxy settings which uses the NetworkProxy CSP in the background:

Intune device restriction profile Network Proxy - Automatically detect proxy settings Block seting

Again for reference this is how it looks like before applying the policy, Automatically detect settings is turn on:

Network Proxy automatically detect settings turned on

Finally, I’ve chosen to apply a Defender policy which utilizes the Defender CSP to submit samples automatically:

Intune device restriction profile - prompt users before sample submission: send all samples automatically setting

This is how the Defender setting looks like before applying the policy:

Defender automatic sample submission turned on (default setting)

After I assigned the device restriction profile to my test device and did a MDM sync, I can see all settings successfully applied:

Ease of Access Settings has less options:

Windows 10 Version 2004 Ease of Access settings limited

Network Proxy automatically detect is turned off:

Network Proxy automatically detect settings disabled

Defender sample submission is turned on:

Defender automatic sample submission enforced through policy

So far so good, everything went as expected. Now we simply un-assign the complete device restriction profile by removing the AAD device group I used for the assignment:

Intune device restriction profile without assignment

After a short wait and clicking on MDM sync again, we should see every setting removed and all UI elements are accessible again with their default values.

Et voilà – everything removed and back to defaults, see below!

Ease of access settings are available again:

Windows 10 version 2004 ease of access settings

Network Proxy auto detect setting is available and turn on again:

Network Proxy automatically detect settings

Defender Automatic sample submission can be configured by the user again:

Defender setting automatic sample submission

I did the same test by not just un-assigning the profile, I switched the values back to “Not configured” and this gave me the same results. So, un-assignment and “Not configured” will revert back to defaults like we used to have with GPO policies (okay there are also some policies in GPO which do tattooing :-)).

Intune device restriction profile network proxy

This is an important feature to know, especially when troubleshooting the behavior should be crystal clear to everyone!

More technical details

I assume the implementation is realized by supporting the Delete command from SyncML Protocol (see also my Monitoring Tool SyncML Viewer) on the various CSPs. If we look at the NetworkProxy CSP for example, we see statements for supported operations. In the following case, starting with Windows 10 version 1803, the Delete operation is supported for ProxyAddress on the NetworkProxy CSP:

https://docs.microsoft.com/en-us/windows/client-management/mdm/networkproxy-csp

ProxyAddress
Address to the proxy server. Specify an address in the format <server>[“:”<port>]. 

The data type is string. Supported operations are Get and Replace. Starting in Windows 10, version 1803, the Delete operation is also supported.

I think this is the key functionality involved here, support for delete on the CSP and of course the MDM server in this case Intune has to send the Delete command to the client on un-assignment or configuration of “Not configured”.

If we have a look what happens on the client side if we un-assign the policy to hide Ease of access from the example above, you will see the Event ID 819 MDM PolicyManager: Delete policy, Policy: (PageVisibilityList), Area (Settings). This clearly references the setting we configured earlier, which gets deleted here:

event 819 MDM PolicyManager: delete policy

To summarize, we have seen Windows 10 version 1903, 1909 and 2004 does a settings removal when policy is unassigned or set to not configured. I already tested the following CSPs, others still need to be tested for this behavior:

As already mentioned in my previous article and following the Microsoft docs article (Troubleshoot device profiles in Microsoft Intune) these CSPs are also using the same behavior:

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

I’m happy to add new ones if someone verified the new behavior already for them.

That’s it for now, always make sure to understand the “inner workings” of technology to successfully implement and troubleshoot it.

Finally something also worth to mention when working with CSPs is the reboot behavior of CSP settings, when device based assigned and applied during Autopilot/ESP. Read my MVP fellow Jörgen Nilsson’s blog article here:

Autopilot, ESP and extra login/reboots