Ditch the GPOs: Migrate to Microsoft Intune

Ditch the GPOs: Migrate to Microsoft Intune

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

  1. ADMX ingestion: Download a custom DriveMapping.admx and its .adml language 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.

  2. PowerShell scripts: Deploy a logon script through Intune’s script deployment feature. Wrap your New-PSDrive commands in a script and deploy it as a Win32 app or platform script. You lose item-level targeting, but gain flexibility.

  3. 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 .intunewin file. Tools like PackageMyPrinters.ps1 can 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:

  1. 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.

  2. Run MDM diagnostics on a test device: Generate the MDMDiagReport.html on 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

  1. 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.

  2. Expand in rings: Once the pilot validates clean, expand to the next ring. Keep the GPOs linked but set MDMWinsOverGP so 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.