My name is Saurabh Sarkar and I am an Intune engineer in Microsoft. I have a YouTube channel ‘EverythingAboutIntune’ and you can subscribe to the same to learn more about Microsoft Intune.
- By using Intune, we can provide a modern device experience to our users and better support their digital transformation by focusing on an internet-first device connection.
- In Intune, policy-based configuration is the primary method for ensuring that devices have the appropriate settings to help keep the enterprise secure and enable productivity-enhancement features.
- The policies deployed via Intune can be broadly categorized as- MDM policy (Device management) or MAM policy(App protection).
- In this blog I wanted to explain the significance of a CSP and OMA–URI and discuss how an MDM policy is delivered to a Windows 10 device.
The entire demonstration of this post can be found in my below Youtube video-
CSP stands for Configuration Service Provider (features integrated into the Windows 10 platform starting with Windows 10 version 1607)
- A CSP is a component of the Windows 10 operating system; kind of like a Client-Side Extension (CSE) is to Group Policy.
- The CSP is what gives IT personnel the ability to apply device-specific settings to Windows devices.
- It is an interface used by mobile device management (MDM) service providers to read, set, modify, or delete configuration settings on the device. These settings map to registry keys or files.
- As an analogy, CSP can be referred to as a form of an API which both the service and client understands
- CSPs expose device configuration settings in Windows 10
Breakdown of a CSP
- CSP Policy scope is the level at which a policy can be configured.
- Some policies can only be configured at the device level, meaning the policy will take effect independent of who is logged into the device.
- Other policies can be configured at the user level, meaning the policy will only take effect for that user.
./User/Vendor/MSFT/Policy/Config/AreaName/PolicyName to configure the policy.
./User/Vendor/MSFT/Policy/Result/AreaName/PolicyName to get the result.
./Device/Vendor/MSFT/Policy/Config/AreaName/PolicyName to configure the policy.
./Device/Vendor/MSFT/Policy/Result/AreaName/PolicyName àto get the result.
(For device wide configuration the ‘./Device’ portion may be omitted from the path)
Please refer to our below document for more details on CSPs-
- OMA-URI’s (Open Mobile Alliance – Uniform Resource) which is basically a path to a specific CSP
- The full path to a specific configuration setting is represented by OMA-URI
- Features supported by a particular CSP can be set by addressing the complete OMA-URI path.
Need of an OMA URI-
Not all CSP settings are “surfaced” as settings within Intune portal’s UI
If we wish to configure settings on a CSP that doesn’t appear in Intune UI then we have 2 options-
- We can either wait for that CSP to be surfaced and featured in the Intune portal OR
- We can make a Custom OMA-URI profile in Intune.
There are loads of settings that can be possibly configured in a Windows machine and it is just not feasible to have all of them in the portal. For the settings which are not there, deploying a Custom OMA-URI profile targeting a CSP comes to the rescue.
This approach enables us to control settings as soon as they are introduced on the client side (Windows 10) and we do not need to be dependent on the Intune, to build an UI explicitly for it.
- The Intune service and the device work together to exchange data based on the Open Mobile Alliance Device Management (OMA-DM) protocol
- The protocol is a pre-defined standard and uses an XML-based SyncML format to push the information to the client.
- This works in the transport layer and uses HTTPS
- This is vendor independent and is used for Android and iOS management as well.
- This transfers instructions in a standardized way to the endpoints.
- On the client side we have the CSP’s responsible to read, set, modify, or delete configuration settings on the device.
PORTAL ALSO DOES THE SAME THING!!
In Intune UI, the OMA-URI’s are hidden in user-friendly configuration interfaces which makes it more intuitive for the admin.
In the background the interface also leverages OMA-URI’s to configure the settings on the device.
As shown below, the tasks we are performing from the UI can also be performed by deploying an OMA-URI and targeting the relevant CSP.
Example 1- Setting a Lockscreen image
#From the portal:
#Via Custom OMA-URI targeting the CSP:
The same setting can be set directly by using the OMA-URI:
#End device Experience:
Example 2- Setting up Bitlocker Encryption
#From the portal:
#Via Custom OMA-URI targeting the CSP:
Comparison of this setup with on-prem:
- Traditionally we have had group policy, which provides a very granular control for management and it has been around since the days of Windows 2000 Server and it has evolved over the years, changing from ADM to ADMX.
- In cloud world we are achieving the same via Intune, over the Internet.!
We evaluated which settings were needed for our devices within an internet-first context and built our MDM policy configuration from there, using Group Policy settings as a reference.
- This is the same architecture as we had in an on-premises domain.
- With MDM it is standardized and designed to work perfectly over the internet
- With the MDM stack, we have a logical evolution of the domain group policy processing.
- When an organization wants to move to MDM to manage devices, they should prepare by analyzing their current Group Policy settings to see what they need to transition to MDM management.
- We have the MDM Migration Analysis Tool (MMAT) which determines which Group Policies have been set for a target user or computer and then generates a report that lists the level of support for each policy settings in MDM equivalents. It can be downloaded from the below link-https://github.com/WindowsDeviceManagement/MMAT
|MDM server (Intune service)
|Client-Side Extension to process GPO
|CSPs to process the MDM policy
|SMB protocol used for communication
|HTTPs protocol used for communication
|.pol | .ini file is usually the input
|SyncXML is the input for the devices
- 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
- Removing the assignment of the policy from the user or device may/maynot not revert the setting automatically to the default value.
- There are a few profiles which are removed after the assignment is removed or the profile is deleted. (Wi-Fi profiles/VPN profiles/Certificate profiles/Email profiles)
- The behavior is controlled by each CSP in the operating system.
Deploying an OMA-URI to target a CSP from Intune
In order to deploy a custom OMA-URI to target a CSP, from Intune, we would have to create a Custom policy as show below. The policy would contain the path to the OMA-URI path along with the value we wish to change in the CSP (enable/disable/modify/delete).
Once the policy is created as above it needs to be assigned to a security group for the same to take effect.
Once Intune policies are down to the device, there are 2 kinds of logs we can check to confirm its delivery-
#MDM diag logs:
- The ability to deploy an OMA-URI custom policy targeting a CSP opens an ocean of opportunities for us!
- We no longer have to be solely dependent on the Intune UI and can manage most of the attributes of the device which have been exposed by the OS in form of a CSP.
Intune does provide us the ability to configure custom OMA-URI’s, but if a separate UI element is available then it might be a better approach to use that instead of dealing with OMA-URIs as it makes it easier for management and review.
I hope this has been informative and insightful in establishing the usage of OMA-URIs targeting CSPs via Intune.