GPO-to-Intune Migration — Structured Policy Buildout
Organizations managing Windows devices through Active Directory Group Policy accumulate GPO estates over years. By the time a modern endpoint management initiative begins, the typical environment has hundreds of GPOs — many obsolete, many overlapping, most without documentation. Migrating them one-to-one into Intune imports the technical debt wholesale.
This chapter describes a top-down, Intune-first approach that treats the existing GPO estate as a source of requirements rather than a migration target. The goal is not to reproduce Group Policy in Intune — it is to build a mature, well-structured Intune policy framework and validate it against what Group Policy was actually enforcing.
The Top-Down Approach
The one-to-one migration instinct is understandable but wrong. Each GPO that gets mapped to an Intune configuration profile carries forward its original context, naming, and scope — which was almost never designed with Intune in mind. The result is the same organic mess in a different tool.
The alternative:
- Define the target state first. Use the Open Intune Baseline (OIB) as the structural foundation. Determine what a well-organized Intune policy set looks like before touching the existing GPOs.
- Treat GPO settings as requirements. Export a Group Policy Analytics report. Use it to validate that your target Intune policies cover the settings that GPOs were enforcing. Fill gaps; discard settings that are obsolete or no longer applicable.
- Build clean, consolidated policies. Fewer policies with clear names and documented purpose are easier to audit, easier to troubleshoot, and easier to hand off.
- Retire the ad-hoc layer. Disable existing organically grown Intune policies as the structured framework subsumes them.
This approach produces a policy set that is defensible in an audit, maintainable over time, and smaller than the original GPO estate.
Group Policy Analytics
Group Policy Analytics is built into the Intune portal (Devices > Windows > Group Policy Analytics). It ingests a GPO XML export and classifies each setting:
| Classification | Meaning |
|---|---|
| MDM supported | A direct CSP equivalent exists in Intune — setting can be migrated as-is |
| Deprecated | Setting targets an obsolete OS feature; do not migrate |
| MDM parity | Equivalent control exists but the implementation path differs — requires manual mapping |
| Not supported | No MDM equivalent; requires a Platform Script, Remediation, or no action |
The MDM readiness percentage shown per GPO is the fraction of its settings that fall in the MDM supported category. A GPO at 100% can be mechanically migrated; a GPO at 0% requires a different workstream entirely (scripts, Win32 apps, or accepted risk).
Running the Analysis
- Export GPOs to XML: On a domain controller or management workstation with the Group Policy Management Console (GPMC) installed, run:
# Export a single GPO
Get-GPO -Name "PolicyName" | Get-GPOReport -ReportType XML -Path ".\GPOName.xml"
# Export all GPOs in the domain
Get-GPO -All | ForEach-Object {
Get-GPOReport -Guid $_.Id -ReportType XML -Path ".\GPOExports\$($_.DisplayName).xml"
} - Upload to Intune: Devices > Windows > Group Policy Analytics > Import — upload individual XML files or a ZIP containing multiple exports.
- Review the report: Filter by MDM support percentage. Sort to identify high-readiness GPOs (quick wins) and zero-readiness GPOs (alternate workstreams).
- Export the settings-level detail: The summary view shows per-GPO readiness; the drill-down shows per-setting CSP mappings. Export the settings-level CSV for use during policy buildout — this is the primary working artifact. Each row is one setting from one GPO: setting name, CSP path, MDM support state, and the source GPO. Sort by MDM support state and functional category to build your policy map.
A single GPO may contain settings that belong in three different target Intune policies. Work from the settings-level export, organized by functional category, not from the GPO list. In large estates, 60–80% of settings across specialized-environment GPOs are duplicates of each other — identifying the shared base before building per-environment supplements dramatically reduces the policy count.
Policy Framework and Naming Convention
The OIB naming convention provides a consistent structure for every Intune policy in the environment. All policies — whether they are direct OIB imports or organization-specific additions — should follow this schema:
Win - [OIB|ORG] - [ES|SC|U] - [Function] - [D|U] - [Description] - v[Version]
| Token | Values | Meaning |
|---|---|---|
Win | Win, iOS, macOS, Android | Platform |
OIB or ORG | OIB = Open Intune Baseline standard; org prefix for org-specific policies | Policy source/ownership |
ES / SC / U | ES = Endpoint Security; SC = Security Compliance / Configuration; U = User-level | Policy category |
| Function | Attack Surface Reduction, Browser, Firewall, etc. | Functional area |
D / U | D = Device scope; U = User scope | Assignment scope |
| Description | Short descriptor | Distinguishes policies in the same function |
| Version | v1.0, v1.1 | Change tracking |
Example: Win - OIB - ES - Attack Surface Reduction - D - ASR Rules - v1.0
Organization-specific policies that extend or deviate from OIB defaults use the org prefix instead of OIB:
Example: Win - COC - SC - Browser - D - Microsoft Edge - v1.0 (City of Cleveland-specific Edge configuration)
This naming convention makes the policy list self-documenting: scope, ownership, and function are visible without opening the policy.
Policy Taxonomy by Tier
Organize the build and deployment sequence into five tiers, ordered by security impact and risk.
Tier 1 — Security Foundation
Deploy first. These policies establish the security posture for all managed Windows devices and produce the most significant compliance and security improvement per unit of effort.
| Policy Area | OIB Equivalent | What It Covers |
|---|---|---|
| Attack Surface Reduction | Win - OIB - ES - Attack Surface Reduction - D - ASR Rules | ASR rules, exploit mitigations |
| Exploit Protection | Win - OIB - ES - Attack Surface Reduction - D - Exploit Protection | System-wide DEP, ASLR, SEHOP |
| Defender Antivirus | Win - OIB - ES - Defender Antivirus - D - AV Configuration | Real-time protection, cloud protection, scan schedule |
| Defender Security Experience | Win - OIB - ES - Defender Antivirus - D - Security Experience | Notification management, tamper protection UI |
| EDR Onboarding | Win - OIB - ES - Defender for Endpoint - D - EDR | Automated onboarding to Microsoft Defender for Endpoint |
| BitLocker | Win - OIB - ES - Encryption - D - BitLocker (OS Disk) | XTS-AES 256-bit encryption, recovery key escrow to Entra ID |
| Windows Firewall | Win - OIB - ES - Firewall - D - Firewall Rules | Domain, private, and public profiles |
| Windows LAPS | Win - OIB - ES - Windows LAPS - D - LAPS Configuration | Local admin password rotation and escrow |
| Removable Media Control | Win - OIB - ES - Attack Surface Reduction - D - Device Control | USB and removable storage allowlist |
Most environments with a GPO estate also have organically built Intune policies covering some of these areas. Diff the existing Intune policy settings against the OIB equivalents before enabling the OIB version. Specific settings (ASR rule exclusions, AV exclusions, LAPS account names) are often customized in the existing policies and must be carried forward.
Tier 2 — Identity and Compliance
| Policy Area | OIB Equivalent | What It Covers |
|---|---|---|
| Windows Hello for Business | Win - OIB - ES - Windows Hello for Business - D - WHfB Configuration | Passwordless authentication, biometrics |
| Cloud Kerberos Trust | Win - OIB - ES - Windows Hello for Business - D - Cloud Kerberos Trust | SSO to on-premises resources for Hybrid environments |
| Local Security Policies | Win - OIB - SC - Device Security - D - Local Security Policies | Account lockout, audit policies, user rights assignments |
| Compliance Policy | Win - [ORG] - Compliance - D - Windows Workstation | BitLocker required, Secure Boot, minimum OS version, firewall and AV state, MDE risk score — drives Conditional Access enforcement |
The compliance policy is the enforcement layer. Tier 1 policies establish the security controls; the compliance policy verifies they are in place and signals Conditional Access whether to permit or block device access.
Tier 3 — Device Configuration
| Policy Area | Coverage |
|---|---|
| Login and lock screen | Screen timeout, lock behavior, inactivity policy |
| Windows Update for Business | Diagnostic data, update compliance reporting (separate from Update Rings — see Tier 4) |
| Browser configuration | Homepage, security zones, enterprise site lists, cache settings |
| OneDrive KFM | Known Folder Move silent configuration, sync settings |
| Productivity apps | Office licensing, modern auth, PST disable |
| Remote access | Remote Desktop, Remote Assistance settings |
| Time synchronization | NTP configuration — often 5-10 GPOs consolidated into one Intune policy |
| Network and proxy | Proxy settings per environment or department group |
Tier 4 — Windows Update Rings
Replace all Windows Update GPOs with a structured Windows Update for Business (WUfB) deployment. The standard ring structure:
| Ring | Typical Target | Quality Deferral | Feature Deferral |
|---|---|---|---|
| IT / Dev | IT staff, administrators | 0 days | 0 days |
| Pilot | Early adopters | 3 days | 0 days |
| General | Standard workforce | 7–10 days | 0 days |
| Critical Ops | Mission-critical devices (dispatch, emergency services, production control) | 14 days | Use Feature Update policy |
Critical Ops devices — those running dispatch, emergency services, or production control software — require extended quality deferrals and thorough validation before feature updates are applied. Rather than setting a long feature deferral period on the update ring (which is hard to manage over time), target a specific Windows version using a separate Feature Update policy and update the target annually. Maintain Group Policy as a fallback for these devices during the WUfB transition.
GPOs that disable Windows Update entirely (Disable Windows Updates x64, Disable Windows Updates x86, or similar) represent an active security risk — they prevent devices from receiving security patches. These must be retired immediately, before the WUfB migration is complete, by assigning affected devices to the Critical Ops ring as an interim measure.
Tier 5 — Specialized Environments
These are higher-risk migrations requiring extended piloting. Before building any Tier 5 policy, audit the settings-level export for cross-environment overlap — in most organizations with specialized devices, 60–80% of settings across environment-specific GPOs are identical. Build a Base Lockdown policy containing shared settings first, then layer environment-specific supplements on top.
Layered architecture pattern:
Base Lockdown Policy (~80 shared settings)
→ Assigned to: all restricted / specialized device groups
+ MDT Supplement (~25 unique settings) → MDT/CAD devices
+ Dispatch Supplement (~15 unique settings) → Dispatch terminals
+ Kiosk Supplement (~15 unique settings) → Shared kiosk devices
+ VDI Supplement (~30 unique settings) → Virtual desktops
+ App Supplement (~33 unique settings) → Per-application policy
Typical shared settings that belong in the base policy: Start Menu restrictions, desktop lockdown, File Explorer restrictions, command prompt and registry editor blocking, screensaver enforcement, Task Manager removal, Lock Computer removal.
Environment types:
- Mission-critical / operational devices — CAD systems, dispatch terminals, vehicle-mounted computers. Cannot tolerate unplanned reboots or feature changes. Extended pilot with a dedicated device group; maintain GP as fallback throughout.
- Kiosk and shared devices — Single-app and multi-app kiosk configurations; power management; LAPS for shared local admin accounts.
- VDI / virtual clients — Virtual machine optimization settings for AVD or W365 session hosts. Verify whether any Defender or system-restore settings in existing VDI GPOs were intentionally disabled for non-persistent images.
- Application-specific policies — Settings that exist to support a specific line-of-business application. Validate that the application is still in active use before building a policy around it; many 0%-MDM-ready app GPOs target decommissioned applications.
What to Exclude from Intune
Not everything in a GPO estate should be migrated. Attempting to migrate out-of-scope GPOs wastes effort and produces policies that will never work correctly in Intune.
Server GPOs
GPOs targeting server OUs remain in Group Policy. They are not in scope for Intune. For hybrid server management at scale, evaluate Azure Arc + Azure Policy as a separate initiative.
Drive Mapping GPOs
Drive mapping has zero MDM support. This is not a policy migration question — it is a file share modernization initiative (SharePoint Online, Azure Files, or OneDrive Known Folder Move). When the organization is ready, a single Intune Platform Script can replace dozens of drive mapping GPOs.
Software Deployment GPOs
GPOs that deploy MSI packages belong in Intune as Win32 app deployments, not configuration policies. This is a separate app packaging and deployment workstream.
Infrastructure and Network GPOs
Certificate deployment, Wi-Fi profiles, VPN configurations, and device enrollment bootstrapping GPOs have Intune equivalents but belong in dedicated workstreams: Certificate Connector, Wi-Fi profiles, VPN profiles, and enrollment restrictions. They should not be migrated as configuration policies.
Empty and Container GPOs
GPOs with no active settings (OU containers, link-only GPOs, printer-only GPOs) have nothing to migrate. Document them and clean them up in AD at the AD team's discretion.
Co-Management Workload Configuration
Organizations on co-management (Intune + Configuration Manager) must explicitly transfer workload authority to Intune for each policy area as migration completes. Until the workload is transferred, Configuration Manager (and therefore Group Policy applied by it) continues to win for that area.
Transfer workloads in Intune (Tenant administration > Connectors and tokens > Microsoft Endpoint Configuration Manager > Properties):
| Workload | Transfer When |
|---|---|
| Compliance policies | Phase 2 complete — compliance policies built and validated |
| Device configuration | Phase 3 complete — Tier 3 policies built and validated |
| Endpoint Protection | Phase 1 complete — Tier 1 security policies validated |
| Windows Update policies | Phase 4 (WUfB rings) validated |
Transfer one workload at a time. Monitor the Device Compliance and Configuration dashboard after each transfer to catch regressions before transferring the next workload.
Implementation Phases
Phase 1 — Security Foundation (Weeks 1–6)
- Export the full GPO estate using GPMC and upload to Group Policy Analytics
- Review the analytics output — identify high-readiness GPOs in security categories
- Import the OIB Tier 1 policies using the IntuneManagement tool
- Customize OIB defaults against the GPO settings export — carry forward any organization-specific exclusions, account names, and rule overrides
- Deploy to a pilot group (IT staff devices) for a minimum two-week validation window
- After validation, deploy broadly and disable superseded ad-hoc Intune policies
Phase 2 — Identity, Compliance, and Device Configuration (Weeks 6–12)
- Deploy WHfB and Cloud Kerberos Trust policies
- Build and deploy the compliance policy — coordinate with the CA team to ensure Conditional Access is ready to enforce compliance state
- Build Tier 3 device configuration policies from the GPO analytics settings export, organized by functional area
- Consolidate existing organically built Intune policies into the OIB-structured equivalents
- Deploy WUfB rings — transfer the Windows Update workload from Configuration Manager once rings are validated
Phase 3 — Specialized Environments (Weeks 12–20)
- Pilot mission-critical device policies with a small, representative device group
- Restructure kiosk policies under the OIB naming convention
- Deploy VDI optimization policies
- Build application-specific policies; for zero-MDM-readiness app settings, build Intune Remediations or Platform Scripts as needed
Phase 4 — Consolidation and Steady State (Weeks 20–26)
- Retire all superseded Intune policies — disable, then delete after a 30-day grace period
- Remove test, temporary, and ZZZ-prefixed deprecated policies
- Produce a policy registry — a living document mapping each Intune policy to its purpose, target group, version, and the GPO settings it replaced
- Establish a change management process: new policy requests follow the OIB naming convention and require documentation before deployment
CMMC Control Mapping
- GCC High (CMMC)
- Commercial
| NIST SP 800-171 Rev. 2 Control | How Structured Policy Buildout Satisfies It |
|---|---|
| CM.L2-3.4.1 — Establish and maintain baseline configurations and inventories of organizational systems | The OIB-structured Intune policy set is the documented, maintained baseline. The policy registry (Phase 4) provides the inventory artifact required by assessors. |
| CM.L2-3.4.2 — Establish and enforce security configuration settings for information technology products | Intune configuration policies enforce security settings on all managed endpoints with compliance state reporting. Group Policy enforcement is replaced with managed, auditable Intune enforcement. |
| CM.L2-3.4.6 — Employ the principle of least functionality | GPO-to-Intune migration is an opportunity to remove settings that enabled unnecessary features or services. Tier 1 ASR rules directly restrict execution of unneeded OS capabilities. |
| SI.L2-3.14.1 — Identify, report, and correct information system flaws in a timely manner | WUfB rings (Tier 4) establish structured, documented patch management with defined deferral periods and ring-based validation. |
A CMMC Level 2 assessor evaluating CM.L2-3.4.1 will typically request both the configuration evidence (Intune policy export) and a document showing what the policies contain and why. The policy registry produced in Phase 4 is the primary audit artifact for this control.
| NIST SP 800-171 Rev. 3 Control | How Structured Policy Buildout Satisfies It |
|---|---|
| 3.4.1 — Establish and maintain baseline configurations and inventories of organizational systems | Same as Rev. 2: the OIB-structured Intune policy set and policy registry are the baseline inventory artifacts. |
| 3.4.2 — Establish and enforce security configuration settings | Intune enforces configuration settings consistently across the device estate with auditable compliance reporting. |
| 3.4.6 — Employ the principle of least functionality | GPO migration is an explicit opportunity to remove legacy settings enabling obsolete or unnecessary features. |
| 3.14.1 — Identify, report, and correct system flaws in a timely manner | WUfB rings provide structured, risk-tiered patch deployment with defined deferral periods. |
📩 Don't Miss the Next Solution
Join the list to see the real-time solutions I'm delivering to my GCC High clients.