Intune macOS ADE: support for minimum macOS version enforcement before Platform SSO registration
Hi everyone, I would like to ask whether Microsoft Intune has any supported method, roadmap, or recommended workaround for enforcing a minimum or target macOS version during Automated Device Enrollment before Setup Assistant continues. The scenario is macOS zero-touch deployment with Intune, Automated Device Enrollment, Setup Assistant with modern authentication, Await final configuration, and Platform SSO registration during ADE. Platform SSO registration during Setup Assistant depends on newer macOS capabilities. In addition, some macOS deployment scenarios, such as Platform SSO password sync and macOS LAPS, may require or strongly benefit from a specific macOS version being installed before the user completes enrollment. Today, Intune can manage macOS software updates after enrollment using Declarative Device Management software update policies. However, that does not fully solve the issue where the Mac starts ADE on an older macOS version. In that case, the device may begin Setup Assistant and Platform SSO registration before the required macOS version is installed. What I am looking for is an Intune-native equivalent of enforcing a minimum or target macOS version during ADE, before Setup Assistant continues. Ideally, the macOS ADE enrollment profile in Intune would support options such as: - Minimum required macOS version - Target specific macOS version - Target specific build, if supported - Latest eligible macOS version for the device - Apply the OS update before Platform SSO registration and final configuration - Reporting in Intune showing whether the ADE OS update was required, started, completed, skipped, or failed Without this capability, organizations using Intune-only macOS deployment may still need manual IT staging or macOS restore/update before handing devices to users. This weakens the zero-touch deployment model, especially when adopting Platform SSO registration during Automated Device Enrollment. 1. Is there currently any supported way in Intune to enforce a minimum or target macOS version during ADE before Setup Assistant continues? 2. Is this capability on the Intune roadmap? 3. Are there any recommended workarounds for organizations deploying Platform SSO registration during ADE where a specific macOS version is required? Thanks in advance for any guidance from the Intune team or the community.
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.Retrieving the “Device inventory” of iOS devices via the Graph API
We use Microsoft Intune to manage our iOS mobile devices. To achieve the highest possible level of efficiency, we use PowerShell as a supplementary tool for administration. Since our devices may contain two SIM cards, it is important for us to be able to read this information in order to perform relevant processes (e.g., adding phone numbers to address books). In general, it would be desirable to be able to read the information from the “Device Inventory” of iOS devices. For the reasons mentioned above, we would like this information to be made available via the Graph API. Alternatively, there should be a way to provide this information for all devices in a single report.Is it really impossible to force an Intune sync from the command line?
Is it really not possible to force an Intune sync on a client computer from the command line? It seems like such a simple thing to do. Rather than make me dig 3 subpages deep to click a button, just let me fire off a DOS command and get on with my day. I'm familiar with the https://timmyit.com/2019/06/04/intune-invoke-sync-to-all-devices-in-intune-with-the-intune-powershell-sdk/, but honestly, clicking a "Sync" button should never be as complicated as that. I'm also familiar with Michael Neihaus' method... Get-ScheduledTask | ? {$_.TaskName -eq 'PushLaunch'} | Start-ScheduledTask That has never worked, but don't tell anyone because there are a lot of admins out there who think it does, and I'd hate to spoil their day. Am I just too dim to figure this out or is there really no way to sync from a CLI? Thanks,iOS managed contacts - how to deal with that?
Hi everyone, the last years i've already tried to solve the problem with the managed contacts. Because this was not possible earlier i forgot about that. Now i want to readress this issue. A very important article i've found is this one: Techcommunity Success: New contact sync scenario available with Outlook for iOS on enrolled devices With this thread i would like to discuss some unanswered questions of myself. I would really appreaciate any answer of you guys. 🙂 Goals: Business contacts should be able to be read through contacts app (because of caller-id) 3rd Party Messengers should not see these business contacts Thesises: It is not possible to achive this with Outlook for iOS and it's contact sync feature, right? (Because of these contacts are going to be synced through icloud, therefore these contacts are marked as "unmanaged contacts.) It is possible to achive these goals by using: an device configuration profile which configures an active sync account which only synchronizes the contacts of the users mailbox. These contacts are considdered as "managed contacts" an app configuration profile which disables the "sync contacts" feature for "outlook for ios" An App protection policy which disables "Viewing corporate documents in unmanaged apps Because of the fact this is only working for enrolled and managed devices, we need to tell the users: Caller identification is only possible if you enroll your device in Intune. (in relation to the previous points) So far, so good, but the bad news is: Because of the incopatibility with conditional access policies, we're hence not able to restrict the user from using other apps to connect their EXO account. Right? I would be very thankful if anyone can discuss this with me. (I think the best way to adress the different topics is to quote my post and answer inline.) Greetings, PatrickHybrid Autopilot as a Transition Strategy Toward Cloud-Native Endpoint Deployment
Hybrid Autopilot sometimes gets labeled as “legacy.” But in large enterprise environments, it can be a very practical transition architecture toward full cloud-native endpoint deployment. In one global rollout scenario I supported across multiple regions in a large enterprise environment, Hybrid Autopilot played exactly that role — helping modernize deployment while maintaining alignment with existing identity and infrastructure dependencies. Instead of treating Hybrid Autopilot as a long-term destination, we approached it as a controlled stepping stone toward Entra ID–only deployment. The challenge Many multinational environments still rely on: on-prem Active Directory legacy application dependencies region-specific provisioning constraints existing device naming standards network-dependent enrollment scenarios Moving directly to cloud-only join is often the goal - but not always realistic. Hybrid Autopilot helped bridge the gap. What worked well for us Several design decisions helped make Hybrid Autopilot scalable and predictable across regions. Machine-level secure connectivity before user sign-in One important enabler for Hybrid Autopilot in internet-based deployment scenarios was establishing machine-level secure connectivity before user authentication. Allowing devices to reach domain services during provisioning made it possible for offline domain join steps to complete successfully even when devices were deployed outside the corporate network. This supported direct-to-user deployment models without requiring traditional on-premises connectivity during setup, which becomes especially important in large enterprise global rollout scenarios. OEM hardware hash integration enabling deployment tagging and Zero Trust alignment Leveraging OEM-provided hardware hashes allowed devices to be pre-registered into Autopilot before shipment and associated with deployment group tags aligned to regional rollout logic. This enabled a consistent enrollment pipeline across distributed device shipments and created the foundation for automated targeting and naming alignment during provisioning. It also supported a stronger Zero Trust posture by ensuring that only officially procured and pre-registered corporate devices were allowed to enroll through the managed provisioning workflow. This helped reinforce device trust at the enrollment stage and reduced the risk of unauthorized or unmanaged endpoints entering the environment. Country-based deployment tagging Country group tagging then allowed hostname naming alignment to remain consistent with regional standards while enabling policy targeting and configuration logic to scale globally. This helped maintain predictable deployment behavior across regions while supporting large enterprise rollout consistency. Maintaining identity continuity during transition Hybrid join allowed compatibility with existing identity-dependent workflows to remain intact while preparing the environment for future Entra-native deployment approaches. Rather than forcing architectural change everywhere at once, this allowed transformation to proceed in controlled phases across regions. Why Hybrid Autopilot still matters? In large enterprise environments, endpoint modernization rarely happens in a single step. Hybrid Autopilot can support: modernization without disruption phased identity transition planning global rollout consistency alignment with existing provisioning standards preparation for cloud-native endpoint strategies When positioned correctly, it becomes part of the transition journey rather than technical debt. Curious how others are approaching this I’m interested to hear how others in large enterprise environments are using Hybrid Autopilot today. Are you treating it as a long-term deployment model, a transition architecture, or actively moving toward Entra ID–only deployment? It would be great to compare approaches and lessons learned across different enterprise rollout scenarios.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.
Autopilot Pre Provisioning Stuck at Device Setup
Hello Everyone, I was trying to use Autopilot Preprovisioning for Windows 10 devices that we would like to setup before we deliver it to our end user. We were getting correct Intune Autopilot profile Once we click on Pre provisioning Device Prepration completed in 2 minutes then Device setup never completed and stuck on Identifying for 60 minutes As my ESP setting is set to 60 minute. I am getting that red screen mentioning that provisioning can not be completed. however that device is visible in Endpoint portal with correct name template as per Autopilot profile Not sure why it is getting stuck at Device Setup Unable to identify Apps Configuration profile network Your advise on this issue would be really appreciable. I have tried it on OOBE device and existing device that met all the pre requisite.
