Microsoft MD-102: Windows Autopilot Deployment Modes

Windows Autopilot is easiest to learn for MD-102 as a deployment decision system. It uses the OEM-installed Windows image and cloud management to move an organization-owned device through identity, Intune enrollment, configuration, and application delivery without relying on a traditional custom-image build process. The important exam skill is choosing the right deployment mode and understanding what must already be true for the device to complete the journey.

Microsoft MD-102 tests Autopilot as part of a wider endpoint-administration role rather than as an isolated deployment wizard. The Microsoft 365 certifications show that role in context, while MD-102 in 2026 explains the move toward Intune, Entra, automation, and cloud-based endpoint operations.

Microsoft has published an MD-102 update effective October 27, 2026 that explicitly asks candidates to choose between Windows Autopilot deployment profiles and device preparation policies. Candidates testing under that version should use the revised study guide; the underlying architecture still depends on identity, enrollment, targeting, application delivery, and operational ownership.

Autopilot still depends on automatic Intune enrollment

Autopilot is not a substitute for the tenant’s identity and MDM configuration. Users or devices must be able to join the intended Microsoft Entra state and enroll in Intune. Licensing, MDM scope, network access, enrollment restrictions, and device registration all need to align. If those prerequisites are wrong, the deployment profile cannot compensate for them.

That means Autopilot troubleshooting should begin upstream. Confirm the device identity and assignment, then verify automatic enrollment and policy targeting before debugging individual applications. A device that never establishes the right management relationship will fail repeatedly regardless of how many times the out-of-box experience is restarted.

User-driven deployment fits assigned-user scenarios

User-driven Autopilot is appropriate when a specific employee receives the device and can authenticate during the out-of-box experience. The user establishes identity, the device joins the organization, and Intune begins applying profiles, policies, and apps. The experience works best when required configuration is intentionally limited so the user is not blocked for an excessive period.

The architecture should decide which settings truly have to complete before the desktop is usable. Loading every application into the initial blocking phase can make deployment fragile and slow. Less critical software can arrive after the user reaches the desktop if business requirements permit it.

Pre-provisioning moves work before user handoff

Pre-provisioning allows an administrator, reseller, or staging team to apply device-targeted configuration before the end user receives the endpoint. This can reduce first-login waiting time for large applications or policies. It also creates an operational process that needs clear ownership: who stages the device, how success is verified, and what happens when the pre-provisioned state becomes stale before delivery.

The mode is valuable when setup time or bandwidth at the user location is constrained, but it adds a staging step. Candidates should choose it because the deployment requirement justifies that step, not because pre-provisioning sounds more advanced.

Self-deploying mode fits userless and shared scenarios

Self-deploying designs can be useful for kiosks or shared devices where no individual user should drive enrollment. The identity and policy model must fit a device-centric scenario, and applications or controls that depend on one primary user need to be reconsidered. A shared endpoint is not simply a user-driven endpoint with the login screen removed.

Operations teams should also plan reset and reassignment behavior. Shared endpoints often have a different service lifecycle, and Autopilot should support restoring a known managed state without creating inconsistent ownership records.

The Enrollment Status Page is a control point

The Enrollment Status Page can block device use until selected device or user setup requirements are satisfied. That can protect the user from reaching a half-configured endpoint, but an overly broad blocking policy makes one slow or failed application look like a complete Autopilot failure. The strongest design keeps the blocking set small and business-critical.

Troubleshooting ESP failures requires identifying which phase is waiting and which app, policy, or profile owns the dependency. Changing the timeout without understanding the failed item can turn a visible deployment problem into an inconsistent device later.

Application packaging affects deployment reliability

Autopilot success depends on application deployment quality. Detection rules, dependencies, return codes, install context, network requirements, and reboot behavior can all influence the first-run experience. Large application chains should be tested on representative hardware and network conditions before they become mandatory for every new endpoint.

A useful deployment design separates foundational security and productivity requirements from software that can arrive after enrollment. This keeps the critical path observable and reduces the number of unrelated failures that can block a new device.

Naming and targeting should be predictable

Device naming templates, dynamic groups, enrollment-time grouping, and assignment filters can shape which configuration arrives during deployment. These controls are powerful but should be simple enough to explain. If a device can land in several overlapping dynamic groups with conflicting profiles, Autopilot becomes a policy-debugging problem rather than a deployment solution.

Test assignments with a small pilot group and verify the final set of policies before broad rollout. Predictable targeting is more valuable than an elaborate group structure that few administrators understand.

Autopilot does not eliminate lifecycle management

A successfully deployed endpoint still needs updates, compliance, application maintenance, security controls, inventory, support, and eventually retirement or reset. Autopilot improves provisioning, but it is one stage in the broader device lifecycle. Reuse or reassignment processes should cleanly remove stale ownership and return the device to an intended managed state.

Candidates should connect deployment choices to later operations. For example, a naming scheme that cannot survive reassignment or a profile that assumes one permanent user can create maintenance problems long after the initial setup appeared successful.

Device preparation is becoming part of the exam comparison

Microsoft’s October 27 study guide asks candidates to choose between Windows Autopilot deployment profiles and device preparation policies. That makes the reasoning more explicit: administrators need to know which provisioning model fits the deployment rather than memorizing one preferred path. Candidates testing under the revised blueprint should use the live study guide for exact wording.

The comparison should be made on prerequisites, targeting, identity, staging, application delivery, operational simplicity, and the desired user experience. Product evolution can change mechanics, but those decision criteria remain useful.

When an MD-102 scenario describes a new device, trace the workflow: device identity and registration, deployment mode, Entra join, automatic Intune enrollment, ESP behavior, configuration and application targeting, user handoff, and post-deployment management. A weak answer usually solves one visible step while ignoring a prerequisite or lifecycle consequence.

Autopilot is successful when a device reaches a known, supportable state with minimal manual intervention. The goal is not zero human involvement at any cost; it is a repeatable deployment whose failures can be diagnosed and whose results fit the organization’s endpoint operating model.

Network dependencies should be tested as part of Autopilot readiness. The out-of-box experience may need access to Microsoft identity, Intune, application content, certificate services, or organization-specific endpoints. Proxy authentication, SSL inspection, captive portals, or restricted branch egress can make a profile look broken when the real failure is connectivity. A deployment pilot should therefore include the network locations from which real users will provision devices.

Rollback planning starts before deployment. If a profile assignment, required app, or device-preparation rule blocks large numbers of machines, administrators need a safe way to pause assignments, correct the configuration, and recover affected endpoints. Emergency fixes should be controlled changes with clear ownership rather than ad-hoc instructions that leave devices in inconsistent states.

Hardware replacement and reuse are useful lifecycle tests for the design. A device may return from a departing user, require repair, or be reassigned to a different business unit. The Autopilot records, ownership data, group assignments, and user association should support that transition without inheriting stale configuration. A provisioning model that works only for the first owner is incomplete.

Deployment metrics can reveal where the experience is failing. Enrollment completion time, ESP failures, application installation delays, profile conflicts, and repeat resets help distinguish isolated user issues from systemic design problems. The purpose of measuring Autopilot is not to create another dashboard; it is to identify which part of the deployment path needs engineering attention.

Profile changes should be versioned operationally even when the service does not force a formal version number. Teams should know which profile, ESP settings, required apps, and assignment logic were active for a deployment wave. Without that record, a failure reported days later can be difficult to reproduce because the configuration may already have changed.

A production Autopilot design should also define exception handling. Some devices will arrive with unusual firmware, replacement components, network restrictions, or business-critical software that does not behave well during initial provisioning. Exceptions should be documented and temporary, with a clear route back to the standard build, rather than becoming an unofficial second deployment process.

Security controls should arrive early enough to protect the device without making provisioning impossible. Endpoint protection, identity, compliance, and baseline settings belong on the critical path when risk requires them, but their dependencies should be tested. A security policy that blocks the installer or network path needed to finish enrollment can create a circular failure if rollout order is not considered.

A final operational question is who owns failed deployments after the initial rollout team moves on. Help-desk staff need enough visibility to identify whether the failure sits in identity, enrollment, profile assignment, ESP, application installation, or network access. Escalation paths should identify which engineering team owns each failure class. That turns Autopilot from a project into a supportable service and prevents every provisioning issue from returning to the original implementation engineer.