Group Policy analytics: how to map GPOs to MDM policies
Group Policy analytics is a Microsoft Intune tool that imports reports of your on-premises Group Policy Objects (GPOs), analyzes each setting, and shows which settings have an equivalent in cloud-based mobile device management (MDM), which are deprecated, and which have no match (Microsoft Learn). It answers the first question in any move from Active Directory to MDM: how much of your current policy can come with you.
The tool belongs to Intune, but the mapping behind it does not. Windows MDM settings are delivered through configuration service providers (CSPs), the same interface every Windows MDM uses. This guide explains how the analysis works, how to read the results, and how to decide where each GPO setting belongs, regardless of which MDM manages your devices.
What is Group Policy analytics?
Group Policy analytics compares each setting in an exported GPO against the CSPs Windows supports and reports the match. Microsoft made the tool generally available in 2023 (Microsoft Tech Community). The key facts from Microsoft’s documentation:
- Platform: Windows only.
- Access: Intune administrator, or a role with the Security baselines and Device Configuration permissions.
- Input: a GPO report saved from the Group Policy Management Console (GPMC) as an XML file, under 4 MB and with proper Unicode encoding.
- Coverage: settings that map to the Policy, PassportForWork (Windows Hello for Business), BitLocker, Firewall, AppLocker, and Group Policy Preferences CSPs. Anything else appears as an unknown setting.
- Known limit: non-ADMX settings are analyzed only in English, so GPOs written in other languages can show an inaccurate MDM support percentage.
How Group Policy analytics works
- Export the GPO. In GPMC, right-click the GPO, select Save report, and choose XML File as the file type. Split any GPO larger than 4 MB.
- Import it. In the Intune admin center, go to Devices, Manage devices, Group Policy analytics, then select Import and add one or more XML files. Add a scope tag if you use role-based access; otherwise, the Default tag applies.
- Review the results. Intune analyzes each file automatically and lists the GPO with an MDM Support percentage.
- Check readiness. The Summary tab and the Group Policy migration readiness report group settings by readiness. Reporting data can take about 20 minutes to update after you add or remove GPOs.
- Migrate supported settings. In Intune, the Migrate option creates a Settings Catalog profile from the supported settings (Microsoft Learn).
How to read the results
The MDM Support percentage on the GPO list is a headline, not a plan. The detail view, opened by selecting that percentage, is where the mapping work happens:
| Column | What it tells you |
|---|---|
| Setting Name | The GPO setting being analyzed |
| Group Policy Setting Category | The ADMX category, such as Microsoft Edge or Internet Explorer |
| MDM Support | Yes if a matching MDM setting exists, No if it does not, or a newer setting to migrate to instead |
| Value and Scope | The configured value, and whether it applies to the user or the device |
| Min OS Version | The oldest Windows build that supports the MDM equivalent |
| CSP Name and CSP Mapping | The CSP that carries the setting and its OMA-URI path |
Settings fall into three readiness groups:
| Readiness | Meaning | What to do |
|---|---|---|
| Ready for migration | A matching MDM setting exists | Map it to the Settings Catalog or Policy CSP |
| Not supported | No matching MDM setting | Check ADMX ingestion, a script, or whether you still need it |
| Deprecated | Applies to older Windows or Edge versions, or policies no longer used | Retire it rather than migrate it |
Source: Microsoft Learn, Group Policy analytics.
Mapping GPO categories to MDM policies
Group Policy analytics tells you whether a match exists. You still have to decide where each setting lands. Most GPO content falls into one of these paths:
| GPO content | MDM path | Notes |
|---|---|---|
| Windows administrative template settings with a CSP match | Settings Catalog or Policy CSP | The bulk of most GPOs. The Policy CSP is the general-purpose CSP for Windows 10 and Windows 11 policy (Microsoft Learn) |
| App settings from ADMX templates | Built-in catalog settings where they exist; otherwise ADMX ingestion | ADMX ingestion processes an app’s ADMX file into MDM policies through the Policy CSP. Ingested policies cannot write to System, Software\Microsoft, or Software\Policies\Microsoft, apart from listed exceptions such as Office and Edge (Microsoft Learn) |
| BitLocker | BitLocker CSP | Covered by Group Policy analytics |
| Windows Hello for Business | PassportForWork CSP | Covered by Group Policy analytics |
| Firewall rules and AppLocker | Firewall and AppLocker CSPs, through endpoint security policies | Analyzed, but Intune’s Migrate option does not convert these rules |
| Settings with no CSP | Script or redesign | Microsoft notes that settings custom policy ingestion cannot configure need their registry keys pushed directly, for example with PowerShell |
| Deprecated settings | None | Retire them; they target older Windows or Edge versions |
Two warnings apply to the scripted path. Registry changes pushed by script aren’t reported back as policy, so you lose the compliance view an MDM profile provides. And Microsoft’s ADMX ingestion page notes that MDM enforces some ingested policy values only on domain-joined devices, so test ingested settings on cloud-only devices before relying on them (Microsoft Learn). Settings outside the Settings Catalog are also where custom OMA-URI profiles come in; the OMA-URI vs. Settings Catalog comparison covers that decision.
Worked example: a screen lock timeout from GPO to MDM
This example follows one real setting through the mapping. A GPO locks idle sessions after 15 minutes, and the table below shows where that setting lands in MDM.
| Step | Worked example |
| Original GPO setting | Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Interactive logon: Machine inactivity limit |
| Configured value | 900 seconds (15 minutes) |
| Mapped CSP | Policy CSP, LocalPoliciesSecurityOptions area, setting InteractiveLogon_MachineInactivityLimit |
| OMA-URI | ./Device/Vendor/MSFT/Policy/Config/LocalPoliciesSecurityOptions/InteractiveLogon_MachineInactivityLimit |
| Data type and value | Integer, 900 (allowed range 0 to 599940; 0 disables the lock) |
| Applies to | Device scope; Windows 10 version 1709 and later; Pro, Enterprise, and Education editions |
| Destination policy | In Intune: a Settings Catalog profile, which is what the Migrate option creates. In another Windows MDM: a custom OMA-URI setting with the path, data type, and value above, where the MDM supports custom settings. |
To verify that it applied:
- Assign the profile to a pilot device and confirm the MDM console reports it as applied on that device.
- On the device, go to Settings, Accounts, Access work or school, select the work account, select Info, then Create report. Open the HTML report saved in C:\Users\Public\Documents\MDMDiagnostics and confirm that InteractiveLogon_MachineInactivityLimit shows 900.
- Restart the device, leave it idle for 15 minutes, and confirm the session locks. Microsoft notes that this policy requires a restart to take effect when set through Group Policy.
- While the GPO is still linked to the device, resolve the overlap. This setting is in the Policy CSP, so the MDMWinsOverGP policy described below applies to it.
Sources: Microsoft Learn, LocalPoliciesSecurityOptions CSP; Interactive logon: Machine inactivity limit; Collect MDM logs.
A GPO-to-MDM migration workflow
- Inventory and clean up. Export every GPO linked to the devices you plan to move. Remove disabled, duplicate, and unlinked GPOs before analysis so the results reflect what actually applies.
- Analyze. Run the exports through Group Policy analytics and record each setting’s readiness.
- Decide per setting. Map, ingest, script, or retire, following the paths above. Retiring is often the right call: many long-lived GPOs carry settings for Windows versions no longer in use.
- Build and pilot. Create MDM profiles and assign them to a pilot group of devices. Microsoft advises against migrating every setting without review and describes its Migrate feature as best-effort (Microsoft Learn).
- Control conflicts during coexistence. While devices still receive GPOs, decide which source wins (see the next section).
- Decommission. Unlink GPOs from migrated devices once the pilot confirms the MDM profiles apply as expected.
If you are also changing MDM vendors at the same time, the MDM migration checklist covers device re-enrollment. New Windows devices can skip the GPO step entirely with Windows Autopilot, and Windows LAPS moves local admin passwords to the cloud.
When Group Policy and MDM set the same setting
During a phased migration, many devices receive both GPOs and MDM policy. If both configure the same setting without a rule, Microsoft says there is a race condition and no guarantee which one wins (Microsoft Learn). The ControlPolicyConflict/MDMWinsOverGP policy, available from Windows 10 version 1803, makes MDM take precedence, with limits:
- It applies only to settings in the Policy CSP, not to equivalents in other CSPs such as the Defender CSP.
- It applies at device scope only.
- For Windows Update conflicts, Microsoft recommends a separate setting, IgnoreWindowsUpdateGroupPolicies.
The cleaner option is to unlink overlapping GPOs from migrated devices as soon as the pilot passes, so only one source configures each setting.
Using the results with any Windows MDM
The CSP Name and CSP Mapping columns are part of the analysis that travels. They give the CSP and OMA-URI path for each supported setting, which any Windows MDM that accepts custom OMA-URI settings can use. Group Policy analytics itself runs only inside the Intune admin center.
Bento MDM manages Windows devices alongside Android, iOS, macOS, and Linux from one console; see Windows device management for the feature set. For settings with no CSP, Bento supports PowerShell scripting on Windows devices. For a broader view of what MDM can and cannot replace on Windows, see the guide to Windows device management with MDM.
Bento MDM’s Windows documentation describes these capabilities:
- GPO import: import existing Group Policy Objects, with their registry settings and configurations applied centrally.
- Built-in Windows policies: security baselines, encryption and access policies, Windows Defender antivirus settings, and firewall rules.
- Scripts: shell and PowerShell scripts, the route for settings that have no CSP.
- Directory and enrollment: Active Directory and Azure AD integration for group-based policy, and Windows Autopilot for first-boot setup.
Importing a GPO and configuring equivalent CSP settings are two different routes. Importing works from the GPO itself and carries its settings over as-is. Configuring CSP settings, as in the worked example above, rebuilds each setting as an MDM policy that the device reports on. Group Policy analytics supports only the second route, and only inside Intune: its Migrate option creates an Intune Settings Catalog profile, and that profile does not transfer into Bento MDM or any other MDM. What carries over is the analysis itself: the list of settings worth keeping and the CSP and OMA-URI path for each.
Frequently asked questions
It imports XML reports of your on-premises GPOs into Microsoft Intune, compares each setting against Windows CSPs, and reports which settings are ready for migration, not supported, or deprecated, along with the CSP and OMA-URI path for each match.
No. The Migrate option creates a Settings Catalog profile only from settings that match, and Microsoft calls it best effort. This method can’t migrate firewall and AppLocker rules, and settings outside the supported CSPs appear as unknown.
An XML report saved from the Group Policy Management Console, under 4 MB per GPO and with proper Unicode encoding.
Yes, but settings configured by both can conflict, with no guaranteed winner. The MDMWinsOverGP policy gives MDM precedence for Policy CSP settings on Windows 10 version 1803 and later; unlinking overlapping GPOs is the cleaner long-term fix.
Migrate less, retire more
Group Policy analytics turns years of accumulated GPOs into an actionable list. The goal is not to recreate Active Directory in the cloud by setting it up. It is to carry forward the policies your devices still need, deliver them through CSPs any Windows MDM can manage, and leave the rest behind.
Related Articles
