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?
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, DilanEntra Shared Device Mode Remote Control
Hi All I hope you are well. Anyway, does anyone have any experience of a decent remote control solution for Android based Entra Shared Mode devices? Preferably with the "LEAST" Android permissions to set / and or an App Config that can suppress Android permissions. SKHow to exclude specific machines from Intune compliance policy?
Hi, I need a few virtual machines to be excluded from the Intune compliance policy, I thought that the following setup would be sufficient to accomplish this and be able to access corporate data without the need to make these virtual machines compliant (they all have fixed IPs): Unfortunately this isn't working and I'm wondering how could I exclude this machines from enrolment. Thank you, Ion
Issue with Android iOS Wi-Fi authentication using certificates EAP-TLS with NPS
I am trying to configure Wi-Fi authentication for Android and iOS devices using certificates (EAP-TLS). I followed the guide below Support Tip - How to configure NDES for SCEP certificate deployments in Intune | Microsoft Community Hub, and I am able to successfully deploy certificates to the devices. The certificates are installed correctly on the final devices, so the distribution part seems to be working fine. However, the devices are not able to authenticate to the Wi-Fi network. The connection fails during authentication, and from what I can see the issue seems to be related to NPS. My doubt is specifically about the NPS configuration. In the guide, user or computer groups are usually added in the network policy conditions, but in my scenario I cannot rely on adding users or groups, since authentication should be based only on the certificate. I am unsure how to correctly configure NPS to accept these devices using certificate-based authentication without assigning them to a security group. Has anyone already faced this situation or can explain how NPS should be configured in this case? Any guidance or example configuration would be greatly appreciated. Thank you in advance.
