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 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
Export the required GPOs from your on-premise Active Directory in .xml format
Import the GPO XML files into Group Policy Analytics in Intune
Download the results of the analysis
Deploy the MDMWinsOverGP settings to all managed devices from Intune so that Intune takes precedence over GPO if applied.
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.
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
Navigate to endpoint.microsoft.com
Select Device configuration Profiles > Create profile
Under Platform select Windows 10 and later
Under Profile type select “custom” and “add“
Name the custom setting as ControlPolicyConflict-MDM Wins (you can give any name)
For OMA-URI add the policy OMA-URI string: ./Device/Vendor/MSFT/Policy/Config/ControlPolicyConflict/MDMWinsOverGP
For Data type select Integer and enter the value as 1
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
Administrative Templates
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?
Microsoft has improved the Group Policy Analytics by including an option to create an Intune policy with the GPO settings that are compatible. Kudos! as this saves us a lot of time.
After you import your GPOs, review the settings that can be migrated. Remember, some settings don't make sense on cloud native endpoints, like Windows 10/11 devices. After they've been reviewed, you can migrate the settings to a Settings Catalog policy.
1. In the Microsoft Endpoint Manager admin center, select Devices > Group Policy analytics (preview).
2. In the list, your imported GPOs are shown. Next to the GPO you want in your Settings Catalog profile, select the Migrate checkbox. You can select one GPO or many GPOs:
3. To see all the settings in your imported GPO, select Migrate:
4. In the Settings to migrate tab, select the Migrate column for the settings you want to include in your Settings Catalog profile:
To help you pick the settings, you can use the built-in features:
Select all on this page: Select this option if you want all settings on the existing page to be included in your Settings Catalog profile.
Search by setting name: Enter the setting name to find the settings you want:
Sort: Sort the settings using the column names:
Note: Some settings don't apply to cloud-based policy management or don't apply to cloud native endpoints, like Windows 10/11 devices. These settings will be greyed out and cannot be chosen. It's recommended to review the settings on each page and include the required settings that you want to migrate.
5. Select Next.
6. In Configuration, your settings and their values are shown. The values are the same values in the on-premises Group Policy. Review these settings and their values. After you create the Settings Catalog policy, you can change any values. Select Next.
7. In Profile info, enter the following settings:
Name: Enter a descriptive name for the Setting Catalog profile. Name your profiles so you can easily identify them later. For example, a good profile name is Windows 10/11: Imported Microsoft Edge GPOs.
Description: Enter a description for the profile. This setting is optional, but recommended.
8. Select Next.
9. In Assignments, select the user or groups that will receive your profile. For more information on assigning profiles, including advice and guidance, go to Assign user and device profiles in Intune. Select Next.
10. In Review + deploy, review your settings.
When you select Create, your changes are saved, and the profile is assigned. The policy is shown in the Devices > Configuration profiles list.
The next time any device within your assigned groups checks for configuration updates, the settings you configured are applied.
Conflicting Settings - detected early
It's possible you have multiple GPOs that include the same setting, and that the setting is set to different values. When you're creating a policy, and selecting your settings in the Settings to migrate tab, any conflicting settings will show the following error:
Conflicts are detected for the following settings: <setting name>. Select only one version with the value you prefer in order to continue.
To resolve the conflict, uncheck a conflicting setting, and continue the migration.
The Migration
The Migrate feature takes the parsed data from the imported Group Policy object (GPO) and translates it to a relevant setting in the Settings Catalog, if the setting exists.
Migrate is best effort.
When you create the Settings Catalog profile, any settings that can be included in the profile will be included. There can be some differences with the imported settings and the settings in Settings Catalog.
Some settings don't migrate exactly, and may use a different setting In some scenarios, some GPO settings won't migrate to the exact same setting in the Settings Catalog. Intune will show an alternate setting that has a similar effect. For example, you may see this behavior if you import GPOs that include older Office Administrative Template settings or older Google Chrome settings.
Some settings fail to migrate It's possible there will be some errors when the settings are migrating. When the profile is being created, settings that return an error are shown in Notifications:
Some common reasons a setting may show an error include:
The setting value is in an unexpected format.
A child setting is missing from the imported GPO and is required to configure the parent setting.
Review the settings that failed to migrate and change the values to a supported format.
What is the risk of using OMA-URIs and what is the benefit of using the Migrate feature?
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 use the migrate feature to easily migrate the bulk of the GPO settings to Intune settings catalog and the unsupported settings can be converted to a Custom OMA-URI (only if required).