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.
Intune 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 partner compliance onboarding
Hello, We develop a MDM solution and we would like to become device compliance partner to offer our customers conditionnal access functionality. After filling twice (the first time almost two month ago) the form "Intune partner compliance onboarding request" whose link is available on this page https://learn.microsoft.com/en-us/intune/device-security/compliance/third-party-partners, we didn't get any reply to our request. Would you know if there is any other way to integrate this partnership ? Any contact or anything to get some news about our request ? Thank you for your help. Best regards,Entra Shared Mode - Force App Stop
Hi All I hope you are well. Anyway, I was asked this yesterday and think I already might know the answer, but here goes. We had an instance of Microsoft Excel stuck in "getting things ready" on an Android Entra Shared Mode Device. Technical Support wondered if there was a way to Force Stop Excel or clear the app data. We had a look in Exit Kiosk Mode, Android Settings, and the Force Stop of Excel said "Action not allowed" and the clear the app data said "Unable to delete data for app" So, my question(s) would be, is going into Exit Kiosk Mode and even trying to force stop / clear data on apps even a valid option, or is this by design? Would adding Excel to this setting help? Any help or confirmation would be greatly appreciated. StuartPlatform SSO + Secure Enclave: True Passwordless macOS Sign-in with Entra ID?
Hi all, I'm testing macOS DEP/ADE + Intune + Platform SSO with Microsoft Entra ID. I have the Mac successfully enrolling through ADE, becoming Entra joined, and users can authenticate against Entra ID. With Platform SSO configured for Password authentication, users can sign in using their Entra password and everything works as expected. What I'm trying to achieve is a passwordless experience using Secure Enclave, similar to Windows Hello for Business: User enrolls the Mac via ADE Device joins Entra ID Platform SSO is registered Authentication uses Secure Enclave / biometrics (Touch ID) User is no longer prompted for their Entra password during normal sign-in/unlock scenarios Has anyone successfully implemented this with Intune and Platform SSO? Specifically: Is a true Windows Hello-like passwordless experience currently supported on macOS with Entra ID + Platform SSO? If yes, what authentication method and Platform SSO configuration are required? Are there any known limitations where Entra authentication still requires the cloud password even when Secure Enclave is configured? I'm interested in real-world deployments and lessons learned. Thanks!Speed where it matters: How Microsoft Intune helps IT prioritize time-sensitive actions
By: Albert Cabello Serrano | Principal Product Manager - Microsoft Intune A closer look at how Intune delivers updates to devices and the investments we’re making to help important changes move faster and more predictably. A common concern we hear from IT admins is, “How quickly will this change actually reach my device?” In many cases, the answer is much faster than expected. Today, 90% of policy updates, app deployments, and device actions in Intune are completed in under an hour. So where does the idea of “8-hour latency” come from? That number reflects a routine maintenance check-in used when devices are idle - not how Intune processes meaningful changes. Intune uses notification-based, priority-driven processing so that high-impact actions, like security policy changes or remediation steps, are handled promptly and reliably as possible. In this context, latency isn’t about making every action instant - it’s about providing predictable, prioritized delivery at global scale. The sections below break down how Intune prioritizes different types of updates and recent investments that are helping time-sensitive changes complete more consistently. How Intune delivers changes to devices Cloud-based device management is designed for real-world conditions; devices are not always online, fully charged, or on stable networks. Intune uses an eventual consistency model so devices can continue to be productive while converging to the desired state over time, without management actions unnecessarily disrupting users or workflows. Because devices operate in different conditions, not all device activity is handled the same way. To manage change reliably at scale, Intune uses different types of device check-ins depending on what needs to happen. Types of device check-ins in Intune Device check-ins generally fall into several categories, each triggered by a different type of action: Single‑device check‑ins: Occurs when an admin or user initiates an action on a specific device, such as starting a device action or installing an app from the Intune Company Portal. Change‑based check‑ins: Push‑triggered check‑ins used to deliver meaningful changes to devices as soon as possible. Client‑initiated check‑ins: Background activity that helps keep devices healthy, such as when a user signs in to a device or when malware status changes. Maintenance check-ins: Scheduled syncs that occur at predetermined intervals and can be client or service-initiated, depending on the platform. These typically occur approximately every 8 hours. Regardless of what triggers a check-in, any pending changes will be applied to the device when it occurs. What happens when an admin makes a change When an admin makes a change in Intune, such as updating a device compliance policy, deploying an app, or setting a configuration, Intune identifies the devices impacted by that change and initiates a change‑based check‑in for affected devices. For online devices, Intune sends a push notification prompting the device to establish a management session with the service, apply the change, and report enforcement status back to Intune. If a device is offline or unreachable, the change is applied when the device next checks in through available mechanisms. Four investments that help critical updates move forward faster The following product changes focus on reducing device‑change latency by shortening the time between an admin action in Intune and enforcement on the device, especially during peak or constrained conditions. 1. Check-in prioritization focused on what matters most Not all device activity carries the same urgency. Routine background check-ins can compete for service resources with devices that have important pending changes, such as compliance updates, remediation actions, or administrator-initiated configuration changes. Intune evaluates the potential impact of delaying a device check-in on security posture, compliance state or user productivity, and dynamically prioritizes processing accordingly. This real-time prioritization model ensures that high-impact actions move forward without being delayed by lower‑impact background activity. Prioritization adapts as conditions change, helping important updates reach devices more quickly and predictably without being delayed by lower-impact background activity. 2. Built-in resilience when multiple changes occur in quick succession Change activity often happens in bursts, with several related updates occurring in rapid succession. These periods of activity may be driven by operational needs or background processes, and can involve adjusting assignments, updating multiple policies, or rolling out configuration changes across the same set of devices. Intune dynamically coordinates notifications, so that each change requiring action triggers a corresponding device notification, even during high-activity periods. This helps improve consistency when applying multiple updates and reduces delays across consecutive changes on devices. Over the next several months, these improvements will extend to additional payloads delivered through the Intune Management Extension (IME), including scripts, Win32 apps, and custom compliance across both Windows and macOS platforms. 3. More timely notifications on Windows Intune notifies devices to check-in when changes require action. If the device is offline, on an unstable network, or low on battery, notifications may be delayed. This can cause missed check-ins or delayed actions. When notification services are delayed, blocked, or unavailable, devices may fall back to scheduled maintenance check‑ins to apply changes. For timely delivery, required notification service endpoints need to remain accessible so devices can receive management signals when updates occur. On Windows devices, Intune complements the Windows Notification Service (WNS) with the same notification protocol that powers Microsoft Teams via the Intune Management Extension. This helps increase the likelihood that devices receive management notifications when they’re online and reachable, improving visibility into whether policy updates or device actions have reached their destination. For more information, see the network endpoints for Intune documentation. 4. Optimized maintenance check-ins for iOS devices Background check-ins are still important to keep devices healthy when nothing else is going on. Unlike Windows devices, iOS devices don’t have client scheduled check‑ins and depend on service‑initiated maintenance check‑ins to ensure device health and compliance. During peak usage periods, these maintenance check‑ins can account for a significant portion of overall traffic, which can compete with devices that require immediate updates. Intune considers device activity in the scheduling of maintenance check‑ins during peak activity, making room for higher‑impact updates, while continuing to ensure devices check in regularly. This helps manage traffic and improves responsiveness when applying policies or remediation actions. What this means for you For IT admins: No additional configuration or workflow changes are required to benefit from Intune’s built-in notification system. When bidirectional communication with notification service endpoints is open, devices can receive and act on updates as they become available. For security teams: Faster delivery of device changes helps shorten the time between a policy update, a tightened Conditional Access rule, an updated compliance baseline, and a remediation action. For Zero Trust frameworks, where posture signals drive access decisions, this helps narrow the window during which a device could be out of compliance or vulnerable. Together, these improvements reflect how Intune is evolving into a more intelligent, priority-aware system. Rather than making every action instant, the focus is on prioritizing high-impact updates so they are delivered without unnecessary delays. This approach is expanding across a number of scenarios to provide a more consistent and predictable experience, helping reduce delays for key updates. Resources to learn more For another perspective on this topic, read an MVP’s take on demystifying the “8-hour” timing myth in this LinkedIn post. You can also watch the recent Tech Takeoff about this same topic to learn more about these improvements. Also, in the April edition of the What's New in Intune blog, we introduced a new segment called Myth vs. Reality. This post is part of that series. To stay current on new capabilities and updates as they ship, follow the What's New in Microsoft Intune blog. What myth should we debunk next? Leave a comment below or reach out to us on X @IntuneSuppTeam or @MSIntune.
Windows 11 + Intune: restrict devices to MDM-managed Wi-Fi profiles only
I was trying to solve a problem for our school exam laptops potentially accessing student phones as hotspots and thought I'd share the results in case it helps someone else. Environment Windows 11 Education 25H2 Microsoft Entra Joined (cloud only) Microsoft Intune Standard users (no local admin) Intune Wi-Fi profiles deployed normally Goal Prevent students from using personal hotspots or home Wi-Fi while still allowing normal Windows logon and access to approved school wireless networks. Most discussions I found concluded that the old "Allow only these SSIDs" WLAN Group Policy isn't available for Entra-only devices. Configuration Custom Intune profile using the Wi-Fi Policy CSP: ./Device/Vendor/MSFT/Policy/Config/Wifi/AllowWiFi = 1 ./Device/Vendor/MSFT/Policy/Config/Wifi/AllowManualWiFiConfiguration = 0 ./Device/Vendor/MSFT/Policy/Config/Wifi/AllowWiFiDirect = 0 ./Device/Vendor/MSFT/Policy/Config/Wifi/AllowAutoConnectToWiFiSenseHotspots = 0 The important setting appears to be: AllowManualWiFiConfiguration = 0 Microsoft describes this as: No Wi-Fi connection outside of MDM provisioned network is allowed. What I observed Before policy: Student Wi-Fi visible Staff Wi-Fi visible Home Wi-Fi visible Phone hotspot visible Neighbour Wi-Fi visible After policy: ✔ Student Wi-Fi (deployed by Intune) visible ✔ Test hotspot profile (also deployed by Intune) visible ❌ Phone hotspot not deployed by Intune hidden ❌ Home Wi-Fi hidden ❌ Neighbour Wi-Fi hidden The device automatically connected to managed Wi-Fi profiles and failed back correctly when one disappeared. Students only saw Wi-Fi profiles that had been deployed through Intune. I have now rolled it out to one of our laptop carts and it has worked flawwlessly for the last week. Unexpected result I originally thought this setting simply prevented users creating new Wi-Fi profiles. Instead it appears (at least in our environment) to hide every unmanaged SSID and only expose MDM-managed Wi-Fi profiles. That effectively solved the hotspot problem without kiosk mode or AppLocker, meaning I can apply it to all school managed student devices now too. Has anyone else seen the same behaviour? I'd be interested to know if this is consistent across: Windows 11 Pro Enterprise Hybrid Entra Join Different Wi-Fi adapters 24H2 vs 25H2Disallow O365 access from 'outside' of the Android for Work work profile?
Is there a way to block Android for Work users to connect to Office 365 with apps that are installed outside of the work profile? For example on my Android for Work capable device I have a work profile with eg. Outlook, which I can use to read my mail. However, i'm also able to use the Outlook app in my personal space to connect to Office 365, I was kinda expecting to only be able to connect to Office 365 from my work profile (?)
