3.2 Autopilot Modes, ESP, and Naming
Key Takeaways
- User-driven Autopilot is for devices primarily used by one person and supports Microsoft Entra join and hybrid Microsoft Entra join.
- Self-deploying Autopilot is for kiosks and shared devices, requires supported TPM attestation, and supports Microsoft Entra join only.
- Pre-provisioned Autopilot splits deployment into a technician flow and a user flow so required device work can complete before the user receives the device.
- The Enrollment Status Page can block desktop access until required apps and profiles complete, but blocking app design must avoid fragile dependencies.
- Autopilot naming templates apply differently by join type; hybrid scenarios rely on the Domain Join profile computer name prefix rather than the Microsoft Entra join name-template variables.
Autopilot mode selection
Windows Autopilot is not one deployment mode. It is a set of cloud-driven deployment scenarios that reuse the OEM Windows installation and enroll the device into management. On MD-102, the correct mode usually follows from the device ownership model, user interaction, join type, and whether IT wants to pre-stage the device.
| Mode | Best scenario | Join support | Key operational detail |
|---|---|---|---|
| User-driven | One primary user, direct shipment, minimal IT touch | Microsoft Entra join or hybrid Microsoft Entra join | User signs in during OOBE with organizational credentials |
| Pre-provisioned | IT, OEM, or reseller stages device before delivery | Microsoft Entra join or hybrid Microsoft Entra join | Technician flow completes device work, then device is resealed for the user |
| Self-deploying | Kiosk, shared, or no assigned user | Microsoft Entra join only | Requires supported TPM attestation and no user sign-in during deployment |
| Existing devices | Reinstall, repurpose, migrate, or use Configuration Manager task sequence | User-driven Entra join or hybrid join through JSON | Prepares an existing device for an Autopilot deployment |
| Autopilot Reset | Return a known Autopilot device to business-ready state | Existing Microsoft Entra joined devices | Keeps enrollment path cleaner for reassignment than full troubleshooting |
Microsoft recommends new cloud-native endpoints use Microsoft Entra join. Hybrid Microsoft Entra join can still appear in exam scenarios when on-premises Active Directory or legacy Group Policy remains required, but remote hybrid deployments need domain controller connectivity at the right point in the flow.
Enrollment Status Page behavior
The Enrollment Status Page (ESP) is the user-facing progress page during enrollment and first sign-in. It can show progress, block device use, enforce timeout behavior, allow log collection, and control what the user can do if installation fails.
ESP tracks three phases:
- Device preparation - enrollment and early setup work.
- Device setup - device-targeted apps, certificates, network profiles, and tracked policies.
- Account setup - user-targeted work after the user signs in.
Blocking is powerful but easy to overuse. If you set Block device use until all apps and profiles are installed to Yes, the user cannot reach the desktop until the tracked work completes or fails according to the configured behavior. You can choose All required apps or a selected blocking-app list. The selected list filters which already-assigned apps are blockers; it does not assign the apps by itself.
Operational ESP details that show up on MD-102:
- Device-targeted ESP profiles take precedence over user-targeted ESP profiles.
- In pre-provisioning and self-deploying scenarios, target ESP to devices because there may be no user context.
- If multiple ESP profiles apply, priority controls which profile wins.
- Blocking-app lists can contain up to 100 apps.
- Mixing line-of-business MSI apps and Win32 apps during ESP can create installer contention because both can use TrustedInstaller.
- Installing Windows quality updates during OOBE improves freshness but can add significant time and may require restarts.
Device naming
Autopilot naming belongs to the deployment profile or to the hybrid domain join path, depending on join type. For Microsoft Entra joined Autopilot devices, use the Autopilot deployment profile option to apply a device name template such as a serial-number or random-character pattern.
For hybrid Microsoft Entra join, naming is handled through the Domain Join configuration profile. That profile uses a computer name prefix and does not support the same variables used by the Microsoft Entra join device name template. If a question says the device name template field is unavailable in a hybrid profile, look for the Domain Join profile answer.
Assignment sequence to remember
A clean Autopilot deployment usually follows this order:
- Register the device with Autopilot or ensure the OEM/reseller did it.
- Place the device into the correct Microsoft Entra device group.
- Assign the Autopilot deployment profile to that device group.
- Assign ESP, required apps, compliance, security, and configuration policies.
- Verify device deployment status and policy installation after enrollment.
That order matters. An app in the ESP blocking list is not enough if the app is not also assigned as required to the user or device that will receive it.
A retail organization needs Windows kiosk devices to enroll without an end user signing in during deployment. The devices support TPM attestation and do not need hybrid join. Which Autopilot mode should be selected?
An admin adds an app to the ESP selected blocking-app list, but the app is not assigned as Required to the device or user. What happens?
A hybrid Microsoft Entra join Autopilot deployment needs computer names with a standard prefix. Which configuration should provide the name value?