In Microsoft Intune, Configuration Service Providers (CSP’s) are used to configure settings on Windows PCs. Here’s the official definition:
A configuration service provider (CSP) is an interface to read, set, modify, or delete configuration settings on the device. These settings map to registry keys or files. Some configuration service providers support the WAP format, some support SyncML, and some support both. SyncML is only used over–the–air for Open Mobile Alliance Device Management (OMA DM), whereas WAP can be used over–the–air for OMA Client Provisioning, or it can be included in the phone image as a .provxml file that is installed during boot
Here’s the important part for Intune admins, “SyncML is only used over–the–air for Open Mobile Alliance Device Management (OMA DM)”. That’s how Intune pushes CSP-based policies to managed devices; it’s using Synchronous Markup Language (Sync ML) and OMA device management (OMA DM).
Windows 10 custom profiles use Open Mobile Alliance Uniform Resource Identifier (OMA-URI) settings to configure different features. The OMA-URI settings can be scoped to either users or devices and some only apply to specific versions of Windows 10.
That all sounds quite confusing at first glance I know. If you’re familiar with Group Policy Objects (GPOs), then you can think of CSPs as kind of like small, pseudo-GPO’s in that they contain settings that you configure centrally via an MDM solution like Intune. Another analogy that works for me is to think of OMA-URI locations as registry key paths containing properties that you want to set via policy. Intune likes to use the Policy CSP to configure Windows 10 settings so all you have to figure out is which one you want to use and where it lives. That’s where the Policy CSP documentation comes in handy.
There’s a lot on that page that you need to know, but there’s also a lot that you don’t need to pay attention to. The bottom line is that we need to build an OMA-URI path that points to a setting we want to configure, and that doc has the few bits of information needed to do so.
Finding your way along the OMA-URI path
When building out the OMA-URI path to configure a setting in Windows 10, you’ll need to get these bits of information from the CSP documentation. Luckily, these are all easy to get:
- Scope
- Root node
- Policy CSP sub-category
- Area and policy name
Scope
There are two scope available for applying CSP settings: User and Device. We’ll come back to how to find this in an example, and it’s easy to figure out, but for now, just remember, the scope is the first part of the OMA-URI path. You’ll see what I mean in a minute. For now, we’ll just call it ./<Scope> which means our OMA-URI path has a beginning:
./<Scope>
You can skip using a scope for device-wide settings, and the majority of Intune custom policies will target the device scope, but I like to use it just to be safe.
Root node
The root node of the Policy CSP is always called /Vendor/MSFT/Policy. That will be the root node for all custom policies used with Intune.
At this point, our new OMA-URI path now looks like this:
./<Scope>/Vendor/MSFT/Policy
These are case sensitive. Watch those p’s and Q’s as you’re building out the path.
Policy CSP sub-category
The Policy CSP has two sub-categories: Policy/Config/AreaName and Policy/Result/AreaName. We’re only ever going to care about the Policy/Config/AreaName.
So, now the OMA-URI path looks like the following Where AreaName is something we still need to define:
./<Scope>/Vendor/MSFT/Policy/Config/AreaName
Policy name information
We’ll need more than just the AreaName to finish building our OMA-URI path—we also need the PolicyName.
The AreaName/PolicyName specifies the name/value pair used in the policy. To find the AreaName/PolicyName combination, just skim through the list of available policies at the bottom of your favorite CSP documentation page to see which section matches your custom policy requirements. Once you have that, you’re done!
The final, full OMA-URI path looks something like this:
./<Scope>/Vendor/MSFT/Policy/Config/AreaName/PolicyName
So that’d be the OMA-URI path to enable you to configure some Windows 10 setting with Intune.
An example might help.
Allow Azure AD password reset
This is a pretty common custom policy that I see implemented a lot. And for good reason. Something like 30% of help desk calls involve helping users reset their passwords. Why not let them reset their own passwords while you focus on something more strategic with all that $$$ you’re going to save by enabling SSPR and reducing the number of help desk calls? Let’s build out the OMA-URI path together for this one.
We already know it’s going to start like this:
./<Scope>/Vendor/MSFT/Policy/Config/
How do we find the AreaName/PolicyName information? Easy, just scroll down the Policy CSP documentation page until you see something that might relate to SSPR. Something like the Authentication Section. See Authentication/AllowAadPasswordReset? That’s the AreaName/PolicyName combination we’ll use to configure self-service password reset from the Windows 10 login screen. The documentation shows us all the information we need to define the OMA-URI path for AAD password reset:
We can see which Windows editions and Windows 10 versions the CSP is supported for. This one works for Windows 10 Pro, Business, Enterprise, and Education editions version 1709 and later. Good to know so we can verify it’s something that will work in our environment, but not necessary for the OMA-URI path. What is necessary is that scope setting. This one is for the Device scope. That means our full OMA-URI path is:
./Device/Vendor/MSFT/Policy/Config/Authentication/AllowAadPasswordReset
The supported values for this setting are:
- 0 (default) –not allowed
- 1—allowed
0 and 1. Looks like an integer value to me.
Now we have an OMA-URI path and a setting value to use to configure it. That’s everything we need to make the option for self-service password reset available to our users from the Windows 10 login screen using Intune.
There’s more to enabling SSPR on the backend than just making the option available on the login screen. In other words, this is probably the last part of that process, but it makes for a good custom policy example. All we’re doing with this policy is making the password reset option available at the login screen. Or what identity types like to call the GINA (graphical identification and authentication).
Create the Intune custom policy
The hard part is over. Now we just need to log into the Microsoft Endpoint Manager admin center and create a pretty standard Windows 10 configuration profile. Do that by navigating here:
Log into the MEM admin center>Devices > Windows > Configuration profiles > + Create profile.
Select Windows 10 and later from the platform drop-down and custom as the profile type. Click Create.
Now, just skip through the process as usual. On the Basics tab, give the policy a name, optional description, and click Next.
The Configuration settings tab is where all the homework pays off. Click Add to enter the OMA-URI settings we found together and then click Add again.
There are a few things to double-check at this point that can save you a lot of time troubleshooting later:
- These OMA-URI values are case sensitive. Watch those p’s and Q’s. Verify everything is capitalized correctly before moving on.
- Also watch out for any trailing spaces. If you leave an extra space in there, the policy will fail to apply because it can’t find an OMA-URI path with that trailing space and send you into a troubleshooting tizzy wondering what “0x87d1fde8 Remediation Failed” means in your device configuration profile status.
Moving on. After you ensure the row is added successfully, just click next through the remaining tabs. Add any necessary scope tags and assign the policy to users so that they can reset their passwords. On the Applicability rules tab you can even make it so the policy is only applied to Windows 10 1709 or later devices—that’s when the SSPR capability was added to the CSP (documented in the CSP documentation we looked up earlier). Hopefully all your devices are above that level now though.
Check on your test devices and, after they’ve applied the policy successfully, Viola! Users can now reset their passwords from the login screen. You’re a hero! You’ve just saved your company boat loads of $$$ in reduced help desk calls and totally deserve a raise. Let me know how that goes.
Some other interesting examples of using custom OMA-URI policies with Intune:
- Using the MDMWinsOverGP policy to let devices know who to listen to: GPOs or Intune. Just know that that policy is only going to apply to settings found in the Policy CSP. So, settings that don’t live there won’t care what you say in your MDMWinsOverGP policy.
- You can use the Accounts CSP to add user accounts to your managed devices. Michael Niehaus does a good job of explaining why you might not want to do that, at least not for all devices, in his blog post: You can use Intune to create a local admin account, but that doesn’t mean it’s a good idea.
- Any others I should add here? Let me know on Twitter @jeffgilb.
You’ve seen my blog; want to follow me on Twitter too? @JeffGilb
