Let me start this blog by saying Group Policy (GPO) is not dying.

Group Policy is the best way to granularly configure domain joined Windows PCs and tablets connected to the corporate network using Windows-based tools. Microsoft continues to add Group Policy settings with each new version of Windows.

So, if we look at the flowchart Microsoft provides, it’s clear that GPOs are still the best method to manage settings granularly.

Given the current situation due to COVID19 most organizations have their employees working from home and none of the devices are not under the direct sight of a Domain Controller for the GPOs to apply. This is where the Intune MDM solution with its modern management capabilities, urge most organizations to move away from the traditional GPOs to using MDM solutions for managing their endpoints.  

Tools available:

Microsoft has introduced the MMAT (MDM Migration Analysis Tool) long back to help IT Admins in analyzing their GPO settings against what is supported in the MDM space.
Group Policy analytics is the newest feature in Microsoft Endpoint Manager (a.k.a Intune) that analyzes your on-premises GPOs. It helps you determine how your GPOs translate in the cloud. The output shows which settings are supported in MDM providers, including Microsoft Intune. It also shows any deprecated settings, or settings not available to MDM providers.

Both the MMAT and the Group Policy Analytics tools will give you the OMA URIs that can be used to configure the Intune policies. However, they do not tell you if there are clickable versions of those settings in Intune policies.

So how do we proceed with the transition?

Here are the high-level steps involved in the transition

1. Export the required GPOs from your on-premise Active Directory in .xml format
2. Import the GPO XML files into Group Policy Analytics in Intune
3. Download the results of the analysis
4. Deploy the MDMWinsOverGP settings to all managed devices from Intune so that Intune takes precedence over GPO if applied.
5. Configure the supported settings into Intune via Administrative Templates (available in Intune Device Configuration Policies) and create custom policies with OMA-URIs for non ADMX supported settings.
6. Assign the policies to the Windows devices

Done!!!

Now, I will not be discussing on how to export the GPOs into .xml format and importing them into Intune > Group Policy Analytics as there are a plethora of articles in Google. What I will cover in this blog is points 4 to 6.

4. Configure MDMWinsOverGP

In Windows 10 versions 1709 and earlier, Group Policy would override MDM policies, even if an identical policy is configured in MDM. With Windows 10 version 1803 and beyond, there is a new Policy CSP setting called ControlPolicyConflict that includes the policy of MDMWinsOverGP, where the preference of which policy wins can be controlled.

Let’s create a new policy in Intune to control the GP vs. MDM winner

1. Navigate to endpoint.microsoft.com
2. Select Device configuration Profiles > Create profile
3. Under Platform select Windows 10 and later
4. Under Profile type select “custom” and “add“
5. Name the custom setting as ControlPolicyConflict-MDM Wins (you can give any name)
6. For OMA-URI add the policy OMA-URI string: ./Device/Vendor/MSFT/Policy/Config/ControlPolicyConflict/MDMWinsOverGP
7. For Data type select Integer and enter the value as 1
8. Assign it to All Devices.

This will ensure that if there is a conflict between GPO and Intune, Intune wins.
More details on the Microsoft article here

Note: Group Policy will re-apply the policies if the device is unenrolled from Intune.

5. Create Device Configuration Policies and Administrative Templates in Intune

As you have already imported your GPO XMLs into Intune’s – Group Policy Analytics you should be able to see all the settings that are ADMX supported, non-Admx but MDM supported (via OMA-URIs) and the unsupported one’s.

Note: Unsupported settings (no Admx or MDM support) do not have CSP Mappings – and those could be settings that are too granular for devices non-managed by Group Policy.

Now that we have the export of the Group Policy Analytics we can convert them into

1. Administrative Templates
2. Custom policies (OMA-URI)

Administrative templates:
These are the ADMX supported settings that you configure. If you’re familiar with ADMX policies or group policy objects (GPO), then configuring them is a cake walk in Microsoft Intune.
For more information, see the Microsoft Documentation for Administrative Templates and it has detailed instructions on how to search and configure the settings which are ADMX supported.

Custom Policy:
In the MEM admin center, go to Devices > Windows > Configuration profiles > + Create profile > select Windows 10 and later for Platform and Templates for Profile type and select Custom

Give a suitable name for the profile and you’ll see a OMA-URI settings pane. Here’s where you copy the CSP Mapping and Value from the Group Policy Analysis page. For example, if I wanted to migrate Show first sign-in animation, I will copy the values from the analysis page and configure it as below:

Add all the required non-ADMX supported settings into the Custom policy and at the end it would look like the below

You can then click the Review + save and assign it to your devices or users. That’s it, you have successfully converted the GPO settings!

Want to know a better way of converting?

What if I said there is a way to convert the GPOs into Intune clickable settings (like toggling Enable/Disable) instead of configuring Custom policies with hundreds of OMA-URIs?
Yes, Intune has several Device Configuration Profile types that you can use to configure 90% of the supported settings instead of using OMA-URIs.

What is the risk of using OMA-URIs and what is the benefit of using clickable settings?

Let’s say you want to disable the camera using a CSP setting within Windows 10, you create the custom policy with the OMA-URI path and apply it to all the Windows 10 devices. Now if you want to revert the same setting and enable camera, simply un-assigning the custom policy or deleting the OMA-URI entry from the policy doesn’t revert the setting that you had previously applied (disable camera). So the only way you can revert or revoke the custom URI policies, is to write another profile which undo’s the setting.

So my recommendation to all EUC Architects out there would be to configure your settings using clickable options found under the Profile type – Templates.

Have a question on which settings to configure instead of OMA-URIs?
Contact me/post your questions and I can guide you.