MDM & GP Tips Blog

So Ignite 2019 is behind me (and us).  And I wanted to give you some of my insights into what I took away (and how I participated.)

First, Microsoft is such a huge company that this year, with all the new stuff coming out (or changes to existing products) Microsoft put out a “book of news” which is a giant PDF of all the what’s new. It’s only 85 pages. Ow ow ow ow ow.

https://news.microsoft.com/wp-content/uploads/prod/sites/563/2019/11/Ignite-2019-Book-of-News-2.pdf

That being said, I’m going to cut to the chase for what I specialize in and think most about: Windows desktop management with Group Policy and MDM.

It starts off with this announcement: Microsoft SCCM and Microsoft Intune are now under a unified product umbrella called “MEM”: Microsoft Endpoint Manager. With this, naturally, there are going to be some questions:

• What does this mean for you?
• What does this mean for on-prem (SCCM and Group Policy) worlds?
• And what does this mean for existing SCCM and existing Intune customers?

Let me try to answer that in this blog. To do that, I want to quote Microsoft leadership (VP Brad Anderson) in his kickoff address:

"Modern management does not mean cloud-only.  It does not mean a migration away from ConfigMgr, or a migration to Intune.  Modern management puts the cloud intelligence that comes from organizations like Microsoft to work to automate  tasks,  prioritize your efforts, connect the IT and Security teams, and continually improve the user experience.  We do believe the destination many organizations will arrive at over time will be a cloud-only management solution with Intune and Microsoft 365 at the center, but we want to enable you to take advantage of our cloud capabilities incrementally at your own pace – without replacing infrastructure as some of you may not be ready for a full cloud migration.  This enables you to  get cloud value along with your on-prem deployments, on the road to full cloud/modern transformation."

Let’s break this down (my words interpreting Brad; this is not Brad himself):

• “Hey Microsoft Customer”: what you’re doing now is okay. (SCCM & Group Policy still has a place, works as expected and continues to work for desktops, onprem servers, VDI etc.)
• “Hey Microsoft Customer”: Cloud is great. If you’re ready for it, great. When you start to use it you’ll get added cloud benefits.
• “Hey Microsoft Customer”: You don’t have to DUMP AND JUMP what you’ve built to cloudland. We think you’ll get there eventually.
• "Hey Microsoft Customer": The tools you use today, like Group Policy and SCCM, aren’t going away.  In fact, they can't go away.

This is ALL good news. For all scenarios and customers: What you’re doing isn’t going away, but there’s options for you if you want to take advantage of the cloud. Indeed, the newest philosophy and guidance (which I took away from multiple sessions) appears to be:

• Keep your PCs / servers / Citrix/ VDI / everything in Group Policy / SCCM land for now.
• Cloud attach / Hybrid Azure AD join to gain some cloud attached features, increased security, reporting, and insights.
• From a policy (and workload) management perspective: pick one. Group Policy or MDM or SCCM for the particular job.

On stage, at least two Microsoft-led sessions referenced my new MDM book (whoa! Thanks Microsoft friends!) and expressed (my sentiment) that trying to untangle a machine with both Group Policy **AND** MDM settings on the same box is a difficult problem. And one that should be avoided.

In Ghostbuster’s parlance:

“Don’t cross the streams…it would be bad. Try to imagine all life as you know it stopping instantaneously and every molecule in your body exploding at the speed of light.”

(Full scene here: https://www.youtube.com/watch?v=wyKQe_i9yyo )

Maybe not that bad, but.. in that ballpark.

So what does this mean for you? The “take away” advice I felt I got was: once you’re settled and have the cloud / Azure/ MDM  (Intune or other) reasonably handled, then NEW deployments of Windows 10 can be cloud only … from a management and policy perspective.

So how can Group Policy, Azure, MDM and SCCM be used at the same time… but take on different (non-conflicting) roles? Here’s an example:

• Roll out a machine using Azure and Autopilot and perform a hybrid Azure AD join.
• Machine gets on-prem Group Policy setting for Windows-y and security things.
• Machine gets software deployment settings from MDM.
• Machine gets patching and updates from SCCM.

Again: That’s just one way to slice it. There are surely others.

So… the message to customers from Microsoft would now be (again, my interpretation; not one person directly.):

1. Get ready for, understand, and use the cloud when you can.
2. Attach your on-prem universe to the cloud for cloud-attached benefits.
3. Yes, we realize utilizing the cloud could actually be a long, long time before you get there and are comfortable. Perhaps many years.
4. Once you’re there in cloudland, we recommend new PC deployments can be in the cloud.
5. Even then, we realize Group Policy will always be used for some circumstances, and we’re cool with that. (So, once again, Group Policy isn’t somehow ‘going away.’). Indeed, even today Windows Virtual Desktop requires on-prem Active Directory and Group Policy even though the WVD machines are in Azure / the cloud. (You can see my walkthrough and gettings started with WVD here if you want to give it a try!)

That being said, Microsoft is trying to make it easier for you to take your existing Group Policy settings and see if it’s possible to use them in MDM-land if you choose to do it. Already, they have the MMAT tool which can analyze your existing Group Policy Objects (or an endpoint) and give you a report on what will, and what won’t transition to MDM-land. .. and I talk about it in my MDM book, chapter 5. Get your signed copy now.?)

What was announced this week with regards to Group Policy and Intune are two items:

1. Microsoft is going to ship a “CSE TOOL” which customers can add-into Windows 10, when a machine is born, or after the fact. This CSE Tool will then be able accept some directives from your MDM service (like Intune or others) and poke at SOME Microsoft Group Policy  CSEs to instantiate some Group Policy functions. The first items that Microsoft is tackling are:

1. Drive maps.
2. NON “Microsoft policies keys” in Registry (think unusual ADM / ADMX files).
3. Auditing.

These items are interesting if the idea is to stop using Group Policy for these items and then use MDM instead. (Again, don’t cross the streams.) What is interesting though is that (again) the MDM provider will have to call this CSE tool, which then actually performs the work in the Group Policy CSE. Which, once again, friends … means that Group Policy cannot die. This essentially guarantees it.

2. Microsoft also demonstrated a future feature in Intune, which is SIMILAR in practice to MMAT I mentioned above. The gist is that you can show Intune a GPO backup which Intune can now analyze. Then if the settings in the GPO exist, an Intune profile will be made (with    the equivalent settings in Intune land.)

That being said, as was repeated several times across multiple sessions: If you’re going to attempt a transition from Group Policy to MDM, don’t “lift and shift” over your settings without making proper decisions to keep or kill a setting.

Then, additionally, if you’ve now lifted and shifted Group Policy to MDM… here we go again… don’t cross the streams.

With any tool which makes things easier, use it wisely with a heap of planning to know what your destination should look like. Don’t just use the tool (any tool) because it’s there.

My little inner fear here is that many companies won’t heed this advice, and very quickly be in the same place like “I’ve got too many MDM profiles where I don’t know what they’re doing !!” as they already do in the “I’ve got too many GPOs where I don’t know what they’re doing!!” place they are right now.

So in summary, here’s what I learned at Ignite 2019:

• Intune and SCCM are now under one umbrella: Microsoft Endpoint Manager. Indeed, if you’re an existing SCCM customer, you now automatically get Windows Intune licenses for managing Windows devices via Intune. Note that this doesn’t mean you magically get, say, iOS or Mac or other non-Windows PC licenses. Also note this requires an Azure Active Directory P1 (at least) subscription  for your organization.
• It’s okay to be on-prem, and it’s okay to be cloud. Cloud is a destination, but destinations take a long time to manifest.
• Microsoft is increasing their tooling for Group Policy understanding and to take on some better Group Policy to MDM migration scenarios for those who feel they are ready to go there.
• (once again) Group Policy isn’t dead.

So, take a deep breath. You’re doing fine. If you’ve got no toes in, or one toe in, or nine toes into the cloud… you’re doing fine. And, yes, I realize, you cannot put toes into cloud, but just  go with me here.

I hope this blog entry helps you out and you’ll share it with your friends, your boss, and anyone else who wants to learn what’s new in management this year from Ignite 2019.

PS: Here’s some pictures of me at Ignite:

• First in the Microsoft Endpoint manager booth (https://twitter.com/jeremymoskowitz/status/1192204319745024005
• Second at the bookstore with my Group Policy and MDM books https://twitter.com/jeremymoskowitz/status/1191776777452032002
• Third, petting a therapy animal who is there for some down time with the geeks https://twitter.com/jeremymoskowitz/status/1191782442354532353

Ignite 2019 was really bananas, and it was awesome seeing many of you in person !

While we used to actively block devices from registering with Intune and SCCM or Group Policy at the same time, we more than welcome this duality of management capabilities today.  Outside of cloud-only enterprises, Microsoft not only allows, but encourages the practice of allowing settings management from multiple sources. Microsoft refers to this current practice as co-management. 

The advantage of Hybrid MDM was that it allowed you to manage SCCM exclusive and MDM exclusive devices from a single console.  Essentially it was a a product of convenience more than anything.  With co-management, the two work in cohesion.  Clients can now have the Configuration Manager client installed and be enrolled in Intune.  For those organizations that have a considerable investment in time and resources in SCCM, Co-management adds greater functionality to your SCCM structure by incorporating cloud functionality.

Co-management requires version 1710 or later and requires all involved Windows 10 devices to be Azure AD-joined or joined to on-premise AD and registered with Azure AD.  For new Windows 10 devices, you can simply join them to Azure AD, enroll them in Intune and install the Configuration Manager client for co-management ability.  When it comes to Windows 10 devices that already have the Configuration Manager client installed the path is more complex, but basically requires you to setup hybrid Azure AD and enrolling them into Intune. Whichever way you get there; the end result is that you get the best of both worlds. 

Co-management is about more than just increased functionality however.  It gives IT administrators the flexibility to choose which management solution works best for their organization, devices and workloads they have to manage.  This facility of choice is exemplified in the screenshot below that shows the workloads tab of the SCCM admin screen.  As you can see, with co-ecomanagement you can switch the authority from Configuration Manager to Intune for select workloads.  This puts the SCCM admin in charge of which tool will manage what policies by simply moving the slider to the selected choice.

Note the presence of the “Pilot Intune” option.  As MDM is relatively new to most admins, Pilot Intune gives you the ability to pilot things first in order to ensure everything operates as expected.  Once results are confirmed, you can throw the switch all the way.  Eventually, Microsoft hopes that all the siders will be moved to the right, with everything hosted and managed in the cloud.  Those who are intimidated by SCCM might say that’s not a bad thing. 

Surprises are great when you are engrossed in a captivating movie.  A good novel always has multiple twists that you don’t see coming.  For the most part though, the world prefers predictability, especially when it comes to managing corporate enterprises.  The whole purpose of deploying settings is to ensure conformity to your enterprise client devices.  Group Policy and MDM were made to deliver a level of certainty to the enterprise.  

So what happens when Group Policy Settings and MDM settings collide with one another?  Because Windows 10 can potentially be a member of an on-prem active directory domain and be MDM enrolled as well, that is a distinct possibility.  Starting with the 1709 release, Microsoft unveiled a GPO setting that allows hybrid joined devices to be automatically MDM enrolled.  So let’s say we have a hybrid environment of Windows 10 laptops and just for grins we disabled Cortana using an MDM policy setting and enabled it using a Group Policy Setting.  Which policy do you would win out?  

If you had to guess, you would probably say Group Policy since it is the elder of the two.  If you did, you would be sort of wrong.  You would also be sort of wrong if you said MDM. 

How can you be sort of wrong you ask? 

Because when MDM and GP settings conflict, we honestly have no idea which one is going to win out. 

In fact, that is the default, expected behavior.  Yes, the default behavior is uncertainty.  Just like the stock market doesn’t like uncertainty, neither do network admins.

So in order to add some stability to these conflicting scenarios, Microsoft introduced a Policy CSP called ControlPolicyConflict/MDMWinsOverGP.  It uses an integer based data type for which there are two supported values:

• 0 (default state of uncertainty)
• 1 - The MDM policy is used and the GP policy is blocked.

To enable this policy, we have to create a custom OMA-URI setting as shown in the screenshot below.

So if MDM and the same Group Policy setting are contending to assign the SAME value to the SAME setting .. then you can use MDMWinsOverGP to force the MDM to always regardless of what GP is trying to do.  

If you are managing a hybrid environment with MDM and GPO, it may in fact be good practice to enable this CSP for good measure just to ensure that certainty will always prevail.  In the IT world, certainty is a good thing.

Long, long ago, well, actually not so long ago, there were two worlds.  There was the on-prem world and the mobile world, and the two would never become one, until of course they did one day.  Up until Windows 10 version 1607, a device could either be on premise AD or Azure AD.  This made sense at the time.  Back then, MDM enrolled machines was pretty much restricted to mobile devices as administrators wanted the extensive management control that Group Policy or SCCM provided them for enterprise desktops. Mobile devices were better served in the cloud and outside of device resets and remote wipe capabilities, there wasn’t much you could do with MDM early on.

It wasn’t thought a good idea at the time to have settings delivered from multiple sources.  In order to prevent that from happening, devices were blocked from the ability to simultaneously register with SCCM and Intune at the same time.  In fact, the activation of the SCCM client on a Windows device automatically disabled any built-in MDM capabilities.  Devices were segregated to one or the other.

If your company’s IT staff had separated SCCM administrators and mobile device administrators, then everything was fine.  But if you had to manage both desktops and tablets, you had to switch back and forth between the Configuration Manager console and the MDM console.  So Microsoft set about to integrate Configuration Manager with Intune with what was called “hybrid configuration” so that both on-prem and mobile devices could be managed from the same console.  Co-management between the two was born.  Note that Intune was the only MDM supported in this scenario.  The merging of these two platforms is illustrated below.

But as in everything, things change.  Microsoft put more focus into MDM as time went on, and as a result, more setting capabilities and features were built into Intune.  Organizations also started recognizing the value of migrating more computers to the cloud than just mobile devices.  Microsoft also began figuring out that it was in their interest to encourage customers to move to the cloud.  Because of these and other factors, the usefulness of allowing devices to co-exist in both on-prem AD and Azure AD was realized.  Starting with 1607, computers could be a part of both at the same time.  Then came 1709 in which the SCCM client could now run on a device without its MDM capabilities being disabled.  This made it possible for a computer to receive setting input from both sources.  This signaled the end of Hybrid MDM.  In August of 2018, Hybrid MDM became a deprecated feature and Microsoft began blocking the registering of new Hybrid MDM customers in November of the same year. 

I have to admit... making a simple registry change in Intune can be ... difficult. 

The Administrative Templates function is nice, for those (under 300 settings) that support them. 

But for the rest of the simple settings ... you might have hand-create custom OMA-URIs and usin ADMX backed policies to do it.

Here are some others' great guides to help you "follow the leaders" and convert your ADMX and/or use an ADMX-backed policy:

Those resources, show how to tear into an ADMX and ADML file and create a more complex ADMX-backed policy:

• https://docs.microsoft.com/en-us/windows/client-management/mdm/understanding-admx-backed-policies
• https://docs.microsoft.com/en-us/windows/client-management/mdm/enable-admx-backed-policies-in-mdm
• https://www.petervanderwoude.nl/post/allow-users-to-connect-remotely-to-this-computer-via-windows-10-mdm-admx-style/
• https://www.petervanderwoude.nl/post/deep-dive-configuring-windows-10-admx-backed-policies/
• http://carlbarrett.uk/admx-backed-policies-quickish-reference-guide
• http://thesccm.com/use-intune-policy-csp-manage-windows-10-settings-internet-explorer-site-to-zone-assignment-list/

This week an Intune feature I have been playing with for a while has finally gone live for Preview.
It’s called “Administrative Templates” and … oh wow, that sounds a lot like Group Policy Administrative Templates, and, oh yes. You’re right… mostly.

Now, before you go bananas saying “Jeremy, clearly Intune now has total Group Policy support!” Or, worse, beat the old trope that “Group Policy must be dead.”

As anything new, it’s worth investigation and to ensure it does what you think it’s going to do.

Let’s talk about the good stuff first !

So, to set the stage, you have to first understand what ADMX backed settings are within Intune / MDM.
It starts with the idea that some settings which are curated by the MDM team. Now, this is weird so stick with me. Because the MDM team is not the Intune team.
You can think of the MDM team as the “receiving platform” which decides upon the settings within the platform.

You can think of the Intune team as “expressing” those settings with knobs and buttons. And this is because Intune isn’t the only MDM game in town; for instance, VMware Workspace one, MobileIron, SOTI and others.

So, these ADMX-backed settings are, as you can imagine, real Group Policy settings which are supported by the target application, say, Explorer or Office.

But these settings are curated by the MDM team as “guaranteed to work and supported as such.”

If you want to see the official docs on Administrative Templates feature you can find it here: https://docs.microsoft.com/en-us/intune/administrative-templates-windows
Here’s the best part from the docs:

These templates are similar to group policy (GPO) settings in Active Directory (AD), and are ADMX-backed settings that use XML. But, the templates in Intune are 100% cloud-based. They offer a more simple and straight-forward way to configure the settings, and find the settings you want.

This is really nice. What’s not to like? Indeed, if you wanted to achieve these ADMX-backed settings before this feature came to be, you needed to know how to perform the dark arts of custom OMA-URI (a different topic for a different day.) Now, with Administrative Templates in Intune, for all those settings, those values are just click and go. +1 for that !

If you look at the docs, you’ll see the following line:

The administrative templates include hundreds of settings that control features in Internet Explorer, Microsoft Office programs, remote desktop, access to OneDrive, use a picture password or PIN to sign in, and more.

The key word here is hundreds. Why is it hundreds, and not thousands or “all”?

Well, you need to go back to something I said earlier. All settings in MDM (and by extension, Intune) are curated. Each setting must be vetted to work as expected and then guaranteed by the MDM platform.

Also, at last count the number of exposed Administrative Template settings is 237. (Note: I did not re-count it before publishing this; the number could have gone up somewhat.). As the docs state, most of the settings seem to revolve around Office, OneDrive, Internet Explorer, and a handful of system settings.

As such you will likely see this list grow over time, but my understanding is that this is not meant to overtake or subsume all existing Group Policy settings.
If you are looking for a setting which doesn’t exist in Intune.. either a native clickable one or via Administrative Templates, don’t despair or throw in the towel, yet.

If you want to make any real Group Policy, Group Policy Security and/or Group Policy Preference setting work thru Intune, you need to enhance Intune with a 3rd party tool. Here's a video for how it's done. An equallty effective option is to use this other 3rd party option, which works with MDM or whenever there is no MDM present.

Let’s talk about what’s missing, last.

If you get a chance to play with this feature, click upon Intune | Device Configuration | Profiles | Create Profile and select Administrative Templates (Preview) like what’s seen here.

Then under Settings, you will see the list of Administrative Template settings like what’s seen here.
Top of the page…

Bottom of page….

At the top of the page begins an alphabetical list of the curated ADMX policy settings and a Search (Filter) bar.
So, if you wanted to quickly search of OneDrive, you can find those settings.
But what you cannot do, like Group Policy, is see these settings hierarchical.

I can see both sides of this; this flat view reduces clutter. But my preference would be to see the settings hierarchical, so I could maybe find related settings around the primary setting I’m searching for.

Summary about Admin Templates in Intune

In summary, Administrative Templates a nice step forward in Intune. Just know that it’s not designed to attempt to take on all of Group Policy settings, but be on the lookout for increased coverage over the long haul as new interesting scenarios pop-up.

What is ADMX File Ingesting in Intune?

We’ve talked about how Intune has incorporated ADMX backed policies to manage even more settings in your Windows 10 devices.  But what if you want to deliver settings that aren’t part of the “in the box” policies from Microsoft.  Well, if you are familiar with Group Policy, then you are aware that you can garner more policy setting opportunities by importing new ADM or ADMX files.  For instance, Microsoft Office has an ADMX file as does other third party applications such as Adobe Reader and to some extent, Mozilla Firefox.   Well you can import additional ADMX files for MDM as well, although its currently not as easy as there is no central store for MDM like is the case for Group Policy.  There is no way (at present) to add additional ADMX templates with a couple clicks of the mouse, but with just a little bit of trouble, you can do it.

The process of importing ADM or ADMX files into MDM is called “ingesting.”  The ingesting process goes like this:

• We create a Custom Windows 10 policy
• We ingest the custom ADMX through the Policy CSP
• We apply the settings we want to enforce

So how do we ingest an ADMX file?  Well, in this case, ingesting means copy/paste.  You obtain the ADMX file you need and then open it in some type of editor such as Notepad.  For this example, I’m going to use the OneDrive.admx file.  I’m not going to show what the entire file looks like in Notepad, but here is what the first part of it looks like:

    
As discussed earlier, creating a custom policy means creating a Custom OMA-URI.  To ingest an ADMX file we must use the following format:

./Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/{AppName}/{SettingType}/{AdmxFileName}. 

I don’t want to get into the boring details concerning the naming of these variables.  Just follow the basic guideline that you should assign the (setting type) variable as “policy” and the other two variables should be meaningful names such as the actual name of the App and the actual name of the ADMX file.  You can name them anything you want actually but its always best to use names that are intuitive for other personnel.  In the case of our OneDrive ADMX example, that would translate to this:

./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/OneDrive/Policy/OneDriveAdmx

As you mentioned, copy the entire contents of the opened ADMX file in Notepad and paste it into the value text box as shown below:

Once the new profile is created, we can then use it to deliver the new supported settings using that profile.   

So we said that CSPs are embedded interfaces in the Windows 10 OS that give MDMs the ability to read, set, modify and delete configuration settings.  This gives administrators the ability to command and deliver settings for enterprise devices.

There are many CSPs, but there is one particular one that is special.  That one is the Policy CSP. 

Like all CSPs, the MDM engine takes directives from it.  What makes it prominent is that it contains so many of the common items that admins are used to managing in Group Policy.  For instance, the Policy CSP contains settings for common components such as:

• Browser
• Defender
• Device Guard
• Power
• Remote Desktop Services
• Update

For instance, may you want to prevent users from terminating a task in the Task Manager.  Well, the Policy CSP contains a TaskManager Policy and the name of the settings is TaskManager/AllowEndTask.  The data type for this setting is integer and the supported values are as follows:

• 0 - Disabled. EndTask functionality is blocked in TaskManager.
• 1 - Enabled (default). Users can perform EndTask in TaskManager.

The TaskManager Policy is supported in the following Windows 10 Editions.

Chart taken from https://docs.microsoft.com/en-us/windows/client-management/mdm/policy-csp-taskmanager

The Policy configuration service provider contains sub-categories.

• Policy/Config/AreaName – Handles the policy configuration request from the server.
• Policy/Result/AreaName – Provides a read-only path to policies enforced on the device.

The Policy CSP have a scope to which its settings can be configured.  Some policies have settings that only apply to the device itself regardless of who is logged on to it.  Others apply to the user which means that settings can vary depending on which user logs on.  Each policy includes a path that defines its scope.  The possible scope paths are as follows:

User scope:

• ./User/Vendor/MSFT/Policy/Config/AreaName/PolicyName to configure the policy.
• ./User/Vendor/MSFT/Policy/Result/AreaName/PolicyName to get the result.

Device scope:

• ./Device/Vendor/MSFT/Policy/Config/AreaName/PolicyName to configure the policy.
• ./Device/Vendor/MSFT/Policy/Result/AreaName/PolicyName to get the result.

This is a quick introduction to the PolicyCSP. In other blog articles we'll examine more how to take advantage of it.

CSP stands for Configuration Service Provider.  You might think Intune i somehow a CSP but that would be incorrect. 

Intune is an MDM service. 

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.  In our case, that means using Intune to do it.  In doing so, IT can be assured that all company devices are compliant with the standards and policies set forth by the organization.  Keep in mind that you can deliver setting configurations to CSPs through other means than an MDM such as Windows Configuration Designer, which is used to create provisioning packages.  

So what are these CSP’s?  Well, you can go to Microsoft’s website and look them up at https://docs.microsoft.com/en-us/windows/client-management/mdm/configuration-service-provider-reference.

Notice that not all operating system editions support each CSP because some settings are unique to select OS versions.  In addition, many CSP’s contain settings introduced in designated Windows versions.  This means that the settings are not supported in versions prior to that release.  

So let’s look at the inner workings of a CSP.  Let’s say you want to enable BitLocker for all the mobile devices used by your HR and Finance personnel.  Well, there is a CSP for that called BitLocker CSP.  If we look at the available settings for that CSP, they look like this:

Chart came from https://docs.microsoft.com/en-us/windows/client-management/mdm/bitlocker-csp

CSP settings accept some sort of data type value to enable or disable the setting.  In this case, the data types are integers, either a 0 or a 1.  A value of 0 disables the settings while a value of 1 enables it.  The setting RequireDeviceEncryption for instance allows an administrator to require the use of BitLocker encryption on designated devices.

So let’s say our security minded administrator wants to deliver an integer data value of “1” to the BitLocker CSP contained within the HR and Finance devices.  That administrator just needs an interface to configure, assign and deliver them, and that is where Intune comes in.  Below, a Profile was created called “BitLocker Settings”  that now delivers the selected Windows Encryption settings.

How easy was that?  Ridiculously simple indeed. 

Keep in mind that not all CSP settings are "surfaced" as settings within Intune. 

So what happens when we want to configure settings on a CSP that doesn’t appear in Intune?  Well, there are two options.  The first would be to sit and wait around with our fingers crossed and hope that Microsoft Intune developers will add our desired settings soon.  The other way is to take matters into our own hands and make a Custom OMA-URL.  So how do we do this?

A key (and useful) example is how to make MDM vs. GP more deterministic.  Starting with 1803 however, a policy called “ControlPolicyConflict/MDMWinsOverGP” was created to give you control over which one won.  So while the policy setting doesn’t appear by default, we can create a customized URI for it that will enforce the outcome we want. 

Intune provides an interface to create Custom OMA-URI policies within a profile.  We just have to provide some information which is outlined below. 

• Name
• Description
• OMA-URI
• Data Type
• Value

In the case of this CSP, the possible values are

• 0 (default)
• 1 - The MDM policy is used and the GP policy is blocked

In the case the creation process will look like this:

For more information concerning this particular CSP:

https://docs.microsoft.com/en-us/windows/client-management/mdm/policy-csp-controlpolicyconflict#controlpolicyconflict-mdmwinsovergp

But the point is: Don't have a "knob" for the setting? Make a custom OMA-URA and you're off to the races.