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?
Platform SSO "Page not found" on macOS Tahoe 26.4 — Company Portal 5.2602
Environment: macOS Tahoe 26.4 Company Portal 5.2602.0 (latest as of April 2026) Microsoft Intune — Automated Device Enrollment (ADE) Platform SSO with Secure Enclave (UserSecureEnclaveKey) SSO Extension: com.microsoft.CompanyPortalMac.ssoextension / Team ID: UBF8T346G9 URLs configured: https://login.microsoftonline.com, https://login.microsoft.com, https://sts.windows.net Device: MacBook Pro 14" (Apple Silicon), supervised, ADE-enrolled Issue: During Platform SSO registration, after the user authenticates successfully in the SSO registration prompt, Company Portal crashes with a "Page not found" error. The registration never completes — no WPJ certificate is created, no SSO registration key is stored in the Secure Enclave. Console logs show: CompanyPortalMac: URL(filePath:) API misuse — usingass old file path API which does not support security scoped bookmarks The error occurs specifically at the token exchange step after authentication, suggesting the Company Portal binary is calling a deprecated macOS file URL API that Tahoe 26.4 now enforces more strictly. What we tried: Full wipe and re-enrollment via ADE Removing and reinstalling Company Portal via Intune Different user accounts Verified SSO extension profile is correctly applied (confirmed via profiles show -type configuration) Verified network connectivity to Microsoft identity endpoints Tested on a clean macOS Tahoe 26.4 install — same result Expected behavior: Platform SSO registration completes, WPJ certificate is created, and SSO token is cached for seamless authentication. Actual behavior: "Page not found" after authentication in the SSO registration flow. Console shows the URL(filePath:) API misuse warning. Registration fails silently — no error surfaced to the user beyond the page not found screen. Question: Is this a known bug in Company Portal 5.2602 with macOS Tahoe 26.4? Is there a newer build or hotfix addressing the URL(filePath:) deprecation? Any workaround available? Tags: Platform SSO, macOS, Company Portal, ADE, Intune
IOS - Embedded Webkit - Not Reporting Correct Device info
It appears that with the latest iOS versions (26.3.1 through 26.4), applications that rely on an embedded WebKit for sign-in are no longer reporting accurate device details within Device Info. Users have company-issued phones that are successfully enrolled in Intune, but when they attempt to sign in to Apple Mail, Conditional Access is denying the login. After reviewing the logs, iOS is reporting the OS version as 18.7.0 to Intune, even though the device is actually running iOS 26.4. Additionally, the device information is coming through as blank, so attributes are not being evaluated. When looking at other logins via the outlook app on that device it all appears normal and works. Has anyone else observed this behavior where WebKit is sending incorrect data to Intune? Does anyone know of a workaround other than relaxing Conditional Access policies?
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.
Intune iOS User-Based App Targeting
I’ve noticed an issue with user-based targeting and was wondering if this is an issue, or I'm just using it wrong. Lets say I want an iOS app to be deployed out to a user group, but only to company owned devices of those users. I set the assignment for required user group and assign an Include filter for corporate owned devices. If this app is also Available for All Users, then the app deploys out to all devices from the required user group, even their personal devices. It basically forgets there is a filter for the required user group assignment. Any way around this? It feels like a glitch in how Intune deploys apps.
Microsoft Managed Home Screen: Unwanted Samsung One UI 8.0 Elements Appearing
Hello Tech Community, Our organization is currently deploying a configuration in Microsoft Intune using a Corporate-owned dedicated device enrollment profile. We’ve applied a device restriction policy to configure Samsung tablets in Multi-app Kiosk mode, with Managed Home Screen set as the launcher. Instead of using an app configuration policy, Managed Home Screen is configured through the device restrictions policy. We’ve left the device navigation options unconfigured, which should hide the following UI elements: Android Overview button Android Home button Android App drawer Once all policies and required apps are installed, Managed Home Screen successfully acts as the launcher for end-users to sign in. Overall, this works well; however, we’ve encountered an intermittent issue: After multiple lock/unlock cycles, the navigation bar sometimes reappears, showing the Overview, Home, and App Drawer buttons. This allows users to access background apps that are not exposed through Managed Home Screen, which defeats the kiosk experience. Device details: Samsung Galaxy Tab S10 FE Android 16, One UI 8.0 Managed Home Screen version: 2.2.0.107721 Has anyone experienced this behavior or have recommendations to prevent these UI elements from reappearing? I’ll gladly provide additional details about our configuration if needed. Thank you!Have OneDrive or SharePoint files/folders on home screen of iPad without internet connection?
This. I'm on a big iOS project. We have several users who need files on an ipad when traveling, and be able to open them when there is no internet connectivity. These files aren't intended to be edited, just 'read only.' These files do not contain any sensitive corporate data. The content lives in SharePoint online and I'm using OneDrive as a bridge to their sharepoint site. BUT the files can only be viewed on the ipad within the OneDrive app without internet access. These are devices using user affinity enrollment. Initially, the solution for users was to use the 'Mark Offline' feature within the OneDrive iOS app. I used Power Automate to have it fetch new files found in OneDrive and move them to the teams SharePoint site. These shared devices are locked down (an understatement). These will be used by the least computer savy/literate people and so having them dive through OneDrive folder after folder, even offline, is a tall order to ask. I totally get it and don't want them doing that either. So now I have to move onto plan B. How can we put the files that live within OneDrive/Sharepoint onto the home screen without an internet connection when the ipad is 'out in the field.?' This would make it infinitely easier for them. The key here is to not have end users manually moving files around. We don't want them to even have to go into OneDrive and mark folders/files offline, if possible. We don't have the SharePoint app on them. I tried the SP app a while back, and it is a hot mess of garbage. I could revisit it. Whatever I can get to work of course we'll have to modify our Intune polices. Thoughts?Hybrid 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.Company portal says rooted device but it's not - Android
Hi everyone, We came across a situation where one of our Android user is not able to access Outlook and Teams due to rooted device. We configured only App protection (MAM) policy in Intune and blocked access from Jailbroken/rooted devices. Only the MAM policy as been applied on the device and the device is not enrolled with Intune. So far, we have followed below troubleshooting, Rejoined the device again, however after sometime, the error will be appeared again. Check whether the device is rooted or not (Go to Settings > About phone > Status Information > Phone Status). Phone status says official. I believe this means not a rooted device. Below is the error message from the company portal Device Status in Azure AD (Not enroll with Intune) I would appreciate if anyone can help me whether I have anything else try out before I create a support case with Microsoft. Thanks, Dilan
