How to Use Autopilot
Summary/Overview
This guide explains how to use Microsoft Autopilot for machines that have yet to be run through Autopilot. It covers the steps involved in enrolling a device in Autopilot, assigning a deployment profile, and troubleshooting any issues.
Prerequisites
- Access to the Microsoft Intune portal
- A device that is eligible for Autopilot
- The device a member of the Autopilot security group in Azure Active Directory
- The assigned user's UPN (this might NOT be the same as their email address)
- User object must have a valid Intune license (you can use the Troubleshoot + support page in the Intune portal to check user status for the green check next to Intune licensed)
Step-by-Step Instructions
- Find the serial number in the Autopilot Enrollment list.
Go to Devices > Device onboarding > Enrollment > Windows Autopilot > Devices in the Intune portal.
2. Check the device's assigned profile.
The device should not yet be assigned a deployment profile. The Assigned Profile property should say Assigned Externally or Not assigned.
3. Copy the device name.
At the bottom of the page, copy the device name shown as a hyperlink. See the image above.
4. Add the device to a security group.
In Azure Active Directory, find the security group you want to use for Autopilot deployment (e.g., SG-APT-UserDrivenDeploy). Add the device name to the members of the security group.
If the device will be used in any of the four main locations, follow the above instructions to add the device to the SG-INT-CFG-CLD-VerathonCorporateWiFi group. This will make the new Verathon WiFi SSID available.
5. Wait for the device to pick up the assigned profile.
The device may take some time to pick up on the assigned profile (around 12-15 minutes). You can verify that it picked up a profile by viewing the device again on the Autopilot Enrollment page.
6. Power on the device and select the language.
Once the profile status says assigned, and the assigned profile shows the value you want (e.g., UDeployment | Surface 1), power on the device and select the language.
7. Select the region.
Note: Just to demonstrate, the autopilot does not currently have network connectivity.
8. Choose the keyboard layout.
9. Choose the secondary layout.
10. Connect to the Wi-Fi.
11. Wait for the device to contact Intune. (The device will now contact Intune and do its stuff.)
12. Wait for the device to reboot.
13. Enter your tenant sign-in credentials.
14. Complete the Enrollment Status Page (ESP).
15. Log in to Windows.
The normal login screen will appear. Once logged into Windows there will probably be another progress screen before you are presented with the desktop. Most assigned applications should be installed and the hostname should follow the W-%SERIAL% format
If the deployment does fail, it can look like this:
Troubleshooting
If the deployment fails:
1. Return to Azure and ensure your device is assigned a profile via the targeted security group.
2. A factory reset (either via the Windows settings menu or the command line) will place the device back in a proper state for re-enrollment.
Factory reset (restore from recovery partition)
systemreset -factoryreset
To gather logs for further scrutiny:
1. Open a command prompt and run the mdmdiagnostictool.
2. To have permission to write the cab file, you'll need to specify a user folder for export.
3. Ship the .cab file to somewhere you can review it.
You'll need to specify a user folder for export to have permission to write the cab file.
Ship the .cab file off to somewhere where you can review it.
You can specify more in the -area parameter
Like this: "mdmdiagnosticstool.exe -area autopilot;deviceenrollment;deviceprovisioning;osconfiguration;tpm -cab C:\users\defaultuser0\file.cab"
Intune - Autopilot Logs
Autopilot Stages and Categorization of Logs
The Autopilot process has four primary phases:
-
Device Preparation (Setting up the device for Autopilot, checking TPM, downloading the deployment profile)
*Takes place after the Internet connection is secured and before Tenant login ESP Page
-
Device Preparation (finished but still shown on ESP page)
-
Device Setup (Applying the deployment profile and configuring the device)
-
Account Setup (Joining Azure AD, applying security policies, provisioning user-specific settings)
After ESP-locked apps
-
Post-Provisioning (Ongoing policy and app deployment via Intune)
Key Logs to Review for Each Phase:
Each phase corresponds to specific logs.
-
Device Preparation:
- dmpdownloader.log
- tpmdiagnostics.log
-
Device Setup:
- MDMSettingsHandler.log
- Setupact.log
-
Account Setup:
- MDMDiagnostics.etl
- AADDiagnostics.log
- UserDeviceRegistration.log
-
ESP-specific logs: EspProvisioning.log
-
Post-Provisioning:
- PolicyPlatform.log
- MDMSettingsHandler.log
There is also a PowerShell script that displays some autopilot diagnostics information.
Additional Commands you can use to show diagnostic information:
Show Azure AD status
dsregcmd /status
Leave Azure AD join:
dsregcmd /leave - once you do this, you can no longer sync on the client side; the option is gone from settings - account work or home
Factory reset (revert back to OOBE form recovery partition)
systemreset -factoryreset
Note: I have found this takes an extremely long time; it's actually faster to re-install Windows from scratch
Diagnose MDM enrollment failures | Microsoft Learn
-
Why Device Assignment Makes Sense for Autopilot:
- Autopilot operates pre-OS, where device properties (like serial numbers or hardware hashes) are used to match devices with deployment profiles.
- Deployment profile configurations are applied during the initial out-of-box experience (OOBE), and the device assignment ensures that the right configurations are applied to the correct hardware before any user logs in.
-
Why User Assignment May Not Work Well in Your Scenario:
- User assignment relies on the user logging in to trigger the profile application. This approach works better for user-based settings (e.g., app deployment or user-based policies) but not for Autopilot deployment profiles, which are hardware-specific.
Version 1.0 | Last Updated: January 24, 2025 | Author: Keith Franz, System Administrator III