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.
Domain Join Configuration Profile suddenly erroring out.
Good morning, I have never posted on here, so I hope this goes through. I have been working on getting HAADJ Autopilot setup in my organization the past few weeks and it has been going well so far, except for yesterday. In my testing I have successfully deployed a few machines using HYAAD Autopilot process with not many issues. Yesterday I pre-provisioned a laptop with no issues, it domain joined and Entra joined and I was able to reseal. A few minutes later I tried a different machine and then it didn't work on that machine. Since then I have been trying multiple machines, and it seems to not be working now at all. I am not sure what broke or changed in my environment that caused this to change. I am very new at Intune and picked up this environment from a team that left a few months ago, so it is a miracle I have gotten this far by myself, but now I am at a complete loss. This just broke on me and I have no lead as to what may have caused this. Please if anyone has ANY ideas on where to start for this please let me know. Google has not been much help. This is what I see when I check the report on the domain join config profile:
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! pause
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?Moving 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
