Company Portal No Longer Installing During Autopilot Enrollment
Up until today, Autopilot enrollment which included Company Portal from the Microsoft Store (NEW) was successful. Starting today, the same enrollment workflow with similar hardware is failing to install Company Portal, reporting an error code of 0x87D1041C ("The application was not detected after installation completed successfully"). The only difference between yesterday and today? Today's enrollment including updating Windows to10.0.26200.8457 (today's Patch Tuesday update). I did find information that there was a similar issue nearly a year ago, where the latest Windows Update resulted in the same errors, and Company Portal requiring an update to fix. Are we looking at the same issue again?
Broken functionality of macOSWiFiConfiguration policies
I'm having trouble accessing macOSWiFiConfiguration policies. They are completely inaccessible via the Intune admin portal (no actual data is displayed) and the Microsoft Graph API. When using Graph (/beta/deviceManagement/deviceConfigurations or with policyId) an InternalServerError is returned mid-response, resulting in a truncated and malformed body. This error indicates that the 'wifiRequirePhysicalMacAddressEnabled' property (type Edm.Boolean, Nullable = False) has a null value stored in the back end. The policy also fails to load in the Intune which I suspect is caused by the same underlying issue. ERROR DETAILS: Endpoint: GET https://graph.microsoft.com/beta/deviceManagement/deviceConfigurations/{policy-id} Error code: InternalServerError Error message: "The property 'wifiRequirePhysicalMacAddressEnabled[Nullable=False]' of type 'Edm.Boolean' has a null value, which is not allowed." STEPS TO REPRODUCE: 1. Create a macOSWiFiConfiguration policy in the Intune admin portal. Additional note: front end will attempt to create the policy multiple times (around 20), even though the back end responds with a 201 HTTP code. 2. Try to GET the policy via Graph API (returns InternalServerError with malformed JSON body) or retrieve it using the WebUI (no data is shown). EXPECTED BEHAVIOR: The policy should be retrievable via Graph API and visible in the Intune admin portal. The property wifiRequirePhysicalMacAddressEnabled should hold a valid boolean value (true or false). ACTUAL BEHAVIOR: Failed to retrieve policy through Graph API and Intune WebUI. Has anyone else encountered this issue? Does anyone know how can I report this directly to Microsoft? All the options I have found lead me to AI chatbots which unfortunately are not helpful at all. Thank you.
Edge displays a splash screen saying ‘Sign in to sync your data’
Hello When the user logs in to a device for the first time and launches Edge, the following splash screen appears, even though we have created the Intune configuration below, which is intended to prevent this. We have following Intune configuration: Why does the splash screen still appear?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.App Enforced Restrictions not working on Chrome
Hi All I hope you are well. Anyway, a strange one here. We have implemented App Enforced Restrictions on unmanaged / BYOD macOS devices. This seems to have taken effect on Edge and Safari browsers but not Chrome. Is there anything we can do to resolve this or force BYOD macOS to use Edge? Info appreciated. SK
Policy applied allthough it shouldn't
Hi, all of a sudden Intune chaanges its behavior. I have a policy in place that sets persistent browser session. On the device filter tab I excluded devices with this syntax: device.trustType -eq "ServerAD" -or device.deviceOwnership -eq "Company" Starting last week I have to re-authenticate on a remote Desktop running Windows Server 2025 every 8 hours. Thats what the policy requires. In Entra I see in the logs for my user that this conditional access policy applied. I then extended the filter to this device.trustType -eq "ServerAD" -or device.deviceOwnership -eq "Company" -or device.operatingSystem -contains "Server" But it did not make a difference. Any idea what is going? This is not specific to my tenant. On a different tenant it behaves the same way.BYOD devices can't launch Windows 365 PC because of device compliance check during CA policy check.
We have a device compliance policy for all cloud apps. We would like to allow personal (BYOD) devices to be able to connect to Windows 365 Cloud PC. In the sign in logs we see the failures for application "Windows 365 Client" app id 4fb5cc57-dbbc-4cdc-9595-748adff5f414. We can't exclude that application in the conditional access policy as it's not available. We already added exclusions for Azure Virtual Desktop, Windows 365 and Windows Cloud Login. How can we allow BYOD devices to connect to cloud PCs?
