Windows CSP: A Tale of Magic, Betrayal, and Intrigue - Part 1
Intune as a GUI is (relatively) simple to understand. You create a policy, define the settings you want to apply, and hit Save. But what happens once you've done that? How do those things find their way down to a device, and how are they actually applied?
Moreover, why is it important that you should understand this as someone who administers Intune, or supports Intune-managed devices?
A trip back in time...
I feel like I start a lot of my posts with some sort of nostalgic history lesson.
This one will be no different, so buckle up. cue wave lines...
It's the early 2010's and you totally don't have your hair swept over one eye while listening to A7X and My Chem on your Zune while learning HTML just to make your MySpace profile look awesome. You pull your Windows Phone out of your baggy jeans pocket...
Cool, now I've set the scene (possibly a little too uncomfortably for some), it's around this time that Microsoft decide that phones aren't just for personal use and BlackBerry were taking too much market share, so they worked closely with an industry group called the Open Mobile Alliance (OMA) to push things forward.
A decision was made to use the Open Device Management (DM) 1.2 standard originally created in 2007 to manage enterprise communication with Windows Phone and subsequently Windows 8.1 devices via the magic of the SyncML protocol. The architecture looked something like this:
Development continued within Microsoft on this whole "Mobile Device Management" thing, and while WinPhone and Win8.1 faded into obscurity, development on this management channel for Windows known as MS-MDM has continued, with the latest protocol update being April 2024!
So SyncML provides the communications lane with a device and sends commands, but how does the client operating system act on those commands?
This is where Configuration Service Providers, or CSP's within Windows come in...
Alright Grandpa, so what's a CSP, and why should I care?
To quote the official docs on the subject:
In the client operating system, a CSP is the interface between configuration settings that are specified in a provisioning document and configuration settings that are on the device. CSPs are similar to Group Policy client-side extensions in that they provide an interface to read, set, modify, or delete configuration settings for a given feature. Typically, these settings map to registry keys, files, or permissions.
So they're sort of like GPO. You configure a policy in your MDM, and as if by magic, a registry key is changed client-side. However unlike GPO or GPP's where you can push an arbitrary registry key to anywhere if a proper GPO setting for it doesn't exist, CSP's are defined explicitly in the Windows OS meaning that to configure a setting, Windows has to actually make the setting available to configure in the first place.
If you've been using Intune for a while, you're probably familiar with what Open Mobile Alliance – Uniform Resources , or OMA-URI's are. An OMA-URI is the path to a specific setting made available by a supported CSP, and generally take shape like this:
./{Scope}/Vendor/MSFT/{CSP}/{AreaName}/{PolicyName}
It can sometimes look a little different depending on which CSP you're dealing with, but more on that later.
There are also a number of policies surfaced directly to MDM's via ADMX, such as Edge, OneDrive and Office, which I won't go into detail here, but there's an incredible article if you're interested:
DO NOT use the ADMX import capability in Intune to import built-in Windows ADMX files in
C:\Windows\PolicyDefinitions unless a third-party ADMX needs them.Before doing that, make sure the third-party ADMX actually needs them, for example by running FixMyADMX.
These CSPs are made available to MDM's via Device Description Framework (DDF) files, and it's these DDF files that Intune uses to provide us a nice friendly UI to work with instead of having to work with OMA-URI's for everything, which anyone who's been working with Intune since the beginning will tell you was a nightmare.
So why should you care?
Because not understanding, at least at a high-level how devices receive policy (and how to troubleshoot them), and how that policy is driven by specific pre-defined locations in the OS, means that you're just clicking buttons in a UI wildly without really knowing what's going to happen when you hit "Save".
To use another analogy:
You can drive a car with your eyes closed and I'm sure you'll be okay for a little bit, but seeing where you're going is going to be incredibly helpful for your physical safety, as well as the other passengers in your vehicle.
Issues of Scale
So device communication is achieved using SyncML, and...
You're saying my current Windows 11 devices are still being managed using a 17 year-old set of instructions!?
Well... mostly, but YES! Isn't it incredible? Genuinely, the amount of capability that the Windows and Intune teams have been able to squeeze out of a protocol meant to manage mobile phones from 2011 is astounding.
Could be worse though, you could be using something that was released alongside Windows 2000 to manage those devices. But I digress...
The way in which policy is pulled from Intune and applied to a device works as:
GET > SET > GET
GET - Get the current configurations and inventory
SET - Remediate configurations that don't match the desired state
GET - Values you set to report
Have you ever gone and hit the "Sync" button and it's taken forever? This is why. The amount of back-and-forth communications with the Intune service just takes a bunch of time to churn through, and part of that is going to be due to just how far the protocol has been taken since it's inception and what was expected of it back then.
The downside to this is, that puts a huge burden on the Intune microservices responsible for policy delivery. Sure, you might only have a few hundred devices in your tenant, but you're just one of MANY tenants that sit on a particular Azure Scale Unit (a large set of replicated and striped VM's in Azure, denoted by location and number, e.g. "Europe 0502"), and your devices are a mere few of millions across the entire service.
This isn't me trying to defend again those who complain that "Intune is slow". I get it, and yes, even I get frustrated sometimes. But we work in technology, and taking a step-back and a think about the sheer scale of what you're using sometimes can be really valuable.
I personally love that kind of deep-dive perspective. Some of my favourite articles I've read have been where Discord explained their scaling challenges:
Bo Ingram
The last thing I can find about Intune is Brad Anderson's 3-part posts from 2019, and anyone who was at MMSMOA 24 and caught Matt and Venkata's "Intune Internals Extreme Deep Dive" will have caught a glimpse into what it is now, but I'd love to see more public info on this stuff!
Recap
So, SyncML provides the management channel, we create our management payloads as OMA-URI's, and Intune delivers them to the device which implements those settings based on pre-defined CSP's.
Easy right? What could possibly go wrong?
Well, take a look at Part 2 where I'll dive into the exciting stuff, like ControlPolicyConflict (MDMWinsOverGP), User vs. Device assignments, and what a post-OMA-DM future might look like!
James Robinson
Comments ()