administrative templates (admx)
4 TopicsFrom GPO to Microsoft Intune: A practical guide to cloud-first policy management
By: Per Larsen - Senior Product Manager | Microsoft Intune For many organizations, Group Policy Objects (GPOs) remain an important part of Windows configuration. As device strategies expand to include cloud-native management, Microsoft Intune provides the policy platform for devices that are Microsoft Entra joined and managed from the cloud. The goal isn’t to force every organization through the same migration, it’s to choose the right management path for each device population and each setting. This guide explains three common paths: starting fresh for new cloud-native devices, selectively transitioning required settings to Intune, and coordinating GPO with Intune for hybrid Microsoft Entra joined or co-managed devices. Across all three paths, the recommended principle is the same: assess and rationalize existing policy before deciding what to retain, re-create, redesign, or retire. 1. Choose the right path for each device population GPO was designed primarily for domain-joined, on-premises devices. Intune, in contrast, is designed for cloud-based management of devices whether they are on or off prem. The right path will depend on the scenario in which the devices are joined and managed. Scenario 1: Start fresh for new cloud-native devices This is the recommended approach for new Microsoft Entra joined devices. Invest in the cloud-first configuration you need today rather than reproducing every historical GPO. Begin with mandatory security requirements, Microsoft-recommended security baselines, and essential settings for services such as OneDrive and Microsoft Edge. Add other settings only when there’s business, security, or operational requirement. Scenario 2: Selectively transition required settings Organizations that need to preserve specific behavior can assess and rationalize existing GPOs, then re-create only the settings that are supported and necessary in Intune. Treat this as a deliberate replatforming effort, not a one-to-one copy. Test each new profile with a pilot group before broad deployment. Scenario 3: Coordinate GPO and Intune for hybrid devices Hybrid Microsoft Entra joined devices may receive settings from both GPO and Intune, including common scenarios where Intune-managed workloads or Windows Autopatch are used for existing hybrid domain-joined devices. Use of both group policy and Intune policy enforcement can continue for an extended period, but you should plan carefully to avoid conflicting settings. Organizations can either leave existing GPOs in place until devices are rebuilt as cloud-native, or actively shift selected policy areas to Intune while the devices remain hybrid joined. Figure 1. A cloud-first policy workflow begins with assessment and rationalization, then applies the appropriate path for each device population. 2. Assess and rationalize before you transition Before changing policy source, understand what’s actually in use. Many environments contain GPOs that are old, undocumented, duplicated, or applied more broadly than intended. A direct lift-and-shift carries that technical debt into Intune. Key assessment actions Export all GPOs from Group Policy Management Console (GPMC). Use Gpresult and operational knowledge to identify which GPOs are still applied and functional. Remove or archive unused, legacy, or duplicated policies instead of transitioning them. Categorize required settings by security, update management, device restrictions, application control, and legacy or unsupported scenarios. Record the device populations and business requirements associated with each policy. 3. Use Group Policy Analytics as an assessment input Microsoft Intune includes Group Policy Analytics, a built-in tool that imports on-premises GPOs and reports their mapped support in mobile device management. It can help identify settings with Intune equivalents, deprecated settings, and configurations that may require another implementation approach. Use the report as one source of evidence rather than as a complete transition engine. Its mappings may not reflect every setting currently available in the Settings Catalog, especially settings added after the analytics mapping was last updated. Validate important settings directly in Intune and against current Microsoft documentation. Useful outcomes Highlights settings with documented Intune mappings. Surfaces GPO settings that no longer make sense for cloud-native devices. Helps identify GPOs that should be retired rather than re-created. Supports, but does not replace, business validation and pilot testing. 4. Don't lift and shift: Re-design for cloud-first management A direct copy of GPOs into Intune can reproduce policy sprawl and create new conflicts. Instead, use the assessment to determine the intended outcome of each setting. Some settings will be unnecessary, some will have a direct Intune settings catalog equivalent, and others will need a cloud-appropriate redesign. Retire settings that are no longer required. Re-create settings that are supported and necessary. Rethink and redesign legacy dependencies such as drive mappings, printers, or vendor-specific prioritizing or considering cloud-first solutions and configurations. Document the owner, target population, and validation method for each resulting Intune profile. Figure 2. Decide whether to retain, re-create, redesign, or retire each GPO based on device type and current business need. 5. Start with security baselines Security baselines in Intune are curated collections of Microsoft-recommended settings for Windows, Microsoft Edge, and Microsoft Defender. They provide a controlled foundation that can reduce policy sprawl and align devices with current security guidance. Review baseline settings with security stakeholders rather than applying them without evaluation. Identify overlaps with existing policies before deployment. Pilot the baseline with representative devices and users. Layer additional configuration policies only for documented requirements. 6. Create equivalent Intune configuration profiles where needed After assessment and baseline planning: Configure supported and necessary settings in the settings catalog. Use Administrative Templates or imported ADMX policies for applicable settings. Use custom configuration, scripts, or remediations only when a built-in option doesn’t meet the requirement. Use standard or organizational safe rollout practices to assign policies before broad rollout, and monitor deployment and conflict reports. 7. Coordinate GPO and Intune during a hybrid period Customers often expect GPOWinsOverMDM to act as a universal precedence switch: whenever Group Policy and Intune configure the same setting, GPO should win. In reality, conflict control applies only to the subset of settings exposed through the Windows Policy CSP with corresponding Group Policy mappings. Additionally, it doesn’t govern settings delivered through other CSPs, such as Defender or Windows Update. Those policy areas can have different precedence, merging, or conflict behavior. Consequently, using GPOWinsOverMDM as a coexistence strategy can produce inconsistent and difficult-to-predict results. The safer approach is to avoid configuring the same setting through both management planes. Use targeted groups, assignment filters, GPO security filtering, and Organizational Units (OU) scoping to establish one authoritative source for each setting and device population. Use selective targeting to move policy areas in controlled stages: In Group Policy, use appropriate OU link placement, security group filtering, and carefully validated Windows Management Instrumentation (WMI) filters to stop selected GPOs from applying to devices that will receive the Intune equivalent. In Intune, use Microsoft Entra groups, dynamic membership rules, assignment filters, and exclusions to target the intended device population. For each policy area, document the authoritative management plane and the date or condition for changing ownership. Validate effective configuration with Gpresult, Intune reports, Event Viewer, and representative pilot devices. For example, an organization might leave most existing GPOs in place for hybrid joined devices while excluding a pilot group from the Windows Update GPO. The same group can then receive the corresponding Intune update policy. After validation, you can expand the targeting changes in stages in alignment with your organizational safe-rollout standards. 8. Common Pitfalls Enforcing GPO and Intune side by side without coordinated targeting Uncoordinated configuration can create conflicts, inconsistent results, and difficult troubleshooting. Define an authoritative management plane for each setting and device population. Transitioning everything as is You should rationalize old, unused, or duplicated settings rather than reproducing or recreating them in Intune. Supporting legacy or non-cloud-first settings. Some requirements don’t have a direct built-in Intune equivalent. Evaluate whether the requirement is still necessary, then use a supported alternative, redesign the process, or retain the setting in GPO for the applicable hybrid devices. Skipping the pilot phase Pilot groups reveal assignment, compatibility, and user-impact issues before a broad deployment. 10. Retire old GPOs gradually Retire a GPO only after its replacement or removal has been validated for the affected device population. Exclude a pilot population from the original GPO and assign the intended Intune configuration. Validate effective settings, Intune deployment status, device events, and user impact. Expand the targeting change in controlled stages. Disable and archive the GPO after dependencies are removed and rollback is no longer required. Keep GPOs that remain necessary for hybrid joined devices, with clear ownership and targeting. Conclusion Moving to Intune policy management isn’t a one-size-fits-all migration or a copy-and-paste exercise. For new cloud-native devices, start with a clean, cloud-first configuration. When existing behavior must be preserved, assess and rationalize the requirement before re-creating it in Intune. During a period of parallel Group Policy and Intune management, coordinate targeting so GPO and Intune do not compete for the same settings. The key principles are: Choose the management path by device population. Assess and rationalize before making changes. Start with security requirements and validated baselines. Use Group Policy Analytics as an input, not as the sole source of truth. Transition only supported and necessary settings. Coordinate GPO and Intune targeting throughout any transition period.1.3KViews0likes0CommentsUpdates to Beta APIs for Windows Endpoint security and Administrative templates
By: Julia Idaewor – Product Manager II | Microsoft Intune In 2023, when we began the migration for older Endpoint security policies, we recommended customers to take action to update their automation and scripts for Endpoint security policy creation. You can learn more about the migration in the blog: Endpoint security policies migrating to the unified settings platform in Microsoft Intune. Starting late March 2025, the Microsoft Graph Beta APIs deviceManagement/templates and deviceManagement/intents will no longer support the creation and management of Endpoint security policies for Windows devices. Additionally, the following Beta APIs will no longer work for managing Administrative templates: deviceManagement/groupPolicyCategories deviceManagement/groupPolicyConfigurations deviceManagement/groupPolicyDefinitions The old APIs used in the following policies will be replaced with the newer API deviceManagement/configurationPolicies. The new APIs leverage the newer policy infrastructure to improve accuracy and consistency. See a list of affected policies below: Antivirus Identity Protection Disk Encryption AV Exclusions Application Control Web Protection Endpoint Detection and Response Attack Surface Reduction Device Control Exploit Protection Firewall Rules Firewall Windows Security App Browser Administrative templates Note: Security baselines will not be affected by this API change as they can still be created using the deviceManagement/intents endpoint. If you're impacted by this change, look for MC955748 in the Message Center. If you’re interacting with Endpoint security policies or Administrative templates via the APIs listed above or, using automation or scripts to create and retrieve policies from these APIs, switch to the new graph endpoint: 'deviceManagement/configurationPolicies' API for policy creation by making POST requests to the corresponding endpoint for each policy. Examples Create Policy: Request Method: POST Request URL: https://graph.microsoft.com/beta/deviceManagement/configurationPolicies { "name": "ASR Rules", "description": "", "settings": [ { "@odata.type": "#microsoft.graph.deviceManagementConfigurationSetting", "settingInstance": { "@odata.type": "#microsoft.graph.deviceManagementConfigurationGroupSettingCollectionInstance", "groupSettingCollectionValue": [ { "children": [ { "@odata.type": "#microsoft.graph.deviceManagementConfigurationChoiceSettingInstance", "choiceSettingValue": { "@odata.type": "#microsoft.graph.deviceManagementConfigurationChoiceSettingValue", "children": [], "settingValueTemplateReference": { "settingValueTemplateId": "8b17ebce-496f-4b58-9d89-dd1c3861de39" }, "value": "device_vendor_msft_policy_config_defender_attacksurfacereductionrules_blockexecutionofpotentiallyobfuscatedscripts_block" }, "settingDefinitionId": "device_vendor_msft_policy_config_defender_attacksurfacereductionrules_blockexecutionofpotentiallyobfuscatedscripts", "settingInstanceTemplateReference": { "settingInstanceTemplateId": "e416083e-05e3-4237-b8ec-a6ad49c4571e" } } ] } ], "settingInstanceTemplateReference": { "settingInstanceTemplateId": "19600663-e264-4c02-8f55-f2983216d6d7" }, "settingDefinitionId": "device_vendor_msft_policy_config_defender_attacksurfacereductionrules" } } ], "roleScopeTagIds": [ "0" ], "platforms": "windows10", "technologies": "mdm,microsoftSense", "templateReference": { "templateId": "e8c053d6-9f95-42b1-a7f1-ebfd71c67a4b_1" } } Get Policy: Request Method: GET Request URL: https://graph.microsoft.com/beta/deviceManagement/configurationPolicies('ec100030-eee3-4d13-9073-019affc599eb') Update Policy: Request Method: PUT Request URL: https://graph.microsoft.com/beta/deviceManagement/configurationPolicies('ec100030-eee3-4d13-9073-019affc599eb') Body: { "name": "ASR Rules", "description": "", "creationSource": null, "settings": [ { "@odata.type": "#microsoft.graph.deviceManagementConfigurationSetting", "settingInstance": { "@odata.type": "#microsoft.graph.deviceManagementConfigurationGroupSettingCollectionInstance", "settingDefinitionId": "device_vendor_msft_policy_config_defender_attacksurfacereductionrules", "settingInstanceTemplateReference": { "settingInstanceTemplateId": "19600663-e264-4c02-8f55-f2983216d6d7" }, "groupSettingCollectionValue": [ { "settingValueTemplateReference": null, "children": [ { "@odata.type": "#microsoft.graph.deviceManagementConfigurationChoiceSettingInstance", "settingDefinitionId": "device_vendor_msft_policy_config_defender_attacksurfacereductionrules_blockexecutionofpotentiallyobfuscatedscripts", "settingInstanceTemplateReference": { "settingInstanceTemplateId": "e416083e-05e3-4237-b8ec-a6ad49c4571e" }, "choiceSettingValue": { "value": "device_vendor_msft_policy_config_defender_attacksurfacereductionrules_blockexecutionofpotentiallyobfuscatedscripts_warn", "settingValueTemplateReference": { "settingValueTemplateId": "8b17ebce-496f-4b58-9d89-dd1c3861de39", "useTemplateDefault": false }, "children": [] } } ] } ] } } ], "roleScopeTagIds": [ "0" ], "platforms": "windows10", "technologies": "mdm,microsoftSense", "templateReference": { "templateId": "e8c053d6-9f95-42b1-a7f1-ebfd71c67a4b_1" } } If you have any questions, leave a comment below or reach out on X @IntuneSuppTeam.3KViews1like0Comments