Autopilot
121 TopicsParameter 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 Arya389Views1like2CommentsTeams 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, 0x801800141.1KViews0likes4CommentsDeploying 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!113Views0likes1CommentIntune 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.102Views0likes1CommentWindows 11 Autopilot and language packages
Hi everyone, I work for a Company with about 10.000 employees. We have a working SCCM envoirenment and an Autopilot PoC which should go live in the near future. The whole project was in cooperation with DELL. The problem here is that DELL scammed us a little bit, because they always ensured us, that we will get the DELL ready image for the region where Notebook is deployed (DELL ready Image contains the LPs for all countries in the Region e.g. central Europe, Asia pecific etc.). At the End Dell told us, that it us technically not possible to provide us this image and the only thing they can do is to provide us the basic US image That's where our problem started... We need some languages for our subsidaries in some countries. Thus we tried to create a package for the Language install. 1. First idea was to use the Powershell cmdlet install-language (Install-Language (LanguagePackManagement) | Microsoft Learn). The problem here is that this package runs pretty unstable. During Autopilot the command needs about 30 Minutes to finish. Sometimes the command throws an error: "Language Pack or feature could only be partially installed. Error Code: -2147023436“ (I guess it is a timeout but I didn't find anything on Google). The strange thing here is that this cmdlet runs pretty good and stable in private envoirenment. I tested it on my PC at home with Windows 10 22H2 and on a company device with the Microsoft en-US base Image (Win 11 23H2). With Autopilot it worked 70-80% of the time and the rest failed. It was very strange that in the logs the cmdlet faild with error Code: -2147023436, but after Autopilot finished, the Language was available if I called get-language. I also monitored it in the OOBE with the powershell. Result: cmdlet sometimes failed, Language was av Does anyone know how install-language works in the Background? Which URLs are called or what this error code means? Thank you for every kind of help Best regards Sven2.8KViews0likes7CommentsDomain 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:217Views0likes3CommentsBest Practices for Managing Autopilot Profiles Across Multiple Locations
Hello everyone, I have a question, and I’d like to get your thoughts on it. In a scenario where an organization manages Hybrid Join devices using Autopilot, distributed across different locations, each with its own Autopilot profile, how do you prefer to manage groups and profile assignments? The options I’m considering are: Option 1 Using a single dynamic group (e.g., “All Autopilot Devices”), with a query like: (device.devicePhysicalIDs -any (_ -startsWith "[ZTDid]")) to include all corporate devices, and then assigning profiles using Scope Tags. Option 2 Creating multiple dynamic groups, one for each location (e.g., “Location 1 Autopilot Devices,” “Location 2 Autopilot Devices,” etc.), with queries like: (device.devicePhysicalIds -any (_ -eq "[OrderID]: Location 1")) and then assigning the respective Autopilot profile to each dynamic group. What’s your approach, and what advantages/disadvantages have you encountered? Thank you to anyone willing to share their experience!Solved213Views0likes4CommentsWindows 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?Solved4.8KViews3likes7CommentsUPN Not getting updated on Azure
Hello team, Infrastructure: we are currently supporting Windows Autopilot (Entra Hybrid Joined). As expected, we see two device objects in Azure for each device we provision. One for Entra joined and another one for Entra Hybrid joined. Issue: Sometimes we receive requests to change the primary user of a device in Intune. When we change the primary user in intune, the new UPN is getting updated only on "Entra Hybrid Joined" object in Azure. If I check the "Entra joined" object, we still see the UPN of whom initially provisioned the device. It is not possible to update the UPN in Azure or delete the object. Due to this issue, the azure device limit has been reached for many service desk persons who help employees to setup the devices on behalf of users.62Views0likes0CommentsAutopilot OOBE stuck at "Sign in With Microsoft" page after authenticating on company specific page
I'm trying to set up intune for windows autopilot, but having trouble. I have the policies configured for our Hybrid AADJ environment, and when starting OOBE on a computer I do get prompted to log in at a screen showing our company specific info, but once I authenticate there (using either password or phone sign in) it comes up to an unbranded "sign in with microsoft" screen, asking me to sign in to my work or school account. On this screen, I can enter a username, but the Next button doesn't do anything. I'm just stuck on that screen. What could be causing this behavior? The computer is running W10 v1909 pro, if that matters. One of the intune policies assigned to it should upgrade it to Enterprise, but I'm not even getting that far.11KViews0likes7Comments