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.BitLocker suspended by recent hotpatch?
We appear to have seen BitLocker get suspended by an automated process this past month or so (since August 2026 Patch Tuesday or thereafter) and left that way. Has anyone else seen their estate do this? We're using Autopatch with hotpatch updates. My No.1 suspect is KB5123607 but I've not yet been able to test this theory. What's not clear is if this was intentional or perhaps a mistake not to resume BitLocker after completing the patch. Leaving the devices with suspended BitLocker would seem to be a risky thing to do. Hotpatch updates means that our devices can now go for extended periods without being rebooted. BitLocker being suspended, resulted in the devices becoming non-compliant because encryption is a requirement. Many devices were going over 14 days with BitLocker in a suspended state. We send automated non-compliance emails to users after 14 days of that state. It's supposed to be highly unlikely that they'd reach that deadline before re-achieving compliance. A device from our last ring booted to recovery but was fine after a further restart. I was concerned this was the same thing. Would be good to get to the bottom of this, in case it occurs again and next time it causes a data loss.
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.Error 80190190 Entra Join Device
Yesterday we could enroll devices fine until about 10am. After that we can no longer complete an Entra join on a corporate laptop. It gives an error code of 80190190. In the logs it shows the device registered/enrolls then shows a removal less than a minute later. Successfully joined device using account type Successfully deleted the device with identifier
WHFB - Intune - Only PIN works and it causes print issues
Hello, I have personally attempted to deploy this for my environment and so has a colleague. We deploy windows hello specifically to a single machine or user, the PIN ends up being the only option which can be used, the device will say every other option is not available. It will constantly pop up at the bottom right that the password needs to be put in again to authenticate the user and printing will not work at all. The devices are fully capable of using facial recognition. Has anyone encountered any of these issues in a similar fashion with an AD > Entra environment ? Thank you, Jamie.
Any chance someone could help me with an Intune question related to SCEP Certificate?
Hi all, I've been having this issue with SCEP cert not recognizing the users and going by system account, and that will cause the device show as "Not managed" in Okta. Could anyone point me to the right direction on how to resolve this problem? I've tried working with Intune Support but not help there. Any help would be appreciated since we've been stuck on this for a couple of months now. Thanks, Arashk
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!
Intune Update Ring not applying to co-managed Windows 11 device
Hello. I am troubleshooting a co-managed Windows 11 Enterprise 23H2 device that is not receiving an assigned Intune Update Ring. The Windows Update policies workload is assigned to Intune, and CoManagementHandler.log confirms that the device is MDM-enrolled, provisioned, and reporting the expected co-management workload flags. The Update Ring settings do not appear under Configured update policies, in the managed policy section of the MDM diagnostics report, or under: "HKLM\SOFTWARE\Microsoft\PolicyManager\current\device\Update" The device also cannot check directly with Microsoft Update and reports that it cannot connect to the update service. I have already checked: Intune assignment, exclusions, and filters Co-management workload ownership MDM enrollment and synchronization WSUS, BigFix, GPO, and scan-source conflicts WinHTTP and user proxy settings DNS and outbound TCP 80/443 connectivity Windows Update Client and MDM event logs Local Update CSP and Windows Update registry settings Other Intune MDM policies apply successfully, and no firewall or network issue has been identified. CoManagementHandler.log repeatedly shows: Could not find one of the mandatory rules Failed to merge/resolve rules. Error 0x8000ffff Failed to process GET for assignment Could these rule-processing errors prevent the Update Ring from reaching the device even though Intune appears to own the Windows Update workload? Which event IDs, registry values, WMI classes, or Configuration Manager policy evaluations would best confirm where the process is failing? Also, the Update Ring is not reporting as failed or in error in the Intune admin center, but its settings are not appearing or taking effect on the endpoint. What additional steps can be used to determine why Intune considers the policy healthy, and how can the policy be forced or corrected so it applies successfully to the device?
