Recent Discussions
Intune - Entra ID Join vs Entra ID Hybrid Join
Greetings everyone, To begin this, let's imagine that a migration is being done for an organization and that Intune will be the chosen MDM solution. Autopilot will be used and let's consider two different options: Autopilot with Entra join for the device Autopilot with Entra Hybrid join for the device There are some main things I already consider when choosing between one or the other, such as: Considering the Entra Hybrid join scenario: The difficulty in setting up a tunnel (especially for some VPN brands) for frontline workers to be able to have access to the Domain Controller Considering the Entra join scenario: Some legacy applications that might require some device authentication aspect Group Policy Objects will not be applied The main objective of this discussion is to understand what are the main advantages and disadvantages regarding each one of these scenarios, in order to have a clear understanding of what are the possible implications of choosing the exclusively Entra join scenario (like "What capabilities are lost when we choose the Entra join scenario?"). I have read the documentation and know that "Microsoft recommends deploying new devices as cloud-native using Microsoft Entra join. Deploying new devices as Microsoft Entra hybrid join devices isn't recommended, including through Autopilot.", but I would like to get even more information regarding this topic and maybe even some professional nuance from people who have gone through the same process. Basically the good, the bad and the ugly type of insights. I would like to thank in advance any corrections about misconceptions or errors I might have written in this post and thank everyone who takes time to reply and be part of this discussion. Cheers!Issue with creating an issuing CA in Cloud PKI
I have activated an trial license for Cloud PKI a couple of days ago. I follow this guide to create a Root and Issuing CA https://oliverkieselbach.com/2024/03/04/how-to-configure-cloud-pki-certificate-based-wifi-with-intune/ I could create a root certificate successfully, but when i want create an issuing certificate i'm getting this error 'CA failed to be created' I have waited to a couple of hours to try it again but still no luck. What can cause this issue and how to solve this?
Best approach for migrating AD joined devices to Entra ID without wiping user profiles?
We’ve seen many organizations struggle with device migration when moving from traditional Active Directory (AD) or hybrid environments to Microsoft Entra ID. The biggest challenge is avoiding user disruption especially when wiping devices causes profile loss, app reconfiguration, and downtime. In large environments, wipe-and-reload becomes difficult to scale and impacts productivity significantly. Curious to know how others are handling this: Are you still using wipe/reimage methods, or are you using alternative approaches that preserve user profiles, applications, and settings? Would love to hear practical experiences from the community.
Unable to create Win32 apps in Intune
I am unable to create a very basic Win32 application in Intune. I get green check marks across the board but when I try to create the application I get an error message saying "Save Application Failed. TypeError: Cannot read properties of null (reading 'id')". Any suggestions?Reporting on Device CPU and Memory
I have a requirement to produce a monthly report on all our Intune managed Windows devices and the applications they have installed. I have written a script that is able to report on UPN, Device Name, Manufacturer, Model, Serial Number, OS, Total HHD and Free space along with all the applications installed. I am however unable to output the devices CPU and Memory details. I have tried using the Get-MgBetaDeviceManagementManagedDevices with the ProcessorArchitecture and PhysicalMemoryInBytes parameters but these just report 0 or NULL. What is the best way to report on the CPU and Memory from Intune?SSID connection using intune pushed profile kept prompting manual login
Hi, anyone encountered an issue where users connecting to an SSID with 802.1X authentication using an Intune-pushed Wi-Fi profile (with credential caching enabled) are still being prompted to enter their credentials manually? However, it works fine by configuring the network connection protocol manually. Thank you.
SCCM PXE Boot Deep Dive – Backend Flow & DP Migration
SCCM PXE Boot Deep Dive – Backend Flow & DP Migration I recently worked on a Distribution Point migration and noticed PXE requests were still routing to the old DP due to DHCP/IP helper configuration. I put together a deep dive explaining: PXE flow (DHCP and TFTP sequence) Role of Distribution Points What changes during DP migration Common failure points One key takeaway: PXE issues are almost always network and routing related, not SCCM itself. Curious how others are handling PXE in large environments. Are you standardizing on IP helpers or still using DHCP options? Full article: http://SCCM%20PXE%20Boot%20Deep%20Dive%20–%20Backend%20Flow%20&%20DP%20MigrationAutopatch - Microsoft 365 Apps Update Rings
I’m trying to understand how the UpdateDeferredVersions registry value is updated in an Intune Autopatch scenario, specifically the version and FileTime values. Registry path: HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Updates Example value: UpdateDeferredVersions = 16.0.19725.20170:13420719560293 | 16.0.19822.20180:13421142577563 I’ve observed the following and would appreciate any clarification: When I modify deadline or deferral settings via Autopatch (policy changes), the FileTime value does not update. Is there a delay or specific trigger (e.g., policy refresh, scheduled task, CDN sync) that updates this FileTime? How exactly is this FileTime calculated? Is it tied to when the build was released, assigned, or when the policy was applied? Is there any supported way to force or influence this FileTime update? Or is this value simply tracking when the build cap was issued, with deferral logic calculated relative to that timestamp? Additionally, I’ve noticed that updates only seem to apply when the FileTime is approximately 4 days behind the current date, is this expected behavior with Autopatch deferral logic? I was able to successfully test this updating FileTime 4 days behind ((Get-Date).AddDays(-4)).ToFileTime(). Any insights into how this mechanism works under the hood (especially with Click-to-Run + Autopatch interaction) would be really helpful. Below is Autopatch group settings for Microsoft 365 update rings that we set in our environment: Test - Deferral 0 - Deadline 0 Ring 1 - Deferral 1 - Deadline 0 Ring 2 - Deferral 2 - Deadline 0 Last - Deferral 4 - Deadline 1 Thanks in advance!Autopilot V1 vs “Device Preparation” (V2): Great direction — but is it enterprise-ready yet?
We evaluated Autopilot v2 but decided to stay on Autopilot v1 for large‑enterprise scale. Group Tags + dynamic groups are still essential for our device naming, segmentation, and governance model. We intentionally limit apps in EAS to speed up provisioning, so EAS‑based app deployment in v2 isn’t a compelling advantage for us. v2 looks promising, but until there’s stronger parity for enterprise‑scale targeting and naming, v1 remains the better fit. Curious how others at scale are balancing provisioning speed vs. segmentation without Group Tags.Protect org data on BYOD Windows / macOS devices
Hi All I hope you are well. Anyway, I have a need to protect org data on: Window personal / BYOD devices MacOS personal / BYOD devices What's the best way to achieve this? My thinking is: 1 X Conditional Access policy that blocks 1 X Conditional Access policy that allows via Edge, no persistent session, no downloads etc Device filter on both policies that target unmanaged devices Any other suggestions? SK
Intune enroll on redhat 10 KDE
**intune-portal 1.2603.31 fails to authenticate on RHEL 10 KDE Plasma — Misconfiguration(0) in gtk4/actions.rs** **Environment** - OS: Red Hat Enterprise Linux 10 - Desktop: KDE Plasma (Wayland, XDG_SESSION_DESKTOP=plasma) - intune-portal: 1.2603.31-1.el10.x86_64 - microsoft-identity-broker: 3.0.1-1.el10.x86_64 - xdg-desktop-portal-kde: 6.4.5-1.el10_1.x86_64 - webkitgtk6.0: 2.50.4-2.el10_1.x86_64 **Summary** The Intune portal fails to complete authentication on KDE Plasma. The same machine, same user account, and same tenant works correctly under GNOME on the same RHEL 10 install. The only difference between the working and non-working sessions is XDG_SESSION_DESKTOP (gnome vs plasma). **Error** The portal throws the following Rust error when attempting to start a login: ``` [intune-portal/src/gtk4/actions.rs:103:29] e = Error { context: "Starting a new login", source: Misconfiguration( 0, ), } ``` The OneAuth logs show: - `No accounts found in the OneAuth account store` - `Auth params authority is empty` - `MATS device telemetry disabled` This results in a [4kv4v] error in the Microsoft auth window with Code: 0. **Additional findings during investigation** 1. On RHEL 10, the KDE portal service is named `plasma-xdg-desktop-portal-kde.service` rather than the expected `xdg-desktop-portal-kde.service`. This means it is not auto-discovered without explicitly starting it, which is a secondary issue. 2. Overriding `XDG_SESSION_DESKTOP=gnome` at launch does not resolve the Misconfiguration(0) error, suggesting the portal reads the session desktop variable at startup rather than at auth time. 3. The auth flow reaches the broker, the broker starts MSAL, but the portal fails to pass authority parameters, so the login flow never presents a credential prompt to the user. **Steps to reproduce** 1. Install intune-portal 1.2603.31 on RHEL 10 2. Log into a KDE Plasma Wayland session 3. Launch intune-portal and attempt to sign in 4. Observe Misconfiguration(0) error — no login prompt is shown 5. Log out, log into GNOME on the same machine 6. Launch intune-portal — authentication completes successfully **Expected behaviour** Authentication should work on KDE Plasma in the same way it does on GNOME. **Workaround** None found. Using GNOME is the only current option on this machine.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?Intune application migration & app management
Migrating applications from Configuration Manager and other on-prem solutions to Microsoft Intune cloud native remains a challenging and time consuming undertaking, especially when dealing with complex line-of-business, legacy, and custom home-grown applications. Some organizations pursuing a full cloud-native management vision are encountering blockers related to application compatibility, re-packaging, and the scale of existing app estates - all while trying to maintain business continuity, device compliance, and preparing for the AI and Copilot era. Start here Read Face the future today by moving your application to cloud native Bookmark the Microsoft Intune planning guide Navigate to: Why app migration matters | Application packaging partners | Frequently asked questions Why app packaging matters Centralizing application management in Intune can deliver operational benefits such as unified enforcement and improved security posture—while supporting broader modernization goals. Common blockers that slow cloud-native adoption include: App compatibility and dependency complexity Manual repackaging effort at scale Risk of disruption during cutover Application packaging partners To address the complex realities of app migration, the Microsoft partner ecosystem has stepped up with specialized offers designed to reduce risk and accelerate cloud adoption. As part of this initiative our Microsoft partners Rimo3 and Robopack are offering no-cost, time-limited app migration service to all Intune customers who are looking to move from Configuration Manager to Intune. These services can help IT teams automate assessment, package conversion, and remediation for various app types, helping organizations realize the full value of Intune faster and with less disruption. Note: The app migration services listed on this page are offered directly by partners and are subject to their terms. Microsoft makes no guarantees or commitments regarding availability or outcome. Rimo3 helps IT professionals modernize, migrate, and manage applications at enterprise scale. The platform eliminates manual effort by automating packaging, validation, and patch testing. With patented IP, Rimo3 ensures every app is compatible, secure, and visible for dependencies and update readiness before deployment. Automated, unattended workflows reduce migration timelines from months to days, while contextual patch validation minimizes production risk. Rimo3 keeps environments evergreen with zero-touch app management and enhances Microsoft Intune with bulk operations, advanced controls, and unified reporting. Robopack is a cloud-native Intune app lifecycle platform that lets you package, deploy, and keep third-party apps updated, across one or many tenants, with phased control and PowerShell App Deployment Toolkit (PSADT)-based customization. Start with a self-service migration readiness report, mapped to the library of 41,000 pre-packaged, fully documented apps ready to go, or upload your own apps to be analysed and converted. Robopack Radar discovers apps installed across your estate, allowing you to quickly migrate to Intune and uncover Shadow IT. Frequently asked questions Q: Is this a Microsoft-managed service? A: No. Partner offers are provided directly by partners and subject to partner terms; Microsoft makes no guarantees regarding availability or outcomes. Q: What kinds of apps can these paths help with? A: The published focus is on helping migrations from Conifguration Manager to Intune, including complex legacy and line-of-business apps. Q: Where do I start if I’m early in planning? A: Start with the Intune Planning Guide and Migration Guide.
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, Tom
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?
Events
Save the date for May's #IntuneForMSPs Community Meetup! These community‑driven events bring together MSPs, Microsoft MVPs, and Intune experts to discuss top‑of‑mind topics shaping device management ...
Online
Let's talk about what actually works. Each month, Unpacking Endpoint Management brings you practical tips, proven strategies, and honest discussions. Our goal? To help you optimize and simplify the w...
Online
Recent Blogs
- 5 MIN READApril in Intune: faster app inventory on Windows and stronger cross-platform management for Linux and Apple devices.Apr 30, 2026
- 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 fas...Apr 30, 2026
