Skip to main content

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 takes a top-down, Intune-first approach: the GPO estate is a source of requirements, not a migration target. The target state already exists: the Open Intune Baseline Layer 1 core (21 policies plus App Control). The work here is validating that baseline against what Group Policy was actually enforcing, then building the small set of organization-specific supplements the estate genuinely requires.

The Top-Down Approach​

The one-to-one migration instinct is understandable but wrong: each migrated GPO carries forward naming and scope that were never designed for Intune, reproducing the same organic mess in a different tool. Offered the choice, clients consistently pick top-down, because their estates have grown into settings whose provenance nobody, including them, can explain.

The alternative:

  1. Assess the estate. One read-only script exports every GPO for analysis and maps where each is assigned and to whom it applies.
  2. Analyze coverage against Layer 1. Import the exports into Group Policy analytics and diff the settings that were genuinely applying against the baseline.
  3. Disposition every setting. Four buckets: covered by Layer 1, genuine organization-specific requirement, obsolete, or out of Intune's scope.
  4. Build only the supplements. ORG-prefixed policies for the genuine requirements. Fewer policies with clear names and documented purpose are easier to audit, troubleshoot, and hand off.

Estate Assessment​

The assessment is one read-only PowerShell script that produces three artifacts:

ArtifactContentsFeeds
XML\*.xmlOne Group Policy report per GPOThe Group Policy analytics import
gpo-links.csvEvery link across the domain root and every OU, with link order, enabled and enforced flags, and inheritance blockingScope weighting and assignment translation
gpo-inventory.csvPer-GPO status, timestamps, WMI filter, security filtering, and a linked-anywhere flagThe discard pile and the estate statistics
Group Policy analytics discards assignment

The per-GPO XML report contains links, security filtering, WMI filtering, and delegation (documented report content), but Group Policy analytics reads none of it: the readiness analysis is settings-only. Where a GPO applies, which decides whether its settings matter at all and which Entra group inherits its scope, must come from the AD side. That is what the link map and inventory are for.

Download: export-gpo-estate.ps1

The assessment script is online rather than printed. PowerShell is meant to be downloaded and run, not retyped from a page. The script, with the comment header documenting its artifacts, prerequisites, and known edges, is at:

docs.mindline.com/docs/devices/device-operations/gpo-to-intune-migration

# GPO Estate Assessment - export, link map, and inventory
#
# Produces the three artifacts the GPO-to-Intune disposition analysis consumes
# (chapter 12.10, GPO-to-Intune Migration):
#
#   XML\<GPO name>.xml  - one Group Policy report per GPO, the import format
#                         for Intune's Group Policy analytics (4 MB per-file cap)
#   gpo-links.csv       - where every GPO is linked: domain root plus every OU,
#                         with link order, enabled and enforced flags, and
#                         whether the container blocks inheritance
#   gpo-inventory.csv   - per-GPO status, created/modified timestamps, WMI
#                         filter, security filtering, and whether the GPO is
#                         linked anywhere at all
#
# Where to run: a domain controller or management workstation with the RSAT
# GroupPolicy and ActiveDirectory modules installed, as a user with read
# access to Group Policy. The script is read-only: it changes nothing in AD.
#
# Known edges:
#   - Site-linked GPOs are not enumerated (Get-GPInheritance targets domains
#     and OUs only). Site links are rare; check GPMC by hand.
#   - Duplicate GPO display names collide on the sanitized file name. Append
#     -$($g.Id) to $file if the estate has any.

$out = "C:\GPOAssessment"
New-Item -ItemType Directory -Force -Path $out, "$out\XML" | Out-Null

# 1. Per-GPO XML reports: the exact format Group Policy analytics imports.
$gpos = Get-GPO -All
foreach ($g in $gpos) {
    $file = ($g.DisplayName -replace '[\\/:*?"<>|]', '_') + ".xml"
    Get-GPOReport -Guid $g.Id -ReportType Xml -Path (Join-Path "$out\XML" $file)
}

# 2. Link map: where every GPO is actually assigned (domain root + every OU).
$targets = @((Get-ADDomain).DistinguishedName) + (Get-ADOrganizationalUnit -Filter *).DistinguishedName
$links = foreach ($t in $targets) {
    $som = Get-GPInheritance -Target $t
    foreach ($l in $som.GpoLinks) {
        [pscustomobject]@{
            Target             = $t
            Gpo                = $l.DisplayName
            LinkOrder          = $l.Order
            LinkEnabled        = $l.Enabled
            Enforced           = $l.Enforced
            InheritanceBlocked = $som.GpoInheritanceBlocked
        }
    }
}
$links | Export-Csv "$out\gpo-links.csv" -NoTypeInformation

# 3. Estate inventory: status, staleness, filters, and whether the GPO is linked anywhere.
$linkedGpos = $links.Gpo | Sort-Object -Unique
$gpos | ForEach-Object {
    [pscustomobject]@{
        Name              = $_.DisplayName
        Status            = $_.GpoStatus
        Created           = $_.CreationTime
        Modified          = $_.ModificationTime
        WmiFilter         = $_.WmiFilter.Name
        LinkedAnywhere    = $linkedGpos -contains $_.DisplayName
        SecurityFiltering = (Get-GPPermission -Guid $_.Id -All |
            Where-Object Permission -eq 'GpoApply').Trustee.Name -join '; '
    }
} | Export-Csv "$out\gpo-inventory.csv" -NoTypeInformation

The script requires the RSAT GroupPolicy and ActiveDirectory modules and read access to Group Policy; it changes nothing in AD. Its header documents two edges: site-linked GPOs are not enumerated (Get-GPInheritance targets domains and OUs only), and duplicate display names collide on the file name. The per-GPO loop is deliberate: Get-GPOReport -All writes one combined file, which Group Policy analytics cannot consume.

The first conversation​

Before anyone reads a single setting, the inventory quantifies the estate for the client conversation:

  • Linked nowhere (LinkedAnywhere = False): dead weight that goes straight to the discard pile. A third or more of a mature estate is common.
  • Stale: Modified five or more years ago. Provenance is almost certainly lost.
  • Disabled halves: GpoStatus showing user or computer settings disabled, which halves the settings actually in force.
  • Where enforcement actually lives: the link map shows which OUs carry the real policy load.

These numbers are usually the moment the client concedes the provenance point themselves, and they shrink the coverage-analysis workload before it begins: only settings that were actually reaching in-scope devices earn analysis.

Group Policy Analytics​

Group Policy analytics ingests the per-GPO XML exports and classifies each setting against the current CSP surface. Import at Devices > Manage devices > Group Policy analytics; the readiness report lives at Reports > Device management > Group policy analytics (import and analyze GPOs).

ClassificationMeaning
Ready for migrationThe setting has a matching setting in Intune
Not supportedNo MDM equivalent is exposed; requires a custom profile, Platform Script, Remediation, or no action
DeprecatedTargets obsolete Windows or Edge versions; do not carry forward

Constraints that matter in practice:

  • Each XML file must be under 4 MB with proper Unicode encoding; a monster GPO over the cap must be split by reducing its settings.
  • The tool supports non-ADMX settings in English only: the MDM support percentage is inaccurate for GPOs with settings in other languages (documented known issue).
  • Readiness data refreshes about 20 minutes after imports change.
  • Microsoft updates the CSP mapping logic server-side, and imported GPOs re-score automatically; there is no need to reimport as the catalog grows.

The MDM support percentage per GPO is not a migration queue. A high percentage means the coverage diff will be quick: the settings map cleanly to CSPs and mostly land in the covered-by-Layer-1 bucket. Zero percent means the GPO is not a policy problem at all, usually drive maps, software installs, or preferences that belong to the excluded workstreams below.

Export the settings-level detail. The drill-down shows per-setting CSP mappings; export it to CSV. This is the primary working artifact for the disposition analysis: one row per setting, with its CSP path, MDM support state, and source GPO.

Prioritize by function, not by GPO

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.

Disposition Analysis​

This is the core of the migration: every surviving setting gets one of four dispositions, recorded in the policy registry as it goes.

Weight by scope first. A setting earns analysis only if its GPO was enabled, linked to a container holding in-scope devices, and its security filtering actually reached them. Everything else is documented and dropped without a coverage diff; the link map and inventory make this a sort, not an investigation.

BucketWhat it meansAction
1. Covered by Layer 1The most common outcome for security settingsNothing to build. Record the GPO-to-policy mapping in the policy registry
2. Genuine ORG requirementDeliberate, still needed, absent from Layer 1Build or extend an ORG-prefixed policy, or apply one of the OIB chapter's sanctioned customizations (AV and ASR exclusions, banner text, LAPS account names)
3. ObsoleteNobody can explain it, it targets retired systems, or it was scope-weighted outDocument and drop
4. Out of Intune's scopeDrive maps, server GPOs, software deployment, infrastructureRoute to the dedicated workstream (see What to Exclude)

Translating assignment​

GPO scoping has four dimensions, and each has an Intune counterpart. The link map and the security-filtering column of the inventory are the raw material for this design:

Group Policy scopingIntune counterpart
OU linkEntra security group assignment; for hybrid-joined fleets, dynamic device groups replace the OU tree
Security filteringAssignment include/exclude groups
WMI filterIntune assignment filter
Loopback processingThe device-scope (D) versus user-scope (U) decision in the naming convention: loopback GPOs almost always become D-scope policies

Where the Migrate button fits​

Group Policy analytics can generate a Settings Catalog profile directly from imported GPOs (select the Migrate checkbox), with built-in cross-GPO conflict detection that forces a single value when two GPOs disagree (create a Settings Catalog policy from imported GPOs). Under the top-down model its use is narrow: assembling a bucket-2 ORG supplement from residual settings, where it saves the transcription. It is never a bulk converter; pointing it at the whole estate reproduces the sprawl this chapter exists to prevent.

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]
TokenValuesMeaning
WinWin, iOS, macOS, AndroidPlatform
OIB or ORGOIB = Open Intune Baseline standard; org prefix for org-specific policiesPolicy source/ownership
ES / SC / UES = Endpoint Security; SC = Security Compliance / Configuration; U = User-levelPolicy category
FunctionAttack Surface Reduction, Browser, Firewall, etc.Functional area
D / UD = Device scope; U = User scopeAssignment scope
DescriptionShort descriptorDistinguishes policies in the same function
Versionv1.0, v1.1Change tracking

Example: Win - OIB - ES - Attack Surface Reduction - D - ASR Rules (L2) - v3.7

Organization-specific policies that extend or deviate from OIB defaults use the org prefix instead of OIB:

Example: Win - ACME - SC - Browser - D - Microsoft Edge - v1.0 (organization-specific Edge configuration, where ACME is replaced with your own 2–4 letter org prefix)

The ORG Buildout Beyond Layer 1​

The security baseline is not built here: deploy the Layer 1 core per the OIB chapter, which owns the policy tables, the GCC High modifications, and the control mappings. Reproducing those tables in this chapter would only create a copy that drifts.

Validate against existing Intune policies before deploying Layer 1

Most environments with a GPO estate also have organically built Intune policies covering some of the same areas. Diff the existing Intune policy settings against the Layer 1 equivalents before enabling them. Specific settings (ASR rule exclusions, AV exclusions, LAPS account names) are often customized in the existing policies and must be carried forward.

What remains for this chapter is the ORG buildout: the bucket-2 supplements the disposition analysis surfaces, organized into three groups.

Device Configuration Supplements​

Policy AreaCoverage
Login and lock screenScreen timeout, lock behavior, inactivity policy
Windows Update for BusinessDiagnostic data, update compliance reporting (separate from Update Rings, below)
Browser configurationHomepage, security zones, enterprise site lists, cache settings
OneDrive KFMKnown Folder Move silent configuration, sync settings
Productivity appsOffice licensing, modern auth, PST disable
Remote accessRemote Desktop, Remote Assistance settings
Time synchronizationNTP configuration: often 5-10 GPOs consolidated into one Intune policy
Network and proxyProxy settings per environment or department group

Windows Update Rings​

Replace all Windows Update GPOs with a structured Windows Update for Business (WUfB) deployment. The standard ring structure:

RingTypical TargetQuality DeferralFeature Deferral
IT / DevIT staff, administrators0 days0 days
PilotEarly adopters3 days0 days
GeneralStandard workforce7–10 days0 days
Critical OpsMission-critical devices (dispatch, emergency services, production control)14 daysUse 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.

Retire update-blocking GPOs immediately

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.

Specialized Environments​

These are higher-risk migrations requiring extended piloting. Before building any specialized-environment 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 zero-percent-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.

Workloads are switched in the Configuration Manager console, not the Intune admin center: Administration > Cloud Services > Cloud Attach, select the co-management object, then Properties > Workloads. Each slider moves from Configuration Manager to Pilot Intune (pilot collection only) to Intune (how to switch workloads). Two documented behaviors to plan around: the Device configuration slider moves Endpoint Protection and Resource Access with it, and Pilot Intune deploys policies but does not remove them on unassignment.

WorkloadTransfer When
Compliance policiesPhase 2 complete: compliance policies built and validated
Device configurationPhase 3 complete: device configuration supplements built and validated
Endpoint ProtectionPhase 1 complete: Layer 1 security policies validated
Windows Update policiesPhase 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)​

  1. Run the estate assessment script; import the per-GPO XML exports into Group Policy analytics
  2. Scope-weight the estate: discard unlinked, disabled, and nowhere-applying GPOs, and record the discard list in the policy registry
  3. Deploy the Layer 1 baseline per the OIB deployment chapter (import, environment modifications, pilot)
  4. Diff the surviving security settings against Layer 1; carry forward the sanctioned customizations (exclusions, account names, banner text)
  5. Deploy to a pilot group (IT staff devices) for a minimum two-week validation window
  6. After validation, deploy broadly and disable superseded ad-hoc Intune policies

Phase 2: Identity, Compliance, and Device Configuration (Weeks 6–12)​

  1. Deploy WHfB and Cloud Kerberos Trust policies
  2. Build and deploy the compliance policies: coordinate with the CA team to ensure Conditional Access is ready to enforce compliance state
  3. Build the bucket-2 device configuration supplements from the settings-level export, organized by functional area
  4. Consolidate existing organically built Intune policies into the OIB-structured equivalents
  5. Deploy WUfB rings: transfer the Windows Update workload from Configuration Manager once rings are validated

Phase 3: Specialized Environments (Weeks 12–20)​

  1. Pilot mission-critical device policies with a small, representative device group
  2. Restructure kiosk policies under the OIB naming convention
  3. Deploy VDI optimization policies
  4. 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)​

  1. Retire all superseded Intune policies: disable, then delete after a 30-day grace period
  2. Remove test, temporary, and ZZZ-prefixed deprecated policies
  3. Produce a policy registry: a living document mapping each Intune policy to its purpose, target group, version, and the GPO settings it replaced, and recording the disposition of every discarded GPO
  4. Establish a change management process: new policy requests follow the OIB naming convention and require documentation before deployment

CMMC Control Mapping​

NIST SP 800-171 Rev. 2 ControlHow Structured Policy Buildout Satisfies It
CM.L2-3.4.1: Establish and maintain baseline configurations and inventories of organizational systemsThe 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 productsIntune 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 functionalityThe disposition analysis is an explicit opportunity to drop settings that enabled unnecessary features or services rather than carry them forward. Layer 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 mannerWUfB rings 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.

📩 Don't Miss the Next Solution

Join the list to see the real-time solutions I'm delivering to my GCC High clients.