Windows CSP: A Tale of Magic, Betrayal, and Intrigue - Part 2
Back in Part 1, we covered some of the history and fundamentals of CSP delivery and how the OMA-DM communication channel works. But getting the policy to the device is only half of the story.
Let's dig in to two of the biggest issues people have...
Policy CSP & MDMWinsOverGP
Oh boy, we've found the betrayal.
Whether you're an Intune veteran or the whole thing is new to you, you'll likely see many references to the infamous "MDMWinsOverGP" setting on your search for answers, especially if you're working in a Hybrid environment and taking your first steps into cloud device management. Let me be very clear:
It is a false idol. Do not let it send you astray!
Trust me, nothing good will ever come from enabling this policy. But the reason you'll see so many references to it is that it didn't always used to be so problematic.
In the early days of Windows MDM, pretty much everything was handled under the Policy CSP, and this is the only CSP that "works" with the MDMWins setting. That's because things in Policy CSP know what the associated GPO setting is, and the registry keys it will change will be the same ones manipulated by GPO.
But MDM settings are always considered to have a lower "priority" than being managed elsewhere, so let's say if you set the following (purely for the sake of example) via GPO:
SetDefaultAutoRunBehavior - Enable
and the following via Intune:
SetDefaultAutoRunBehavior - Disable
The "Enable" setting via GPO will be applied, regardless of the more restrictive setting being deployed via MDM. Applying MDMWinsOverGP would flip that priority, allowing the MDM setting to apply and ignoring the GPO.
The problem was, many, many people used this as a crutch so as to not have to mess around with the hideous mess their Group Policy was almost definitely in. I'm sure it did work for some people, but as time has gone on, more and more settings now use their own CSP's.
Thankfully (if you bother to check the CSP documentation) there's is a big purple box on the ControlPolicyConflict page that states:
Unsure of how many other CSP's there currently are? About this many:
That's a lot of settings that have the potential for completely ignoring you in a Hybrid environment.
The amount of times I see people having issues trying to move to Windows Update for Business who don't doing anything about their existing GP that says to Disable Auto Update, or still push CM Client Settings to use WSUS...
The other really important thing to note about CSPs is that they have various applicability rules, from the OS Version, OS SKU, and the policy Scope:
If we look for the above policy in the Settings Catalog, we'll see two entries:
This is linked to that CSP scope, and what is means is the top option will deploy reg keys at the device-level (HKLM), and the bottom at the user-level (HKCU).
This can be very important in multi-user scenarios where you might want the user experience to differ depending on who's logged on, though it's worth noting that the User scope will take precedence in that scenario.
Let's dig into why that can be a rather confusing problem.
Users vs. Devices - The Eternal Question
This is by far the thing I see people consistently struggle with, and the reason is that it's so damn complicated.
I've lost track of how many times I've linked to or referenced the following section of a Learn doc, and it turns out it was written by none other than Mike Danoski:
MandiOhlinger
People coming from managing GPO are very familiar with the concept of "Computer" and "User" policies, and as it's been so long since I've had to mess with them so I'm not going to pretend I remember the nuances of how they actually apply.
Device and User Scopes, on the face of it, sounds like the same thing. Logic would dictate you apply Device settings to devices, and User to users. But the two important points of the doc above are:
If a device scoped policy is assigned to a user, once that user signs in and an Intune sync occurs, the device scope settings apply to all users on the device.
If a user scope policy is assigned to a device, all users on that device have that setting applied. This behavior is like a loopback set to merge.
So if applying a device policy to a user group is functionally fine, when would you ever need to do that?
What about instances where applying those device policies to devices triggers a reboot?
What if that reboot happens during Autopilot?
Do you experience an annoying reboot between the Device and User phase of Autopilot, dear reader?
I'd confidently put money on it likely (though not always) being related to one of the following policies applying at device-level:
This is also part of an inherent problem with "monolithic" policies like the built-in Security Baselines in Intune, or implementing a CIS Build Kit which lumps settings together into seemingly arbitrary groups. How do you find the culprit easily?
Having a well thought out, understandable set of Intune policies that allows the flexibility to fix this type of issue easily, or create settings for different groups of people such as Edge Extensions is so incredibly important.
So if you're hitting issues like this, or even just struggling for inspiration, why not go take a look at the OpenIntuneBaseline? ;)
SkipToTheEndpointWhat Does the Future Hold?
In Part 1, we went over the fact that your devices are still largely managed by a protocol almost old enough to drink in... most of the world. But what's next?
What if I were to tell you that "Tomorrow" is actually "Today"?!
Now I'm not going to pretend I'm anywhere nearly as clued up as Mr MDM himself Rudy Ooms on this, but if you've ever seen the words "MMP-C" or "WinDC", that's the future.
In fact, if you're using Defender for Endpoint or EPM as part of the Intune Suite, you've had a "LinkedEnrollment" into the MMP-C service for some time, but as of recently (and ahead of the new Intune Device Inventory rollout), all tenants and devices have been lit-up to enrol.
So what does this mean for Intune and policy deployment?
Well, eventually, that regularly heard complaint of "Intune is so slow" (which most of the time is due to poor network configuration, and totally ignores the fact that GPO literally worked on hopes and prayers) will become a non-issue. The OMA-DM approach of GET>SET>GET will be replaced by Inventory > Remediate & Report.
In practice, this can take a multiple-minute sync of policy down to seconds, and in turn reducing the load on Intune services, allowing them to scale further.
But understand this will take some time. Unpicking and re-architecting stuff is complicated when you've got to maintain backward-compatibility and interoperability. Changes will be small at first, and given some of the DeclaredConfiguration CSP Schema already visible on devices, it seems like there's a set of policy types that will likely come first:
Intune isn't without it's issues, but no other MDM platform has the same cross-platform feature set and sheer scale that Intune runs at, and unless MS were to publicly publish some figures, you'll just have to trust me, bro.
I, for one, welcome our DeclaredConfiguration overlords. Exciting times are coming.
References
I found some cracking relics while researching this two-parter, so I'm posting them below:
Peter van der Woude - @pvanderwoude
Nickolaj Andersen - @NickolajA
Nickolaj Andersen
Ramon Arjona
Comments ()