Teams 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 (Co-manage internet-based devices - Configuration Manager | Microsoft Learn) 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 Client installation methods in Configuration Manager. 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 (Co-manage internet-based devices - Configuration Manager | Microsoft Learn) 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 JeensAutomated 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
SCCM vs Autopilot
Hi All, i hope i'am writing in the right section. i have a request but before that let me explain the goal and what i'am looking for. in My company , i passed by several migration , and i had to re-deploy machines using 2 ways , USB image and join to domain manually , or using SCCM Server thanks to PXE mode. next migration i will be using Autopilot which i'am not familiar with . the problem i'am facing is , to re-deploy machine , i had to wipe it , install an OS , and start the OS in configuration page then CTRL + SHIFT + D , and from another machine i have to go to Intinues and do lot of stufff there (' like machine tag , add autopilot etc ) and then , back to the machine to continue configuration. i find this very long , and not practical specially if i have lot of machines to deploy in the same time. my question is , is there a simple way to deploy big number of machines using with Autopilot n without doing all these steps i mentioned , i was thinking about , deploying USB image , then perform DSREGCMD /JOIN , to add machine to Azure , but i'am not sure if it is good solution. Thank you in advanceAutoPilot Profile ???
Hi All I hope you are well. Anyway, it has came to my attention that some of inexperienced Intune admins are using the AutoPilot Hardware Scripts at the OOBE screen. No issue there. However, they are NOT checking that the devices actually sync to Intune > Devices > Enrollment > Devices Furthermore, they then proceed with the OOBE enrollment WITHOUT waiting for an AutoPilot to be assigned. The result is that devices never appear in: Intune > Devices > Enrollment > Devices No AutoPilot profile is assigned Is there any way to avoid this? Info appreciated SK
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?Parameter is incorrect error at ESP phase of Autopilot device preparation policy (Autopilot V2)
Hi Team, I am testing the Windows autopilot device preparation profile (Autopilot V2). Here, I need to rename the device while it is enrolling to the Intune (during ESP). So, I created a script that has below command to rename the device and rebooting it. Rename-Computer -NewName $newname -ErrorAction 'Stop' -ErrorVariable err -Restart -Force The issue I am facing now is that, when the device is at ESP, it runs the script to rename the device and also it restart the device. But after restart it does not complete the device preparation set up and s an shows an error screen called with message "Parameter is incorrect" and after clicking on OK, I get to see the login screen. After logging in, I am able to use my machine fine and the device is also renamed as per my organization standards. Does anyone also have faced this kind of issue while testing the Autopilot V2 with reboot script at ESP. Regards, Ashish AryaDeploying Microsoft Teams Rooms via Autopilot in Self-Deployment Mode
Description: We are experiencing issues with deploying our Microsoft Teams Room (MTR) systems via Windows Autopilot in Self-Deployment Mode. Despite following the official Microsoft documentation (Autopilot Autologin for Teams Rooms), the device fails to complete the login process. Setup Details: Device: Certified Intel NUC, previously in use. OS Installation: Windows 11 Pro pre-installed. Autopilot Import: The device was successfully imported into Autopilot. Group Assignment: GroupTag "MTR-ConsoleName" has been correctly assigned. Dynamic Group: The device appears in the associated dynamic MTR group. Profiles and Assignments: Deployment Profile and Enrollment Status Page (ESP) are assigned to the device. Teams Room Update App: Deployed via Intune and assigned to the MTR group (also included in ESP). LAPS: Local Administrator Password Solution (LAPS) is active on the device. Teams Rooms Pro Console: The device appears in the console and has been assigned to a resource account with a Teams Room Pro license. Issue: After completing the deployment process, the device hangs on the login screen and cannot connect to the resource account. This prevents the self-deployment process from completing. Steps Already Taken to Resolve the Issue: The device has been completely removed from Intune and Autopilot and re-added. A custom device restriction policy was created to ensure the device is allowed. All Intune and Azure policies were reviewed and optimized to avoid conflicts. Despite these efforts, the issue persists. Questions: Are there specific requirements or limitations that we might have overlooked? Are additional settings or policies required to ensure the device connects to the resource account successfully? Could existing policies, such as LAPS, interfere with the login process? Are there any known issues related to Autopilot and Teams Room deployments, particularly for previously used devices? We urgently request your assistance in identifying and resolving this issue, as these MTR systems are critical for our operations. Thank you for your support!
Intune Pre-Provisioning stuck at last app.
Good morning, We are running into an issue starting Friday where our devices seem to get stuck during the last app installation during white glove. The problem is that when I check the registry, all apps DO report as installed. I can further verify this by going into setting (still during preprovisioning) and seeing the apps are installed. Its showing 9/10 apps installed but, in the registry, there are only 9 apps total all of which have succeeded. I'm not sure what the hang up is with this "last app" that still mysteriously needs to install. I have been troubleshooting this since Friday. It started happening randomly without anyone making any config changes in Intune.
