The majority (66%) of companies today have started some transition or co-management to the cloud. The goal is to digitally transform the enterprises of the companies.
While the basic network concepts may be similar, the cloud is a different beast. It uses different protocols and management tools. There is also a host of new acronyms to learn. For those who are, or will be, managing Windows 10 devices using some type of mobile device management (MDM), understanding the Configuration Service Provider (CSP) is an important concept to learn.
CSP stands for configuration service provider. A Windows CSP is used to deliver managed configuration settings or manage features on Windows 10 devices (or any MDM-managed device for that matter).
Group Policy vs. MDM Policy: Compare and Contrast
Those who have managed on-premise domains utilizing Windows Server Active Directory are familiar with the Group Policy Management Console (GPMC). GPMC is used to create Group Policy Objects (GPOs) to target and deliver configuration settings to designated domain-joined devices.
These Windows devices have the Group Policy service built-in, essentially serving as a Group Policy client. The desired settings are then created in the GPMC and Group Policy Editor, then invoked via the service’s client-side extensions (CSEs), which are contained within the Windows OS of the managed device.
Mobile Device Management (MDM)
Mobile device management (MDM) tools, such as Intune, are used to manage mobile devices and Azure AD-joined computers. Windows 10 machines house the MDM engine, which then calls the configuration service providers (CSPs) to perform the operation.
So, let’s summarize two administrators’ experiences:
- Admin 1: Opens the GPMC, creates a GPO, which has policy settings. Those are received by the Group Policy engine, where client-side extensions (CSEs) will process the settings.
- Admin 2: Opens Intune (or another MDM service) and creates a profile with settings. Those profiles are received by the MDM engine, where CSPs will process the settings.
In order to manage a Windows device via MDM, it must be MDM-enrolled. This “warms up” the in-box MDM client to receive CSP directives. The end goal is for the clients’ CSPs to be responsible for reading, setting, modifying, and deleting configuration settings on that device. The MDM system and MDM client work together to exchange setting configurations and commands based on a protocol called open mobile alliance device management (OMA-DM).
Digging into Windows CSPs
Different versions of Windows have different CSPs. This makes sense because Windows 10 Enterprise has features that are not included in Windows 10 Pro. In addition, new Windows CSP settings are made available with each version release. See the list of available Windows CSPs here. For instance, Windows 10 has a CSP called BitLocker. The BitLocker CSP has various settings, depending on the Windows 10 edition and version. The example below is from Microsoft’s explanation of the BitLocker CSP.
Like the above example, each CSP has a full path to each configuration setting in the CSP. This is represented by the CSP’s Open Mobile Alliance-Uniform Resource Identifier (OMA-URI). The URI is relative to the device’s root node. In the above example, the root node is BitLocker, and the supported settings branch off from it. Every label in the tree above represents a node.
In another example, let us say we wanted to configure the Windows 10 AutoDetect Proxy setting through MDM. The node path, in this case, would be:
./Vendor/MSFT/NetworkProxy/ AutoDetect
So, every setting contained within a CSP has a path. Each setting has some type of data type that awaits for a value to be assigned to it. As new versions are released, new nodes are introduced, and some are even deprecated. These nodes may be added to existing CSPs, or a new CSP may be created to accommodate the new settings. For instance, Windows 1909 introduced the following nodes to the BitLocker CSP shown above:
- ConfigureRecoveryPasswordRotation,
- RotateRecoveryPasswords,
- RotateRecoveryPasswordsStatus,
Version 1903 introduced a new CSP called EnrollmentStatusTracking. Microsoft documents all new and depreciated nodes for each version here.
MDM Built-in CSP Settings
Intune isn’t the only game in town when it comes to MDM. That’s because Windows CSPs aren’t tied to any one vendor. You simply need an MDM provider such as Intune, Workspace One, or MobileIron to configure a Windows 10 machine with MDM and its CSPs.
It really does not matter.
For the sake of this article, however, we will use Intune.
Intune has a number of settings available within the Intune menu. As mentioned, you create profiles to deliver configured settings. When creating a profile using the Intune menu, you first select the platform OS of the targeted device(s).
You then select a Configuration Profile type. A partial list is shown below from the drop-down menu.
Once you select the Configuration Setting type, you are shown the list of available settings to configure. Below we chose “Device Restrictions” in order to block access to certain Control Panel settings.
Custom OMA-URIs
Not all CSP settings are clickable and built nicely into Intune. That does not mean you cannot manage those settings through Intune, however. You can use Custom OMA-URIs, which will eventually configure CSPs to manage settings and features.
An MDM service like Intune might not have a clickable function, but the setting is ultimately configurable via a Custom OMA-URI, which will configure a CSP on the endpoint.
To do this, you must choose “Custom” as the Profile Type, as is shown below.
Note that we must now configure the Custom OMA-URI Settings. These settings will direct the policy to manage the desired setting or feature. These settings are as follows:
- Name: The name is for your reference to help you identify it. Use any name you wish.
- Description: Enter a short summary of what the profile does and any other pertinent details.
- OMA-URI: The OMA-URI settings are unique for each platform, be it Android, iOS, Windows, etc. It is also case sensitive, so be careful to type in the setting path correctly. To configure settings for a Windows 10 device, you would type the path:
Vendor/MSFT/Policy/Config/AreaName/PolicyName
- Data type: The data type will vary based on the OMA-URI setting. The options are String, String (XML file), Date and time, Integer, Floating point, Boolean and Base 64 (file)
- Value: Here is where you associate the OMA-URI value you wish to enforce.
Here is an example below:
In some rare cases, you might be able to export some of Group Policy’s exported settings into an XML file and import them into Intune. But they must correlate with a CSP. In this example, we imported AppLocker settings configured in Group Policy and made a custom profile.
Summary
If you’re going to get familiar with managing Windows 10 with MDM, you should understand the relationship between an MDM service, its engine and CSPs.
CSPs cannot do everything that an admin might want to do.
For instance:
- There is no CSP to manage non-Microsoft browsers.
- There is no CSP to manage Java settings.
- There is no CSP to perform elevation of applications that need Local Admin rights.
- There is no CSP to “lift and shift” some settings of Group Policy and Group Policy Preferences to MDM land.
If you plan to be a power admin with MDM to manage Windows 10 devices, we invite you to check out PolicyPak, a modern desktop management solution that empowers you to easily configure, deploy and manage policies for on-premises, MDM, and cloud Windows environments.
PolicyPak MDM Edition can supplement your MDM solution not only to provide complete setting coverage but also to manage third-party applications, enforce browser policies and lock down desktops in a way that traditionally has only been available through application whitelisting.
CSPs will take you part of the way. PolicyPak can get you the rest of the way and works seamlessly with Intune and all other MDM providers.
