3.2 Autopilot Modes, ESP, and Naming

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.

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, which is a frequent reason remote hybrid Autopilot fails. A key discriminator: self-deploying mode supports Microsoft Entra join only, so any scenario that pairs self-deploying with hybrid join is wrong.

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:

1. Device preparation - enrollment and early setup work.
2. Device setup - device-targeted apps, certificates, network profiles, and tracked policies.
3. 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 only filters which already-assigned apps are blockers; it does not assign the apps by itself. If you add an app to the blocking list but never assign it as required to that device or user, ESP simply will not track it.

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 example, a %SERIAL% or %RAND:x% variable).

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, the answer is the Domain Join profile with a computer name prefix.

Assignment sequence to remember

A clean Autopilot deployment usually follows this order:

1. Register the device with Autopilot or ensure the OEM/reseller did it.
2. Place the device into the correct Microsoft Entra device group.
3. Assign the Autopilot deployment profile to that device group.
4. Assign ESP, required apps, compliance, security, and configuration policies.
5. 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. The most common ESP failure is a blocking app that was never actually assigned, so the page either ignores it or, if the app genuinely fails, holds the user at the progress screen until the configured failure behavior releases them.

Pre-provisioned mode in depth

Pre-provisioned mode (formerly called white glove) deserves special attention because it splits the deployment into two flows. In the technician flow, IT, an OEM, or a reseller runs the device-targeted portion of setup, installs device-scoped apps and policies, and then reseals the device. In the user flow, the end user powers on the resealed device and completes only the lighter user-targeted work. The benefit is that time-consuming device setup finishes before the user ever sees the machine, so the user experience at first sign-in is fast.

Because there may be no user context during the technician flow, target the ESP and required apps to device groups for pre-provisioning, not user groups. A pre-provisioning scenario that assigns blocking apps only to users is a setup error the exam may ask you to spot.

Choosing a mode quickly

Use this shortcut. No user signs in and the device is a kiosk or shared with supported TPM attestation: self-deploying (Entra join only). One primary user, direct shipment, minimal IT touch: user-driven. IT wants to finish heavy device setup before handing over the device: pre-provisioned. An already-deployed device must be returned to a clean business-ready state for reuse: Autopilot Reset. An existing or reimaged device must be prepared for Autopilot through a configuration: Autopilot for existing devices.

Pair the mode with the join type the scenario requires, and reject any answer that pairs self-deploying with hybrid join, because self-deploying supports Microsoft Entra join only.