From 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.
DDM Check in errors after ios 27.0 update
Many of our BYOB users started applying 27.0 this morning (9/15/26) and I immediately started seeing Check In errors for any of the devices that did so in Intune. I have the standard DDM policy in place with Enforce Latest Software Update Version set to True, Delay in Days set to 3 and Install Time set to 23.59. All the users that update to 27.0 are showing as having errors on all those settings. I've had this policy in place since earlier this year (at least 7 months) and it's been through numerous updates prior to this without any issue. Anyone else seeing this?
Intune On-Demand Proactive Remediation API Reliability for Large-Scale Usage
Hi Team, We are testing the Intune On-Demand Proactive Remediation API: POST /deviceManagement/managedDevices/{managedDeviceId}/initiateOnDemandProactiveRemediation In our environment, the remediation package works correctly, and the API generally triggers the remediation as expected. However, during repeated testing, we noticed that a small percentage of requests do not seem to reach the endpoint. For example: 20 remediation requests sent 18-19 execute successfully 1-2 never trigger on the target device Devices are online and managed by Intune Added a 30-second delay between requests, but the behavior still occurs intermittently Before adopting this in production for a large client base, we'd like to understand: Has anyone observed similar behavior? Is this API reliable for triggering remediation across multiple devices in parallel? Are there any known limitations, queueing mechanisms, throttling considerations, or best practices? Is there a recommended way to verify that a remediation request was actually delivered to the device? Since this API is still in the beta/preview stage, is there any information on its roadmap or GA timeline? Note: For additional context, detailed test results, observations, and environment information, a PDF containing the complete analysis has been attached. Any guidance or real-world experience would be greatly appreciated. Thank you. https://learn-attachment.microsoft.com/api/attachments/1ad5bea4-9038-4b25-9a2a-a9e66a870f6a?platform=QnA https://learn.microsoft.com/en-us/graph/api/intune-devices-manageddevice-initiateondemandproactiveremediation?view=graph-rest-beta
enrolling in Intune MacBook Pro with an M5 Pro
Hi everyone We have tested the Wi-Fi and ethernet profile without success with Apple businesses manager. The Wi-Fi and the ethernet connection itself works, but the enrollment process into Intune does not complete successfully. At this stage, we cannot sign in, and neither the Wi-Fi nor the Ethernet connection appears to be working. The device is a 14-inch MacBook Pro with an M5 Pro chip, running macOS 26.5.1 the device connects to the server, the settings begin to apply, but the process suddenly stops, and we are then unable to log in. These are steps followed : Synchronize the device from Apple Business Manager to Intune. Assign the enrollment profile to the device. Perform a device wipe/reset. Start Automated Device Enrollment (ADE). Complete the device setup and user sign-in. The device successfully enrolls into Intune. Intune begins deploying configuration profiles, compliance policies, security policies, and applications. During the policy application process, Wi-Fi connectivity stops responding. The device loses network connectivity and cannot continue synchronizing policies. We are unable to sign in because the enrolment process has not been finalized. As a result, we have to wipe the Mac and start the process again each time. We have disabled some policies, but we are still experiencing the same issue. Have anyone experienced any issues like that ? Regards,How to Manually Sync the Compliance Policies
Hi All, We have come across an incident where we need to exclude a device from a device compliance policy after the device got non-compliant according as per the policy. We have exclude the specific user from the compliance policy to meet the requirement (we have assigned the policy to user groups). However, the issue is that the device not get back to the compliant state event after passed 4 days. I would appreciate if anyone could help me here to manually get the device into the compliant state. Please note that, when we go to specific device > device compliance policies, we are not able to see the compliance policy anymore and other applied policies in complaint state (refer image01). However, the device is still showing as non-compliant in devices in Intune (refer image 02). Last checking time is continuously updating as well. Further, We have tried below troubleshooting but there is no luck yet. We are not still take a remote session to the device yet as we have some challenges to get a remote session from the end user. Sync the device from Intune Portal. remotely login into the PowerShell of the device and run below command. Start-Process -FilePath "C:\Program Files (x86)\Microsoft Intune Management Extension\Microsoft.Management.Services.IntuneWindowsAgent.exe" -ArgumentList "intunemanagementextension://synccompliance" Image01 We are not able to see the excluded compliance policy under policy name anymore and the all the applied policies are in complaint state as below. Image02 Thanks in advance DilanIntune App inventory Graph
Hi All, I've enabled the configuration profile to receive app inventory data in Intune. In the GUI the data I can view the data just fine, but I would like to use Graph to automate this data and create custom reports. When I use the following https://graph.microsoft.com/beta/deviceManagement/managedDevices/[device-id]/deviceInventories('ApplicationProperties') I get an error: "Forbidden - 403 - 199 ms Either the signed-in user does not have sufficient privileges, or you need to consent to one of the permissions on the Modify permissions tab" even though the docs I can find about permissions are OK.
Intune Mobile Outlook Asking password again and again
we have some of the mobile users which is having issue with outlook signin . After enrollment of the device user is not able to sign in in the outlook it seems like it is stucked in the loop. however teams is working fine for these users. Also these device are successfully enrolled without any error,device is compliant and passed all the conditional access policies. can anyone help me out on this issue.
Microsoft Teams not working when Company Intune Portal is installed
Hello can someone help me why MS Teams force to closed the app when the company intune portal is installed. I need the company portal to sign in on teams because of policy in our company. But when I installed it crashed the MS team app Using android 13.
Android 12 Sign-In Issue with HP Corporate Accounts via Intune Company Portal
Since yesterday, HP employees using older mobile operating systems (Ex. Android 12) have been unable to access Microsoft Outlook and Microsoft Teams on their smart devices. When launching Outlook or Teams, users are prompted to install the Microsoft Intune Company Portal app for authentication and device compliance. However, the latest version of this app appears to require a newer operating system version and is not supported on older devices. As a result, users with devices running Android 12 or earlier cannot complete the authentication process and are unable to use Outlook or Teams. ■ Please provide additional details 1) The issue started yesterday and affects employees using older Android and iOS versions. 2) On iOS devices, users can typically resolve the issue by upgrading to a newer iOS version. 3) However, some Android devices cannot be upgraded further due to manufacturer limitations. 4) For example, Samsung Galaxy Note 10 officially supports Android 12 as its final OS version and cannot be upgraded to Android 13 or later. 5) Because of this limitation, affected Android users are unable to install or use the required Microsoft Intune Company Portal app, which prevents access to Microsoft Outlook and Microsoft Teams. 6) This issue may impact multiple HP employees who are using Android devices that do not support Android 13 or later. Example affected device: Samsung Galaxy Note 10 (Android 12) Affected applications: Microsoft Outlook, Microsoft Teams, and Microsoft Intune Company Portal Business impact: Users cannot access corporate email, messaging, and collaboration services from their mobile devices. I have already posted this issue on the Microsoft Feedback Portal: https://feedbackportal.microsoft.com/feedback/idea/7bba2697-a2a2-f111-85ce-7c1e529382f4 However, this issue cannot be reproduced when using a personal Microsoft account. It only occurs when using an HP corporate email account because HP requires the use of the Microsoft Intune Company Portal app for authentication and device compliance. Since the problem appears to be related to the Intune Company Portal rather than Outlook or Teams themselves, I would like to post this issue here and seek guidance on resolving the Intune Company Portal authentication and compatibility issue affecting Android 12 devices.
Blocking/Disabling SMS, RCS and iMessage services on a device
Hi all, I'm trying to gather more information on Intune capabilities around blocking or disabling various text messaging services on mobile devices. I have done some research and here are my current understandings: SMS Android: This can be disabled on Samsung Knox Only devices. Not 100% if this means devices that are enrolled via Samsung's Knox enrollment, but that's what it sounds like. iOS: Did not find any capabilities here. iMessage: Android: N/A iOS: This can be disabled on iOS ADE enrollment device, no other types of enrollment support this for iOS. RCS: Android: Need to utilize OEMConfig profiles, which means it's vendor specific. Don't have any details here so not sure which OEMs support this for Android. iOS: N/A Any further information on this would be very appreciated. Thanks, Durango2k13
