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
Microsoft Edge default browser with Intune
Hello everyone, I am looking for the best way to configure Microsoft Edge as the default browser for Windows devices managed through Microsoft Intune. I have reviewed the available Microsoft Edge settings in the Settings Catalog but have not been able to identify a specific setting that configures Edge as the default browser. Is there a supported and recommended way to enforce Microsoft Edge as the default browser for managed Windows 10/11 devices? If there are multiple approaches available, I would appreciate recommendations on the preferred method for enterprise environments. Thank you.
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?
Keyboard reverting on reboot
I'm having an issue with the keyboard reverting after OOBE. I'm using an English (UK) Windows 11 25H2 base image (deliberately — I want English display language, with Swedish keyboard/regional settings applied without needing to install a Swedish language pack). Deployment is native Windows Autopilot, no third-party tooling involved. Autopilot deployment profile: Language (Region) = Swedish (Sweden), Automatically configure keyboard = No. During OOBE, I manually select Swedish keyboard, and it's correctly applied — it's still Swedish through the first user logon. But after rebooting the keyboard silently reverts to English (UK). This is regardless of if I run pre-provisioning or user-driven. Is this a known/new behaviour, and how can I fix it?
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.Account Protection Policy Unable to Save
I am trying to configure an Account Protection policy to allow but not enforce Windows Hello for Business in my org's tenant. If I configure any of the device- or user-settings, the policy throws an error when trying to save. Two errors actually, both pretty generic. This has been persisting for the last 24hrs. Does anyone know what may be the culprit here?Problems identifying managed iOS devices when using APP
Hello, As the title says i am having a hard time getting this to work. We have been using APP for a long time, but it has not been necessary for us to have different policies for managed (we only use iOS) and unmanaged devices (all mobile device types). Now i want to remove APP from managed devices all together, and only enforce this on unmanaged devices (BYOD) Please see attached image of how it is configured today. I also have an CA policy which requires APP when using MS apps, where i have added and "Filter for devices" exclude with following syntax: device.enrollmentProfileName -contains "iOS standard profile" (which cover our enrollment profiles, both are fully managed) When enrolling a managed device, APP still is enforced. Does anyone have any tips? I wanted to try here before submitting a ticket to MS. As far as i have found out , the app.devicemanagmenttype is the only rule that can be used to filter managed devices when used with APP.
AD Minimization: How ready are organizations for the journey?
Microsoft's direction around Active Directory minimization is an interesting and important part of the broader cloud transformation journey. Moving more identity and device management toward Microsoft Entra ID can help organizations gradually reduce their dependency on traditional on-premises Active Directory and move towards a more cloud-first environment. What I particularly like about Microsoft's approach is that this is positioned as a journey rather than something that needs to happen overnight. For many organizations, Active Directory has been part of the environment for 20+ years. Over that time, a lot of dependencies may have been built around it, such as: Legacy applications, Group Policies, Domain-joined Windows devices, LDAP, Kerberos or NTLM dependencies, File servers and other infrastructure, Scripts and operational processes linked to AD. Moving new users, applications and devices towards a cloud-first approach is one part of the journey. The more interesting challenge is how organizations modernize the existing environment while minimizing disruption to users and day-to-day operations. This is where I think Microsoft's phased approach makes a lot of sense. Organizations can gradually identify and reduce AD dependencies while continuing to modernize identity, endpoint management and applications at a pace that works for their environment. I would be interested to hear from others who are already working towards AD minimization. Where is your organization in this journey today? Are you already actively reducing your dependency on on-premises AD? And what has been the biggest area to address so far, legacy applications, Group Policy, existing Windows devices, authentication dependencies, or something else? It would also be interesting to hear which Microsoft technologies or approaches have helped you most during this transition.
Intune and PSADT v4.x
I have a reboot package PSADT and the first dialog give the user the choice to defer the install, and a Scheduled Task is created to run an hour later. I am returning a 1618 (retry) and inside the PSADT, If Intune runs the app again, it will check my reg key for the defer and check that the task is active and hasn't run, and will exit without any interaction to the user and exit with another 1618. I am not an Intune admin and wondered if there are some downsides to trying this type of package in Intune. The defer time is the unknown for me and I am not sure how many times Intune will try to reinstall the reboot package within the deferred hour, and what Intune will do after the 3rd try...which I think is the max retries it might attempt in an hour? Any suggestions for a change in the exit codes or script interaction with Intune? Thanks.
