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
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.Hybrid Azure AD joined device not enrolling into Intune
Issue A Windows device successfully registers in Entra ID (Hybrid Azure AD join) but never enrolls into Intune. Result: Device appears in Entra ID Device does not appear in Intune Intune Management Extension is not installed Device remains SCCM‑only (co‑management never starts) Log (CoManagementHandler.log): EnrollmentUrl = (null) Device is not MDM enrolled yet. All workloads are managed by SCCM. Environment Windows 10/11 Hybrid Azure AD Join On‑prem AD + MECM (Cloud Attach / Co‑management enabled) Microsoft 365 E3 (Intune license assigned) Device on corporate trusted network What I’ve done Verified Azure AD join and MDM URL Confirmed MDM user scope = All Verified Intune enrollment restrictions allow Windows Verified user has Intune license Identified Conditional Access policy targeting “Register or join devices” Updated that CA policy to Exclude → Microsoft Intune Enrollment Waited for replication and retried enrollment (deviceenroller.exe /c /AutoEnrollMDM) Question Despite excluding Microsoft Intune Enrollment, the device still does not enroll into Intune.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.
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.Hybrid to Entra ID WiFi Certificate Authentication NPS via WHfB Cloud Trust & Cloud PKI-Replace ADCS
Hello Team, We are working in moving our devices Hybrid Entra ID Joined to Intune autopilot Entra ID Joined Current scenario: Hybrid Entra ID Joined devices (joined to both on-prem AD and Entra ID) Active Directory with Entra ID Connect for object synchronization AD Certificate Services (ADCS) issuing user and device certificates via GPO auto-enrollment Group Policies to push Wi-Fi configuration (EAP-TLS using device certificate) NPS RADIUS server using EAP-TLS ("Smart Card or Other Certificate") for secure 802.1X authentication On-prem SSO enabled through standard Kerberos authentication Now, I am testing Autopilot Win11 Entra ID Joined with WHfB using Cloud trust to SSO to on-prem resources. The autopilot is working, however, the WIFI is not working as the autopilot device doesn't have any certificate from the on-prem ADCS. What is the best practice to try be as much cloud and begin to decommision on-prem services. I have 2 options to push the User and computer certificate to the AUtopilot device: Option 1: Intune Certificate Connector that will bridge on-prem ADCS and Intune, In Intune a PKCS profile to install the certificate to the autopilot device. Option 2: Intune Cloud PKI and configuration profile PKCS profile to install the certificate to the autopilot device. on-prem install the root CA from the Intune cloud PKI. https://learn.microsoft.com/en-us/intune/intune-service/protect/microsoft-cloud-pki-deployment For the on-prem SSO I will contine using Cloud Trust. Component Target Device Identity Autopilot + Entra ID Joined only (no domain join) User Sign-In Windows Hello for Business (WHfB) with Cloud Kerberos Trust Certificate Issuance Replace ADCS/GPO with Microsoft Cloud PKI and Intune PKCS Wi-Fi Authentication Retain existing NPS RADIUS using EAP-TLS, but trust both ADCS and Cloud PKI root CAs On-prem SSO Enabled by AzureADKerberos on domain controllers Hybrid Devices Continue current operation during the transition — no immediate impact The 2 network environment needs to coexist: the on-prem and the cloud. Device Type Certificate Issuer Wi-Fi Auth SSO Hybrid AD-joined ADCS via GPO EAP-TLS (device cert) Native Kerberos Autopilot Entra ID Joined Cloud PKI via Intune EAP-TLS (device cert) WHfB + Cloud Trust (AzureADKerberos) How the New Wi-Fi Auth Works: Autopilot devices receive: A device certificate from Cloud PKI via Intune A Wi-Fi profile using EAP-TLS authentication NPS RADIUS server: Validates the device cert Issues access to Wi-Fi WHfB Cloud Trust provides a Kerberos ticket from AzureADKerberos, enabling seamless access to file shares, print servers, etc. This allows Autopilot Entra ID Joined devices to: Connect to Wi-Fi without GPO Access on-prem resources without passwords High-Level Implementation Steps Deploy Microsoft Cloud PKI in Intune Configure PKCS profiles for user and device certificates Deploy WHfB Cloud Trust via Intune + Entra ID (no AD join needed) Configure AzureADKerberos on domain controllers Install Cloud PKI Root CA in NPS server trust store Update NPS policy to accept certificates from both ADCS and Cloud PKI Deploy Wi-Fi profiles to Autopilot devices via Intune (EAP-TLS using device cert) Based on it, what is the best practice to move the device to the cloud as much possible.
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.
App Protection: Custom app vs Partner app
Is there any functional difference in using an app protection policy to manage a public partner app versus a custom application? We have an app vendor that says they wrapped their app with the SDK but it is not on the partner list so we cannot pick it from the public app list. Which leaves us with the custom app option. Is the functionality the same? Will it show up on the app protection report, work with conditional access policies, other Microsoft solutions, etc.? Thank you - Jessie
