Pinned Posts
Forum Widgets
Latest Discussions
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?
Reenroll Company Owned With Work Profile Android
I have been putting together a profile that will allow our company to enroll our Android devices into Intune as a Company Owned with Work Profile. One question I currently have is, if we ever need to remove the Work Profile say for troubleshooting do we have to do a complete factory reset of the phone to reenroll it back into Intune? Seems crazy to have to do that just to test or try to fix something especially if the person has data on the personal side like pictures, apps, etc. Please let me that is not the case! LOL!How to configure Intune to not allow remote wiping of personal devices
I’m a journalist seeking to do a story around best practices for configuring Intune, in the wake of last week’s destructive attack against Michigan-based medical device maker Stryker. It looks like attackers gained admin-level access to Intune and used it to wipe employees’ personal devices that were enrolled in Intune. I was speaking with someone who has recent Intune administration experience, and his take is that like other UEM/BYOD/endpoint management tools, none of this software should be configured with the ability to fully wipe a personal device. Instead, it should be only placing sandboxed apps or directories onto a device. Only this sandboxed stuff should be remotely nuke-able. His supposition is that if personal data can be wiped, then either the Intune admins set it up incorrectly, or their documentation for employees who self-configure didn’t specify how to add their device but not give Intune full wiping capabilities. My questions: 1) Is it possible to configure Intune so that it doesn’t have overly broad permission to wipe an entire, personally owned device? 2) How exactly would one do that (on either Android or iOS)? There’s lots of “ditch Intune” chatter on Reddit now, supposedly tied to CISOs/executives reacting to the Stryker attack. So I’m seeking clarity around whether the tool can be configured to not remotely wipe personal data, even if other defenses that should be in place (such as requiring multiple admins’ approval before wiping devices, setting alerts if more than a few devices get remotely wiped at once, and so on) aren’t there.Windows Autopilot Hybrid Join failing with OOBE error 80004005
Hello everyone, We’re facing a consistent issue with Windows Autopilot user‑driven Microsoft Entra hybrid join where devices are provisioned using a Hybrid Join Autopilot profile, but Hybrid Join does not complete. Setup (High level) Windows Autopilot (user‑driven) Autopilot profile: Microsoft Entra hybrid joined Only one Autopilot profile Domain Join profile configured (domain + OU) Entra Connect: Hybrid Join + device writeback enabled Intune Connector for Active Directory installed and healthy MDM auto‑enrollment enabled Issue During Autopilot OOBE, the device frequently shows: “Something went wrong” Error code: 80004005 Despite this, Autopilot continues and completes. Resulting Device State After provisioning: Device appears in Entra ID as Microsoft Entra joined (not Hybrid) Device is enrolled into Intune and shows compliant Device‑scoped Intune MDM policies do not apply dsregcmd confirms Hybrid Join never completed Understanding So Far From correlating the OOBE error, dsregcmd output, and final device state: Hybrid Join starts but fails mid‑process Windows does not roll back provisioning Device falls back to Entra ID Join Join type is finalized for that run Resetting without fixing the root cause repeats the behavior This explains why devices look healthy but are not Hybrid Joined and why device‑based policies don’t reflect. Questions Is 80004005 during Autopilot OOBE a known indicator of Hybrid Join / Offline Domain Join failure? Is fallback from Hybrid Join → Entra ID Join expected when Hybrid Join prerequisites fail? Once a device ends up Entra joined, is wipe + reprovision the only supported recovery after fixing the root cause? Public Wi‑Fi / offsite scenario: Has anyone successfully completed Hybrid Autopilot using pre‑logon VPN / device tunnel (Always On VPN, GlobalProtect, AnyConnect, etc.) to provide DC line‑of‑sight? Which logs are most useful to confirm the exact failure point (ODJ, dsreg, Intune Connector, ESP)? Thanks in advance for any insights or field experience.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.
Can We Set a Default Font for Office Apps via Intune?
Hello everyone, I would like to know if it’s possible to configure a default font for Word, Excel, PowerPoint, and OneNote using Microsoft Intune. Has anyone implemented this, and if so, what’s the recommended approach? Thanks in advance for your insights!
Android 15 - CredentialProviderPolicy not surfaced by Intune
I have been having an issue with Android 15 devices. We use Authenticator as our password autofill provider. As soon as a device is updated from Android 14 to Android 15, the password autofill provider is no longer set and the setting to change it is 'blocked by work policy.' I have already tried removing all policies that apply to the devices (device config and device compliance policies) and factory resetting them. Simply having them enrolled as corporate owned fully managed devices causes this to happen. I raised the issue in the Android Enterprise community blog. A link to that is included below. Someone on that thread found that there is a policy in Android 14/15 called the credentialproviderpolicy. When that policy is blocked or unconfigured, this behavior happens. I cannot find anywhere in Intune where I can set this policy. It seems that it is allowed by default when managing Android 14 with Intune, but not set or blocked when the device switches to Android 15. Is there any way to specifically set a policy that is not reflected in the Intune UI? This is a blocker for being able to move more phones to Android 15. Link to Android Enterprise thread: https://www.androidenterprise.community/t5/admin-discussions/android-15-cannot-set-default-password-app/m-p/8827#M2105 Thanks, TomCompany 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
Windows Hello - optional
Hello community, I'm trying to set Windows Hello as optional (not forced) for users in our org. Currently we have security group for people who asked for Windows Hello to be enabled for them. All devices are Windows 11 fully managed by Intune. Current Win Hello solution is provided by Intune policy - identity protection - "Configure Windows Hello for Business". It works, but as mentioned I would like to make it optional for everyone in our org so users can decide whether use it or not. Is it possible?
