MD-102: Intune Enrollment and Windows Autopilot

A company orders five hundred Windows laptops for remote employees. Some arrive through a reseller, others are replacement machines already in use, and a small group will become shared devices in branch offices. The organization wants consistent configuration, but sending every machine to headquarters for imaging would defeat the purpose of cloud management. The difficult part is choosing the right registration, identity, enrollment, and provisioning path for each device. Those distinctions are central to MD-102 and to a successful Microsoft Intune rollout.

The exam’s endpoint-infrastructure objectives encompass Microsoft Entra device join and registration, Windows automatic enrollment, Windows Autopilot, Apple and Android corporate enrollment, group targeting, and enrollment failure investigation. The technologies are connected but not synonymous. A deployment profile does not create a device identity by magic; an identity record does not prove that MDM enrollment succeeded; and a managed endpoint is not necessarily ready for its user. Following the sequence makes troubleshooting much more reliable than memorizing portal locations.

Model registration, join, and enrollment as different events

An identity tenant must know enough about a device to apply the correct controls, but the relationship differs between registration, Entra join, and hybrid join. Entra-registered devices often support bring-your-own-device access scenarios without making the device equivalent to a corporate Windows workstation. Entra-joined devices use the cloud identity platform as their primary join arrangement. Hybrid-joined devices retain a relationship with on-premises Active Directory while also appearing in Entra ID. Each choice affects prerequisites, sign-in behavior, policies, and the operational burden the organization must maintain.

Enrollment adds the management channel. An organization may establish automatic Intune enrollment for supported Windows join flows, but the administrator must still confirm MDM user scope, licensing, enrollment restrictions, platform eligibility, and device assignment. Troubleshooting a machine that appears in Entra ID but not in Intune therefore starts by checking the step that did not finish. Was its join state recorded but MDM enrollment not initiated? Was the user outside the configured scope? Was an enrollment restriction triggered? The article on Microsoft Entra ID terminology can help readers distinguish current product names from older Azure AD instructions encountered in legacy documentation.

Choose the Autopilot experience for the real handoff

Windows Autopilot uses the existing supported Windows installation and a defined deployment experience rather than requiring administrators to apply a traditional custom image to every new device. In user-driven mode, an employee completes parts of the initial experience, including organizational sign-in, while the device obtains its management configuration. A hardware vendor may register eligible devices, reducing internal handling. Successful deployment still depends on correct profile assignment, identity access, connectivity, and the device meeting the mode’s requirements. User-driven Autopilot is appropriate when a human user is expected to own the first interactive sign-in.

Pre-provisioned deployment splits preparation into a technician phase and a later user phase. That can shorten the time an employee waits for required device-targeted applications and policies, but it introduces a staging process and additional preparation assumptions. Self-deploying mode targets scenarios with minimal user interaction, such as certain shared devices, and has different identity and hardware requirements; it is not just user-driven mode with fewer screens. A sound design first asks who performs the handoff, whether the device is personal or shared, which apps must be present at first sign-in, and whether a technician or reseller can reliably prepare it. Only then should the mode be selected.

Distinguish Autopilot deployment profiles from device preparation

Microsoft’s newer Windows Autopilot device preparation approach and traditional Autopilot deployment profiles have overlapping goals but different mechanisms, prerequisites, and administration experiences. Device preparation is particularly relevant to eligible user-driven Microsoft Entra join scenarios and uses defined policies for essential applications and scripts. Traditional registered-device profiles cover other supported deployment scenarios and include the familiar provisioning paths. Treat them as options to evaluate against a supported scenario rather than interchangeable settings. For a shared kiosk, the user-driven device preparation path may not satisfy the intended deployment experience; for a new personal-assigned Windows laptop, it may be worth evaluating alongside a traditional user-driven profile.

Do not combine a deployment workflow’s limits or requirements from one approach with another. For example, the number of essential apps and scripts configured during device preparation and the behavior of the traditional Enrollment Status Page belong to their respective workflows. Instead of remembering an isolated number, identify which workflow creates the configuration, what is expected to complete during out-of-box setup, and what continues afterward. A pilot should capture the device registration state, deployment method, assigned policies, elapsed time to first use, and any late-arriving applications. That evidence tells you whether the chosen approach meets the organization’s service target.

Give the Enrollment Status Page a deliberate purpose

The Enrollment Status Page (ESP) is useful because it can make defined provisioning stages visible while critical device and user setup runs. Used without care, it can also prolong onboarding when an application has a broken install command, unreliable detection logic, or an unreachable dependency. Decide which apps and policies are genuinely blocking prerequisites before requiring them for a first usable desktop. A company that makes every optional collaboration tool a setup blocker may increase support calls without improving readiness. Conversely, allowing a finance machine to reach sensitive resources before required protection is in place can create a real control gap.

When a user reports that setup is stuck, ask which phase is waiting. Device-targeted requirements and user-targeted requirements behave differently, especially in pre-provisioned scenarios. Investigate assignment status, network access, app dependencies, Intune Management Extension diagnostics where relevant, and enrollment logs rather than factory-resetting as the first response. If ten machines from one reseller fail while devices from another work, include hardware registration and procurement data in the diagnosis. A good support playbook identifies the failing boundary and records a repeatable correction that can be applied before the next shipment.

Design Apple and Android enrollment separately

Corporate Apple devices can use Apple Business Manager integration and Automated Device Enrollment, supporting an organization-controlled onboarding process. Personal Apple enrollment demands different privacy assumptions and supported management options. Android Enterprise distinguishes personally owned work profiles, corporate-owned work profiles, fully managed devices, and dedicated devices; different ownership relationships produce different controls and user experiences. Samsung Knox Mobile Enrollment and Android zero-touch enrollment can be relevant on supported corporate devices, but neither should be presented as a universal Android enrollment requirement.

The crucial exercise is matching use cases to enrollment outcomes. A personal mobile phone requiring work email may need protected app data without full corporate control. A warehouse handheld with a single scanning app may be enrolled as a dedicated corporate device. A company-owned phone used for work and permitted personal activity could need a corporate-owned work-profile arrangement. For Apple, the technical relationship between the device reseller, the organization’s Apple Business Manager assignment, and Intune can be explored through Automated Device Enrollment. Do not transfer assumptions from the Windows join model directly onto mobile-device ownership models.

Plan groups, licensing, and administration before rollout

Group assignments and filters decide which devices receive enrollment profiles and what follows after onboarding. Dynamic device groups can reduce manual processing, but their rules must use reliable properties; a mislabeled procurement batch can route devices into the wrong deployment experience. Establish a small and understandable group taxonomy. Separate stable identity facts from temporary rollout cohorts, and record who owns the membership logic. Where multi-admin environments are involved, Intune scope tags and role assignments constrain administrative visibility and capability, not the underlying enrollment eligibility of every device.

Licensing and service readiness are part of the same preparation. The exact subscription requirements depend on products and features used, especially paid Intune Suite add-ons. An Enrollment Status Page that works in a pilot may fail in another tenant because the targeted users lack a necessary service entitlement, an enrollment restriction differs, or a Conditional Access policy interrupts the flow. Test with ordinary users rather than only privileged administrators, since admin accounts often bypass conditions that affect the real workforce. When an enrollment problem is actually a sign-in policy issue, the broader SC-300 identity and access scope can clarify the identity boundary without replacing MD-102’s device-lifecycle emphasis.

Diagnose failures by tracing the sequence

Use a simple dependency chain: device eligibility and registration, profile assignment, identity and network access, join or registration outcome, MDM enrollment, initial policy arrival, application installation, compliance evaluation, and user access. An error at one stage may be visible much later. For instance, a missing Autopilot assignment can cause an unexpected consumer-like setup experience; a network-proxy restriction might prevent the enrollment channel from reaching its required endpoints; and an app that takes too long to install can look like a generic deployment failure. Record the earliest confirmed successful stage instead of working backward from the most alarming final symptom.

Create an incident note for each failed pilot with the device serial or record identifier, intended enrollment mode, expected group membership, observed join status, deployment timestamp, exact failure phase, relevant diagnostic messages, and the remedy tested. Avoid leaving sensitive enrollment information in informal messages or shared screenshots. Then change only one variable for the next pilot machine if feasible. Resetting and retrying with multiple simultaneous changes makes it harder to distinguish the actual fix from coincidence. Deliberate logging prevents a rollout from becoming a collection of undocumented one-off fixes.

Close the loop with reassignment and retirement

Deployment architecture must account for the day a user leaves or a device is lost. Retire, wipe, reset, and delete are different operations with different consequences. A personally owned phone requiring organizational data removal is not an appropriate target for every corporate-device action. A recycled corporate laptop must have its identity, management record, encryption recovery arrangements, and future deployment state handled in a coordinated way. Devices that will be redeployed through Autopilot may require carefully staged cleanup rather than an indiscriminate deletion of every directory and management object.

Test the full lifecycle in a pilot: unbox and deploy, rotate the assigned user where appropriate, lose network connectivity, enforce a changed baseline, recover from a failed install, and retire or reset the endpoint. Write down which records remain after each operation and who can authorize destructive remote actions. That operational picture is the real skill behind enrollment questions. MD-102 candidates who understand why each stage exists can usually identify the right next step even when an exam scenario describes an unfamiliar device population or changes the order in which the symptoms appear.