You have spent years perfecting your Group Policy Objects. Dozens of GPOs, carefully nested OUs, inheritance rules you documented once and never looked at again. And yet here you are, managing a workforce where half your devices never touch the corporate network. GPOs require line-of-sight to a domain controller. Microsoft Intune does not. That single difference changes everything about how you manage Windows endpoints.
The good news is you do not have to start from scratch. Microsoft built Group Policy Analytics directly into the Intune admin center. It reads your existing GPO exports, tells you exactly which settings translate to cloud-native equivalents, and can migrate supported settings into Settings Catalog profiles with a few clicks. The bad news is that not everything migrates cleanly, and the tool does not tell you that upfront.
This walkthrough takes you through the full migration lifecycle: exporting your GPOs, analyzing them with Group Policy Analytics, migrating what the tool supports, and handling everything it leaves behind.
Prerequisites
Before you start, confirm you have these in place:
-
Intune Administrator role (or a custom role with Security Baselines and Device Configurations/Create permissions)
-
Group Policy Management Console (GPMC) installed on your management workstation
-
Windows 10 or 11 target devices—Group Policy Analytics only analyzes policies for these operating systems
-
A test Azure AD group for piloting migrated profiles before broad deployment
Reality Check: Group Policy Analytics does not support Windows Server policies or earlier client OS versions. If your GPOs target Server 2019 or Windows 8.1, those settings are invisible to this tool.
Export Your GPOs as XML
The migration starts on your domain controller or any workstation running GPMC. You need XML exports—not the HTML reports that GPMC defaults to.
Open GPMC.msc, expand your domain, and navigate to the Group Policy Objects container. Right-click the GPO you want to migrate and select Save Report. Here is the part that trips people up: in the “Save as type” dropdown, change the format from HTML to XML File (*.xml). HTML exports look nice but are completely useless for Intune analysis.
# Export a single GPO to XML via PowerShell Get-GPOReport -Name "Desktop Security Policy" -ReportType Xml -Path "C:\GPOExports\DesktopSecurity.xml"
# Bulk export all GPOs in the domain
Get-GPO -All | ForEach-Object {
Get-GPOReport -Guid $_.Id -ReportType Xml -Path "C:\GPOExports\$($_.DisplayName).xml"
}
Before uploading, check your file sizes. Intune enforces a 4 MB limit per GPO XML file. If a GPO exceeds that, you will need to split it or remove deprecated settings before exporting. The XML must also be Unicode-encoded—anything else fails silently on import.
Pro Tip: Run the bulk export first, then sort by file size. You will immediately see which GPOs need trimming before they hit the Intune import wall.
Import and Analyze in the Intune Admin Center
With your XML files ready, open the Intune admin center and navigate to Devices > Group Policy analytics. Click Import, upload your XML, and optionally assign Scope Tags to control which administrators can see the imported GPO. If you skip scope tags, the Default tag applies automatically.
After import, Intune displays each GPO with an MDM Support percentage. This number represents the ratio of settings that have a direct equivalent in the Settings Catalog.
Click the MDM Support percentage to drill into individual settings. Each one lands in one of three buckets:
| Status | What It Means | Your Move |
|---|---|---|
| Ready for migration | Direct match in the Settings Catalog | Migrate using the built-in wizard |
| Not supported | No matching MDM setting exists | Handle via PowerShell scripts or custom OMA-URI |
| Deprecated | Targets legacy features like IE8 settings | Retire—do not migrate dead weight |
You may also see an Unknown column for settings the analytics engine identified but could not categorize. These typically involve custom registry keys or third-party ADMX settings that fall outside the standard CSP mappings.
Migrate Supported Settings
For settings marked “Ready for migration,” Group Policy Analytics provides a one-click migration path.
Select the GPO from your analysis results, click Migrate, and choose the settings you want to include. The tool creates a new Settings Catalog profile and pre-populates values directly from your GPO—enabled/disabled states, numeric values, string configurations, all of it.
# After migration, verify the new profile exists # Connect to Microsoft Graph Connect-MgGraph -Scopes "DeviceManagementConfiguration.Read.All" # List Settings Catalog profiles Get-MgDeviceManagementConfigurationPolicy | Select-Object Name, CreatedDateTime
Review every pre-populated value before assigning the profile. The migration is best-effort—if a setting has an unexpected format or a missing child dependency, the value may not transfer correctly.
Warning: Complex settings like AppLocker rules and Windows Firewall configurations are often grayed out in the migration wizard. Microsoft recommends configuring these through the dedicated Endpoint Security workload rather than the Settings Catalog.
Two important details about the destination profile type. Microsoft now recommends the Settings Catalog for all new policy configurations. The legacy “Administrative Templates” profile type is being phased out—you cannot create new ones, and existing ones should be migrated to Settings Catalog profiles. The Group Policy Analytics migration tool targets the Settings Catalog by default, so you are already on the right path.
Handle the Settings That Do Not Migrate
Here is where the real work starts. Group Policy Analytics handles OS configuration policies well, but Group Policy Preferences (GPP)—drive mappings, printer deployments, scheduled tasks, shortcuts—do not come along for the ride.
Drive Mappings
Your users still need their H:\ drive and their department shares. Three approaches, ranked by how cloud-native they are:
| Approach | Effort | Cloud-Native Level | Best For |
|---|---|---|---|
| ADMX ingestion | Medium | Partial | Quick wins with existing UNC paths |
| PowerShell scripts | Low | Partial | Flexible, one-off deployments |
| Azure Files | High | Full | Long-term cloud-first strategy |
-
ADMX ingestion: Download a custom
DriveMapping.admxand its.admllanguage file, import them to Intune under Devices > Configuration > Import ADMX, and create a profile using Imported Administrative Templates. This gets drive maps into the Settings Catalog workflow. -
PowerShell scripts: Deploy a logon script through Intune’s script deployment feature. Wrap your
New-PSDrivecommands in a script and deploy it as a Win32 app or platform script. You lose item-level targeting, but gain flexibility. -
Azure Files: Replace your on-premises UNC paths with Azure Files shares mounted via SMB. This is the architectural endgame but requires infrastructure changes.
Yes, that is three options ranked from “cloud-ish” to “actually cloud.” Pick whichever matches your tolerance for infrastructure changes this quarter.
Printer Deployments
Legacy Group Policy printer deployments do not translate to Intune policies through Group Policy Analytics. You know those printer GPOs you have been maintaining since 2014? Time to rethink them. Your options:
| Approach | Print Server Required | Best For |
|---|---|---|
| Universal Print | No | New printer deployments, cloud-first orgs |
| Win32 app packaging | Yes (for driver extraction) | Legacy printers you cannot replace yet |
-
Universal Print: Microsoft’s cloud-based replacement for on-premises print servers. Intune has a native policy type for Universal Print provisioning. If you are buying new printers anyway, this is the path forward.
-
Win32 app packaging: For existing network printers, package the printer driver and installation logic into an
.intunewinfile. Tools likePackageMyPrinters.ps1can automate extracting driver details from your print server and wrapping them for Intune deployment.
Registry Keys and Custom Settings
For settings that show up as “Unknown” or rely on direct registry manipulation:
# Deploy registry settings via Intune PowerShell script Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\YourApp" -Name "SettingName" -Value 1 -Type DWord
You can deploy this through Proactive Remediations (requires specific licensing), which detect configuration drift and correct it automatically. For one-off settings, a simple platform script works. For CSPs not yet in the Settings Catalog, custom OMA-URI profiles let you target the MDM path directly.
Manage the Hybrid Transition
Unless you are cutting over to cloud-only in a single weekend—and you probably are not—your devices will receive policies from both GPO and Intune simultaneously. This creates conflicts.
The fix is the MDMWinsOverGP policy. Set it to 1, and Intune settings take precedence over conflicting GPOs for any setting covered by the Policy CSP.
# Verify MDMWinsOverGP is applied on a client device Get-ItemProperty -Path "HKLM:\Software\Microsoft\PolicyManager\current\device\ControlPolicyConflict" -Name "MDMWinsOverGP"
One critical caveat: MDMWinsOverGP only covers the Policy CSP. Not every CSP gets the override treatment.
| CSP | MDMWinsOverGP Coverage | If Conflict Exists |
|---|---|---|
| Policy CSP | Covered | Intune wins automatically |
| Defender CSP | Not covered | Unlink the GPO manually |
| Windows Update CSP | Not covered | Unlink the GPO manually |
| BitLocker CSP | Not covered | Unlink the GPO manually |
For settings in uncovered CSPs, you must explicitly unlink or disable the conflicting GPO on your domain controllers. There is no MDM override—you have to remove the source.
Validate Before You Deploy Wide
Do not push migrated profiles to your entire fleet on day one. Build a validation workflow:
-
Assign to a pilot group: Create an Azure AD security group with a handful of test devices. Assign your migrated Settings Catalog profiles exclusively to this group.
-
Run MDM diagnostics on a test device: Generate the
MDMDiagReport.htmlon a client device to verify which policies—GPO versus MDM—are actually applying.
# Generate MDM diagnostic report on the client mdmdiagnosticstool.exe -out C:\MDMDiag # Open the generated MDMDiagReport.html to review applied policies
-
Compare against your GPO baseline: Confirm that every “Ready for migration” setting is applying correctly via Intune and that no GPO is overriding it unexpectedly.
-
Expand in rings: Once the pilot validates clean, expand to the next ring. Keep the GPOs linked but set
MDMWinsOverGPso Intune wins. Only unlink GPOs after you have confirmed Intune coverage across all targeted settings.
Rationalize, Do Not Just Migrate
One final piece of advice before you start uploading XML files. Do not treat this as a lift-and-shift exercise. Your GPO environment almost certainly contains settings targeting Internet Explorer 6, Windows XP policies somebody forgot to clean up, and conflicting configurations across overlapping OUs.
Group Policy Analytics will flag these as “Deprecated,” but it will not tell you to delete them. That is your job. Use this migration as an opportunity to audit your policy baseline. Start with Intune Security Baselines as your foundation for security settings rather than migrating 15-year-old GPO security policies line by line. The baselines reflect current Microsoft security recommendations and save you from carrying forward technical debt that should have been retired years ago.
The end state is not “my GPOs in the cloud.” It is a modern, maintainable policy set that works whether your devices are in the office, at home, or at a coffee shop with questionable Wi-Fi.
