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.Will Intune device-only subscription get additional value in FY27
Will the Intune device-only subscription (Microsoft Intune announces device-only subscription for shared resources | Microsoft Community Hub) get the additional features which Intune P1 will get in FY27 (Microsoft 365 adds advanced Microsoft Intune solutions at scale - Microsoft Intune Blog), Intune Remote Help, Intune Advanced Analytics and Intune P2? This would have a huge impact of our planning how to manage special purpose devices in production environments without any user affinity. Deploying security and configuration settings, Windows Autopilot for Windows IoT Enterprise LTSC kiosk deployment, Windows Autopatch (servicing), Remote Help and FOTA for Zebra devices would be drivers to add these production devices to Intune.
Intune MAM BYOD: Remove Account message for iOS devices
Hello, I am seeing an issue for Intune MAM BYOD(iOS) users. After a user account password reset, it causes Intune to remove the account configured from mobile applications like MS Outlook, Work, OneDrive, etc. Current Intune Configuration: Done - App Protection Policy Done - Conditional access policy --> Grant --> Requires app protection policy (checked) Users had to re-enrol to access his/her data. Here is the screenshot, Thank you,Close the Year Strong with Surface for Business Deals
As organizations look to maximize their remaining budget and prepare for 2026, now is the moment to modernize device fleets with Surface for Business. These limited-time Surface promotions make it easier to accelerate refresh cycles, strengthen endpoint security, and equip employees with devices that are AI-ready from day one. Surface for Business devices combine productivity-forward design, leading AI capabilities, and Microsoft security at multiple layers. Whether refreshing a subset of users or upgrading entire departments, organizations can close the year with hardware that helps reduce risk, assists in lowering management overhead, and positions teams for the next wave of AI-driven productivity. Secure by Design Surface for Business devices deliver hardware-based protections aligned with Secured-core PC standards. Hardware-based security, advanced firmware protections, and a growing number of memory-safe drivers help reduce exposure across the stack, providing peace of mind that clears the way for AI innovation. AI-Ready With advanced processors including powerful AI chips on supported models, Surface for Business devices are ready to help employees maximize their skills using AI to drive business forward. From a dedicated Copilot key 1 to Foundry on Windows 2 for developing local agents, these devices provide the foundation for people to achieve their best. Learn more about unlocking AI innovation in our new eBook. Ready to Deploy Surface for Business devices support Windows Autopilot 3 , enabling IT teams to deploy devices directly to employees, preconfigured with corporate profiles and security baselines, without imaging or desk-side setup. Combined with centralized management through Microsoft Intune 4 , organizations can reduce deployment time and help keep endpoints consistent from day one. Make the Most of Year-End Purchasing Opportunities Maximize remaining 2025 budget by exploring end-of-year savings on select Surface for Business devices. Work with your preferred reseller to capitalize on year-end spend, or purchase directly through Microsoft Store in the US 5 to take advantage of available offers that make modernizing your device fleet easier as you prepare for 2026. Resellers can help organizations align device selection, deployment plans, and support needs while optimizing budget utilization. Businesses purchasing through Microsoft Store benefit from fast, free shipping and a 60-day return window on most physical products. 6 Across both channels, Surface for Business offers provide a cost-effective path to refresh devices now rather than deferring upgrades—helping IT leaders complete their roadmap, meet procurement targets, and deliver new value to end users before the new year. Find a reseller [https://www.microsoft.com/surface/business/where-to-buy-microsoft-surface Buy from Microsoft Store US [https://www.microsoft.com/en-us/store/collections/surface-deals-bundles] References Feature availability varies by device and market. See Key Support for details. Some capabilities may require additional subscriptions not included with Windows or Surface devices. Windows Autopilot device preparation depends on specific capabilities available in Windows client and Microsoft Entra ID. It also requires a mobile device management (MDM) service such as Microsoft Intune. These capabilities can be obtained through various editions and subscription programs. Additional licenses required, not included with Surface. Offers and promotions vary by market. Terms apply. Microsoft Store only ships to certain countries; see Shipping options, costs, and delivery times - Microsoft Support for details.Issues with Windows 11 Autopilot Hybrid Joined Since last Week
Hi all, as of Thursday 4th December our Windows 11 Autopilot (Hybrid Joined) has ceased functioning. On the very first step, after the user attempts to enter their username&password, we can see the deployment profile gets downloaded to the device but then everything immediately stops with error "Something went wrong. Confirm you are using the correct sign-in information and that your organisation uses this feature. You can try and do this again and contact your system administrator with the error code 800004005". We can see that the ODJ process never starts. And we think we're seeing errors with the device reading the deployment profile JSON locally. Has anyone else had any errors? Wondering if Microsoft have made a change somewhere or have issues.
Conditional Access and -Online Device registration error
So there was an Issue creating new discussions yesterday and I ended up with a discussion with Heading only. :) We're using the Get-WindowsAutopilotInfo.ps1 script with the -Online switch to register our Entra Joined Devices, and the process is being blocked by Conditional Access. The sign-in logs point to Microsoft Graph Command Line Tools (App ID: 14d82eec-204b-4c2f-b7e8-296a70dab67e) as the blocker. Microsoft Support suggested whitelisting several apps, but unfortunately, that hasn’t resolved the issue—likely because the device doesn’t have the compliant state during online registration. We’re currently evaluating whether a dedicated service account with scoped permissions for Autopilot enrollment might be a workaround. Would be great to hear if anyone else has found a reliable solution.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.
Automated import of Hardware Hashes into Intune
Hi everyone, So, here is the script I used to pre-seed the hardware hashes into my Intune environment. Please check it over before just running it.. You'll need to create a csv called: computernamelist.csv In this file, you'll need a list of all your computer names like this: "ComputerName" "SID-1234" "SID-4345" You can use a the Get-ADComputer command to gather all your computers and output to a CSV. Features: It will run through 10 computers at a time. It will remove computers that it has confirmed as being updated in Intune. Pings a computer first to speed it up. Only for devices on your network or on the VPN. You can schedule it to run, or I just re-ran it a bunch of times over a few weeks. # Path to the CSV file $csvPath = "C:\scripts\computernamelist.csv" # Import the CSV file $computers = Import-Csv -Path $csvPath # Number of concurrent jobs (adjust as needed) $maxConcurrentJobs = 10 # Array to store the job references $jobs = @() # Ensure the required settings and script are set up [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned -Force Install-Script -Name Get-WindowsAutopilotInfo -Force # Authenticate with Microsoft Graph (Office 365 / Azure AD) Connect-MGGraph # Function to remove a computer from the CSV after successful import function Remove-ComputerFromCSV { param ( [string]$computerName, [string]$csvPath ) $computers = Import-Csv -Path $csvPath $computers = $computers | Where-Object { $_.ComputerName -ne $computerName } $computers | Export-Csv -Path $csvPath -NoTypeInformation Write-Host "Removed $computerName from CSV." } # Loop through each computer in the CSV foreach ($computer in $computers) { $computerName = $computer.ComputerName # Start a new background job for each computer $job = Start-Job -ScriptBlock { param($computerName, $csvPath) # Check if the computer is reachable (ping check) if (Test-Connection -ComputerName $computerName -Count 1 -Quiet) { Write-Host "$computerName is online. Retrieving Autopilot info..." # Ensure TLS 1.2 is used and execution policy is set for the job [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned -Force # Run the Autopilot info command and capture the output $output = Get-WindowsAutopilotInfo -Online -Name $computerName # Check if the output contains the success or error messages if ($output -like "*devices imported successfully*") { Write-Host "Success: $computerName - Autopilot info imported successfully." # Remove the computer from the CSV after successful import Remove-ComputerFromCSV -computerName $computerName -csvPath $csvPath } elseif ($output -like "*error 806 ZtdDeviceAlreadyAssigned*") { Write-Host "Error: $computerName - Device already assigned." } else { Write-Host "Error: $computerName - Unknown issue during import." } } else { Write-Host "$computerName is offline. Skipping." } } -ArgumentList $computerName, $csvPath # Add the job to the list $jobs += $job # Monitor job status Write-Host "Started job for $computerName with Job ID $($job.Id)." # If the number of jobs reaches the limit, wait for them to complete if ($jobs.Count -ge $maxConcurrentJobs) { # Wait for all current jobs to complete before starting new ones $jobs | ForEach-Object { Write-Host "Waiting for Job ID $($_.Id) ($($_.State)) to complete..." $_ | Wait-Job Write-Host "Job ID $($_.Id) has completed." } # Check job output and clean up completed jobs $jobs | ForEach-Object { if ($_.State -eq 'Completed') { $output = Receive-Job -Job $_ Write-Host "Output for Job ID $($_.Id): $output" Remove-Job $_ } elseif ($_.State -eq 'Failed') { Write-Host "Job ID $($_.Id) failed." } } # Reset the jobs array $jobs = @() } } # Wait for any remaining jobs to complete $jobs | ForEach-Object { Write-Host "Waiting for Job ID $($_.Id) ($($_.State)) to complete..." $_ | Wait-Job Write-Host "Job ID $($_.Id) has completed." } # Check job output for remaining jobs $jobs | ForEach-Object { if ($_.State -eq 'Completed') { $output = Receive-Job -Job $_ Write-Host "Output for Job ID $($_.Id): $output" Remove-Job $_ } elseif ($_.State -eq 'Failed') { Write-Host "Job ID $($_.Id) failed." } } This is all derived from: https://learn.microsoft.com/en-us/autopilot/add-devices "Get-WindowsAutopilotInfo" is from this link. Hope this helps someone. Thanks, Tim JeensMoving from MDT/WDS to Autopilot – Real-World Lessons, Wins & Gotchas
Hi all, We’ve been moving away from an ageing WDS + MDT setup and over to Windows Autopilot, and I thought I’d share a few key lessons and experiences from the journey. In case anyone else is working through the same transition (...or about to). Why the change? MDT was becoming unreliable, drivers/apps would randomly fail to install, WDS is on the way out, and we needed a more remote-friendly approach. We also wanted to simplify things for our small IT team and shift from Hybrid Azure AD Join to Azure AD Join only. We’re doing this as a phased rollout. I harvested existing device hashes using a script from a central server, and manually added machines that weren’t online at the time (most of which were just unused spares, we haven't introduced new hardware yet). If you want a copy of this auto-harvest, please see my next post, this script is useful as it'll just go off and import the hardware hashes into Intune, and can run against multiple computers at a time. (I will add the link to the post once made). Some of the biggest hurdles: • 0x80070002 / 0x80070643 errors (typically due to incomplete registration or app deployment failures) • Enrollment Status Page (ESP) hangs due to app targeting issues (user vs device) and BitLocker config conflicts • Wi-Fi setup with RADIUS (NPS) was complex, Enterprise Certificates and we're still using internal AD for authentication, so user accounts exist there and sync over to Azure. • Legacy GPOs had to be rebuilt manually in Intune, lots of trial and error • Some software (like SolidWorks) wouldn’t install silently via Intune, so I used NinjaOne to handle these, along with remediation scripts in Intune where needed We also moved from WSUS to Windows Autopatch, which improved update reliability and even helped with driver delivery via Windows Update. What’s gone well: Device provisioning is more consistent, updates are more reliable, build time per machine has dropped, and remote users get systems faster. It’s also reduced our reliance on legacy infrastructure. What I’m still working on: Tightening up compliance and reporting, improving detection/remediation coverage, figuring out new errors that may occur, and automating as much manual processes as possible. Ask me anything or share your own experience! I’m happy to help anyone dealing with similar issues or just curious about the move. Feel free to reply here or message me. Always happy to trade lessons learned, especially if you’re in the middle of an Autopilot project yourself. Cheers, Timothy Jeens
