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.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.
Windows Autopilot Error Code 0x800705b4 Preparing device for mobile management
We are implementing a number of Windows Autopilot via Lenovo Thinkbook 15-ITL. These are being deployed to authorised users whether they are at home connected to their home broadband or in the office connect to the Wide Area Network. Despite lots of testing, we randomly see the the error (see attached). If we wipe the device a couple of times, it seems to remedy the issue. I've tried to look online about this about various posts talk about the TPM, which it is not. I've tried to look through the logs from the device - what a minefield of information that means something to someone. Has anyone any ideas? Thanks Martin
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.
Required Apps assigned to dynamic group are being skipped during pre-provisioning?
I have a few dynamic groups based on a group tag that gets assigned to the device during Intune enrollment. Each of those groups have a different set of applications that are installed on them. One of those dynamic groups just doesn't want to detect the required applications. There are supposed to be 5 apps. During pre-provisioning, it just jumps straight to the reseal page. If I let the device sit at the ESP page, the apps are installed in the background as if they aren't being tracked. If I quickly seal the machine before other apps are installed and unseal, it works like normal (tracking each of the apps and installing them). I can confirm the following: The device is in the proper dynamic group The Autopilot deployment profile and ESP settings are correct All of the applications are Win32 packages and install successfully during ESP This same setup works with my other dynamic groups fine. And it has worked previously with the trouble group before. I didn't change anything I tried: Removing and re-registering the device I'm about to delete and recreate the dynamic group or try to create a static group and see if I get the same results. Everything looks fine and I haven't been able to find something in the logs that points to why it doesn't see the apps as required. Again, if I let it sit, the apps install in the background fine. It's just baffling since my other dynamic groups work fine. Has anyone seen something similar?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 Jeens
AutoPilot Hardware hash error, You cannot call a method on a null-valued expression
When we trying to download the hardware hash for Autopilot via Powershell, we recently are getting null-valued expression errors on random laptops W11P laptops . So far on W10P we never hard problems. Is there a way to exclude $model, $make? Or can we adjust the script? our script: @ECHO OFF echo Enabling WinRM PowerShell -NoProfile -ExecutionPolicy Unrestricted -Command Enable-PSRemoting -SkipNetworkProfileCheck -Force echo Gathering AutoPilot Hash PowerShell -NoProfile -ExecutionPolicy Unrestricted -Command %~dp0Get-WindowsAutoPilotInfo.ps1 -ComputerName $env:computername -OutputFile %~dp0compHash.csv -append echo Done! pauseTeams Room System Autopilot deployment does not work - Error Code: 6, 0x80180014
Problem: We are attempting to deploy our Microsoft Teams Room (MTR) systems, some of which are already in use, using Windows Autopilot in self-deploying mode. Despite following the official guide, we keep encountering errors. https://learn.microsoft.com/en-us/microsoftteams/rooms/autopilot-autologin Procedure: Device: Certified Intel NUC, previously in use. Installation: Windows 11 Pro installed. Autopilot Import: Device imported into Autopilot. Group Assignment: GroupTag "MTR-ConsoleName" assigned. Dynamic Group: Device appeared in the Dynamic MTR group. Assignments: Deployment Profile and ESP (Enrollment Status Page) assigned. Teams Room Update App: Deployed via Intune, assigned to the MTR group, and integrated into the ESP. LAPS: Local Administrator Password Solution (LAPS) is active. Teams Rooms Pro Console: Device appeared and was assigned to a resource account with a Teams Room Pro license. Error Description: After the setup process, we consistently encounter an error during device registration for mobile management: Error Code: 6, 0x80180014 Attempts to resolve the issue: Deleted the device completely from Intune and Autopilot and re-added it. Created a custom Device Restriction Policy to allow all devices in the group. Additionally, during one attempt where the error did not occur, Teams failed to set up automatically. Questions: Why does error 6, 0x80180014 occur during device registration for mobile management? Are there specific requirements or settings beyond the official guide that need to be considered? What steps can be taken to ensure that Teams sets up automatically when the registration error does not occur? Objective: We aim to ensure that the MTR systems are smoothly deployed via Autopilot in self-deploying mode and that Teams sets up automatically. Thank you for your support!Teams Room System Autopilot deployment does not work - Error Code: 6, 0x80180014
Windows Autopilot and Configuration Management Client Installation Methods
I'm using Windows Autopilot to build my machines with AzureAD hybrid join. Currently as part of the ESP we deploy the configuration manager client and our VPN software (both Win32 apps) to them so we can get them co-managed ASAP. We also do this in ESP as blocking apps to control the device availability to users until they are completed. Our implementation partner advised us to install the Configuration Manager client in this manner to speed up co-management. Autopilot works (albeit slow at _ 60 mins). I am confused though on whether or not adding the configuration manager client into the autopilot build in this manner is supported? Reading this (https://learn.microsoft.com/en-us/mem/configmgr/comanage/how-to-prepare-win10) it states: You can't deploy the Configuration Manager client while provisioning a new computer in Windows Autopilot user-driven mode for hybrid Azure AD join. This limitation is due to the identity change of the device during the hybrid Azure AD-join process. Deploy the Configuration Manager client after the Autopilot process. For alternative options to install the client, see https://learn.microsoft.com/en-us/mem/configmgr/core/clients/deploy/plan/client-installation-methods. So reading this it seems what we are doing is invalid. So question 1: Is it incorrect/unsupported to install the configuration manager client as a Win32 app during autopilot (ESP or otherwise)? Furthermore I read here (https://learn.microsoft.com/en-us/mem/configmgr/comanage/how-to-prepare-win10) that it appears there is no longer a need to to deploy configuration manager client as an app at all but it can simply be configured in it via Home -> Device -> Enroll Devices -> Windows Enrollment > Co-management Authority You no longer need to create and assign an Intune app to install the Configuration Manager client. The Intune enrollment policy automatically installs the Configuration Manager client as a first-party app. The device gets the client content from the Configuration Manager cloud management gateway (CMG), so you don't need to provide and manage the client content in Intune. Is this method only valid post autopilot?
