Preparing for end of support for CNAME auto-discovery in Windows MDM-only enrollment
Today, some organizations use an EnterpriseEnrollment DNS CNAME record to automatically direct devices to the Microsoft enrollment service during Windows MDM-only enrollment. Starting January 15, 2027, as part of our ongoing efforts to simplify and modernize enrollment experiences, Microsoft Intune will end support for CNAME-based auto-discovery in Windows MDM-only enrollment scenarios. This change reduces dependency on DNS-based discovery while providing a more consistent enrollment experience moving forward. After this change, users may need to enter the Microsoft enrollment server URL if it’s not already provided by the enrollment experience: https://enrollment.manage.microsoft.com/enrollmentserver/discovery.svc Who this change affects Your organization may be affected if: You use Windows MDM-only enrollment. You have configured an EnterpriseEnrollment DNS CNAME record. Your enrollment process depends on DNS record to automatically discover the enrollment service. You likely aren't affected if you exclusively use: Microsoft Entra join enrollment Microsoft Entra hybrid join enrollment Other enrollment methods that don't rely on EnterpriseEnrollment CNAME discovery How the user experience will change Today, in affected environments, a user can begin Windows MDM-only enrollment, and the enrollment service is automatically discovered using the organization’s EnterpriseEnrollment DNS CNAME record. The user doesn’t need to provide the enrollment server information. After this change, CNAME-based auto-discovery will no longer be used for these Windows MDM-only enrollment scenarios. If the enrollment service URL isn't already provided by the enrollment experience, the user will need to enter it when prompted. Enrollment can then continue using the Microsoft enrollment service URL. For example: Identifying affected environments Review your organization's DNS configuration and Windows MDM-only enrollment documentation.In particular, look for an EnterpriseEnrollment DNS record similar to: EnterpriseEnrollment.contoso.com If your organization configured the EnterpriseEnrollment record to support Windows MDM-only enrollment discovery, you should prepare for this change. You should also review and update documentation that assumes enrollment service discovery happens automatically through DNS, including: Internal enrollment guides Help desk procedures Device deployment instructions Provisioning documentation User onboarding materials Actions to take if you’re affected To prepare for this change we recommend the following actions: 1. Identify impacted enrollment workflows Review all Windows MDM-only enrollment scenarios used within your organization and determine whether they depend on EnterpriseEnrollment DNS discovery. 2. Update enrollment documentation Update user guides, knowledge base articles, onboarding materials, and other instructions to reflect the new enrollment process. 3. Prepare support teams Ensure help desk and deployment teams understand the change and know when the enrollment service URL may need to be provided. 4. Test enrollment scenarios Validate affected enrollment workflows before the change takes effect. Identify any required updates and determine where users may be prompted to enter the enrollment service URL. 5. Communicate with impacted users If users will need to enter the enrollment service URL, provide updated instructions before the change takes effect. Frequently asked questions Does this affect existing enrolled devices? No. Existing enrolled devices remain enrolled and aren’t affected by this change. Is Windows MDM-only enrollment being retired? No. Windows MDM-only enrollment remains supported. Only CNAME-based auto-discovery will become unsupported. Do I need to remove my EnterpriseEnrollment DNS record? Review your environment and DNS configuration requirements. This change only affects use of the record for Windows MDM-only enrollment auto-discovery. Will every user need to enter the enrollment service URL? Not necessarily. Some enrollment experiences may already provide enrollment server information. Manual entry is only required when the enrollment experience doesn’t provide it automatically. Should we begin testing now? Yes. We strongly recommend validating enrollment scenarios as early as possible and updating relevant documentation before this change takes effect. Next steps Review your Windows MDM-only enrollment processes and identify any dependencies on EnterpriseEnrollment DNS CNAME records. Update enrollment guidance, deployment instructions, onboarding materials, and help desk procedures that assume the enrollment service will be discovered automatically through DNS. Stay tuned to this blog for updates. If you have any questions, leave a comment below.
Managed Google Play apps not syncing completely to Intune
Nimm diesen Text für den Beitrag: Hi, we are using Microsoft Intune with Android Enterprise Fully Managed devices and Managed Google Play. The Managed Google Play connection itself is working. Apps can be approved successfully and are visible in our Managed Google Play enterprise store. The problem is the synchronization from Managed Google Play to Intune. Several apps were approved and saved, for example: Adobe Acrobat Reader Microsoft OneNote ScanSnap Home Brother Mobile Connect HP Canon PRINT Canon PRINT Business A manual Managed Google Play sync in Intune completes, but the apps are not imported reliably into the Intune Android app list. We have had this issue repeatedly for several days. Sometimes only one app appears after synchronization while the other approved apps remain missing. Example from today: All seven apps are visible and approved in Managed Google Play, but after synchronization only Brother Mobile Connect appeared in Intune. We also tried removing the affected apps from Managed Google Play and approving them again individually. After each approval we saved the app, started another synchronization and refreshed the Intune Admin Center. The result was still incomplete. The Android Enterprise connection is otherwise working and existing apps are already managed successfully. Has anyone seen the same behavior? Is there currently a known synchronization issue between Managed Google Play and Microsoft Intune, or is there another way to force a complete re-import of the approved apps? Thanks.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[New Blog Post] Selective Wipe Corporate Data on unmanagmed devices (iOS/iPadOS and Android)
1. Introduction This blog aims to detail the Mobile Application Management for un-managed iOS/iPadOS devices and un-managed Android devices. This blog is intended to demonstrate how to utilize selective wipe corporate data. When a device is stolen, or lost or an employee leaves the company, you want to be sure there is no corporate data left on the device. This can be achieved by performing a selective wipe. After the selective wipe is requested, the corporate data will be removed from the app. This will be performed the next time the app is started. This guide will touch on three aspects as follow: Conditional Launch Device based wipe request (Stolen/Lost device) User based wipe request (Employee leave the company) How to initiate a wipe There are two ways to initiate a selective wipe. The selective wipe can be performed as part of the Conditional Launch in the App protection policy or by manually initiating a wipe request (Device based wipe and User base wipe). 2.1. Conditional launch When you configure an app protection policy a selective wipe will be configured. This is part of the https://docs.microsoft.com/en-us/mem/intune/apps/app-protection-policy-settings-android#conditional-launch. One of the default settings is “Offline grace period -> 180 days”. After 180 days offline you need to reconnect to the network and successfully authenticate. If the user successfully authenticates nothing will happen, but if the user fails, a selective wipe will be performed. 2.2. Manually initiate a wipe request Here are two ways to manually initiate a wipe request. There is a device based wipe request and a user based wipe request. To initiate a wipe select in the MEM admin center “Apps” -> “App selective wipe” or press https://endpoint.microsoft.com/#blade/Microsoft_Intune_DeviceSettings/AppsMenu/appSelectiveWipe. In the top of the app selective wipe blade, you can select “Wipe request” (device based wipe) or “User-Level Wipe” (user based wipe). 2.2.1. Device based wipe request With a device based wipe request a wipe can be initiated for each user device registered with an app protection policy. If a user has lost the device and a new device is in use. Then a device based wipe can be used to only wipe the previous device. Press the button “Create wipe request” in top of the page. 2. Press “Select user” to select the user of which you want to wipe a device. After the user has been selected the devices belonging to the user will be displayed. Select the device you want to wipe and press “Create”. 3. The wipe request will be sent to the device to remove corporate data from applications protected with an app protection policy. You will return to the app selective wipe blade where you can monitor the removal process of the user. Pending requests can be deleted by right-clicking the request and selecting “Delete wipe request”. 4. After successfully performing a wipe, the device will be removed from the device overview that was display on step 2. Important: The user must open the app for the wipe to occur, and the wipe may take up to 30 minutes after the request has been made. 2.2.2. User based wipe request When performing a user-based wipe request a wipe request will be sent to all apps on all the devices. This wipe you may want to perform when a user leaves the company and you want to be sure that all data is removed from all devices associated with the user. In the app selective wipe page select “User-level wipe” and press “add” to select the user for which you want to perform a user-level wipe. 2. Now the user has been selected wipe requests will be sent to all the devices of the user. As long as the user is on the list. The user will continue to get wipe commands at every check-in from all devices. To allow sign-in on a device you first need to remove the user from the list. 1. The wipe action can be monitored using the https://endpoint.microsoft.com/#blade/Microsoft_Intune/ReportingMenuBlade/userReportSettingKey (“Apps” -> “Monitor” -> “Reports”) or click https://endpoint.microsoft.com/#blade/Microsoft_Intune/ReportingMenuBlade/userReportSettingKey. Important: The user must open the app for the wipe to occur, and the wipe may take up to 30 minutes after the request was made. Author https://www.linkedin.com/in/shady-khorshed-19277723/ is a Microsoft enthusiast. He loves writing on iOS/Android, Windows 11, Windows 365 and related Microsoft Intune. He is here to share quick tips and tricks for all young professionals.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.
Multi-App Kiosk not applying on Samsung A55 (Android 16)
Hello everyone, I’m facing a critical issue with Android Enterprise Multi-App Kiosk mode on a Samsung Galaxy A55 (SM-A556B). The problem started suddenly last week without any configuration changes, and now no Android Enterprise configuration profiles apply anymore. What happened originally The device was running Android 15, and it had been working fine for months in Managed Home Screen (Multi-App Kiosk). Then suddenly: Managed Home Screen stopped showing all apps The device booted into MHS, but the screen was completely empty No policy changes were made on our side I tried several troubleshooting steps, but nothing fixed it. Eventually, I factory-reset the device and re-enrolled it as a Corporate-Owned Dedicated Device (COBO). Current situation after re-enrollment Even after a clean enrollment: No Android Enterprise device restriction profiles apply (Multi-App Kiosk doesn’t start at all) The device stays in the normal Samsung launcher Only very basic commands work: Remote restart App install/uninstall via group assignment All assigned apps show as Installed Profile status in Intune shows Success, but nothing is actually enforced I then upgraded the device to Android 16 (patch 2025-11-01). Unfortunately, the behavior did not change. Current configuration Android Enterprise → Device Restrictions → Multi-App kiosk Allowed apps: Teams, Managed Home Screen, Contacts Managed Home Screen installed Enrollment type: Android Enterprise – Fully Managed / Dedicated No OEM kiosk (no Samsung Knox settings) No Work Profile on the device Symptoms now Managed Home Screen never launches Kiosk mode is completely ignored Device is fully usable like a normal phone Only app deployments work, nothing else This began while still on Android 15 Updating to 16 did NOT resolve the issue Questions Has anyone seen this behavior where Android Enterprise policies stop applying entirely after MHS fails? Is there a known issue with Samsung A55, Android 15/16, or Managed Home Screen? Could this be related to a bug in the Fully Managed/Dedicated enrollment flow for the A55? Any recommended workarounds or known fixes? Any guidance is appreciated — this behavior is completely blocking Kiosk deployments for us. Thanks!
