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.
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.Which Entra account are you supposed to use to connect to a managed Google Play account?
At Connect Intune account to managed Google Play account - Microsoft Intune | Microsoft Learn, it says: We recommend using the Microsoft Entra account you're signed into to create the Google Admin account. So I used my Entra account to set it up. Now, though, when I look at the Managed Google Play item in Intune under Devices > Android > Enrollment, it has my email address under "Linked account". Was I supposed to create a shared Entra account to make this connection? What happens when I leave the org?
