Device enrollment is where a company’s endpoint strategy becomes real. Before a Windows laptop can receive compliance policies, applications and configuration, the organization must establish who owns it, how it joins the identity environment and which management authority will maintain it. An enrollment mistake can leave a device visible in an inventory but outside the controls administrators assumed were active. For candidates preparing for Microsoft MD-102, the important skill is selecting an enrollment method that fits the device’s ownership, platform and lifecycle, then proving that management actually succeeded.
Microsoft’s MD-102 objectives updated on July 24, 2026 emphasize enrollment settings, Windows automatic enrollment, Autopilot choices, personal-device enrollment across platforms, and integration with corporate provisioning programs. That breadth can make the subject feel like a catalog of wizards. A more useful approach is to trace an endpoint from purchase or user registration through identity join, enrollment, configuration and retirement. A corporate Windows notebook, an employee’s personal phone and a shared Android kiosk have different trust and support models. They should not be forced through one deployment pattern just to reduce the number of policy groups.
Choose enrollment by ownership and platform
For corporate Windows devices, Windows Autopilot supports provisioning through the existing OEM Windows installation rather than a custom image for every machine. It relies on the organization registering the device and setting appropriate deployment behavior, including automatic Intune enrollment. This can simplify remote delivery, but the prerequisites matter: the device must be correctly associated with the organization, the user must be eligible and the deployment profile must match the scenario. A help desk should not assume that every login automatically proves a company device is managed.
Windows automatic enrollment can link eligible Entra-joined or registered experiences to Intune management, depending on tenant configuration and licensing. Administrators should understand the MDM user scope, join state and enrollment restrictions. A personally owned Windows device may need a less intrusive management approach, while an organization-owned shared device may require deployment modes and sign-in behavior that do not depend on one permanent user. The distinction between registering a device and joining it is essential. Registration supports an identity relationship; management requires the applicable enrollment and policy processes to complete.
Other platforms introduce their own mechanisms. Corporate Apple devices can use Apple Business Manager integration and automated device enrollment. Personal iOS, iPadOS and macOS enrollment should reflect employee privacy expectations and organization policy. Android Enterprise offers work-profile, fully managed, dedicated and corporate-owned work-profile scenarios; choosing the wrong one changes what IT can control and what personal information should remain outside its scope. Programs such as Android zero-touch or Samsung Knox Mobile Enrollment help connect provisioning to corporate ownership but still require appropriate management profiles and assignments.
Prepare the tenant before shipping devices
A sound rollout begins with identity, licensing and authority checks. Confirm which users and devices are eligible for Intune, which platforms are supported and whether another MDM system is already managing a device. Review restrictions for personal ownership, device limits, operating system versions and enrollment types. Define how group membership controls policy delivery and which enrollment profiles apply to pilot users. A misplaced exclusion or contradictory configuration can turn a working demonstration into a widespread support problem.
Administrators should also decide where policy will be staged. A new notebook that receives a restrictive security profile before its required connectivity configuration may never complete provisioning. A security rule that blocks the management service’s endpoints can trap the device in a partially configured state. Sequence network access, certificates, app dependencies and endpoint protections so the device can contact its identity and management services. Use documented endpoints and supported dependencies instead of temporarily allowing unrestricted access without a closure plan.
Ownership and asset inventory must match. A device marked corporate in an enrollment platform but personally owned in practice creates privacy and support concerns. Conversely, a corporate asset misidentified as personal may escape security requirements. Keep a reliable inventory tying serial or hardware identity to purchase records, assigned staff and retirement status. Link that information to provisioning controls without copying sensitive personally identifiable information into unnecessary logs. The MD-102 certification path provides broader context for endpoint administrators, but enrollment needs its own operational acceptance criteria.
Understand the Autopilot experience and its failure points
Autopilot deployment choices depend on who starts setup and what device will become. User-driven deployment fits many assigned laptops; self-deploying scenarios are relevant to appropriate shared or kiosk devices; pre-provisioning can shift some preparation to an earlier stage. Windows Autopilot device preparation introduces another approach with its own prerequisites and policy experience. Rather than memorizing labels, determine when a user is available, whether the device is assigned, which identity state is required and who can recover a failed setup.
The Enrollment Status Page can control what users see while applications and policies install. A useful configuration identifies genuinely essential apps and profiles, rather than treating every optional utility as a blocking dependency. If a line-of-business app’s installer hangs, holding the entire enrollment process can strand the user. Define timeout and retry behavior, monitor failures and keep an approved recovery path. A device that reaches the desktop is not necessarily healthy; verify configuration delivery, required software, protection and compliance after sign-in.
Troubleshooting should distinguish registration, identity join, enrollment and post-enrollment assignment. A device may appear in the Autopilot list but never enroll; it may enroll but not receive a policy because of a group mismatch; it may receive a policy but remain noncompliant because a requirement is unmet. Collect deployment state, device diagnostics, service-side errors and relevant timestamps before resetting hardware repeatedly. A full wipe can destroy useful evidence and consume hours while leaving the tenant-side problem untouched.
Handle BYOD without disguising the tradeoffs
Bring-your-own-device programs need explicit boundaries between corporate information and employee ownership. Users should know what the organization can manage, what administrators can view and what happens when employment ends. A program that demands full device management for access to one web application may not fit the business’s privacy commitments. Application protection and other access controls can sometimes reduce the need for extensive device authority, depending on the data and platform. That is a governance choice, not just a convenience feature.
Corporate data should be separable from personal data where the platform and enrollment method support it. Android work profiles, for example, are designed to maintain a work boundary within a personal or corporate-owned device according to configuration. Apple enrollment models provide different levels of organization control. A remote retirement process should be designed to remove authorized corporate access or data without unexpectedly destroying personal content. Test the actual departure experience with representative devices rather than relying on a product description.
Cross-platform support increases complexity. Device restrictions, OS versions, privacy settings and user consent can affect whether security signals are available to Intune. A policy that is meaningful on a fully managed Windows endpoint may not map directly to personal iOS. Design platform-specific assurance requirements and then align them to business access tiers. For sensitive roles, the organization might require a corporate-managed device rather than pretending every personal-device enrollment mode can satisfy identical control objectives.
Corporate enrollment programs also require support for exceptional transitions. A laptop might be shipped to a staff member in a country with restricted network reachability; another may be returned before the first user ever signs in. Autopilot registration and ownership records should follow the actual asset, not just the originally planned recipient. Reassignment policies need to specify whether the device should be wiped, whether old certificates remain valid and how inventory updates reach deployment administrators. Poorly handled exceptions can create orphaned records that appear healthy in one console but block provisioning in another.
Verify management and compliance after enrollment
Enrollment success should be a measurable condition. Check that the device has the expected identity, ownership and management state, is targeted by required profiles, reports protection signals and can receive remote administrative actions permitted by policy. Review discrepancies between inventory and actual check-in. A record can remain after a device has been retired, or an active device may go silent because its management certificate expired or connectivity changed. Set alerting and escalation based on business importance rather than collecting device counts for a dashboard.
Do not conflate enrollment with compliance. An enrolled computer can fail disk encryption, OS version or security configuration requirements. Compliance policies evaluate those signals; Microsoft Entra Conditional Access can use the resulting status to decide whether access is granted. The distinction becomes central when users report that sign-in succeeds but a resource remains blocked. Resolve the failing control instead of disabling an entire Conditional Access policy. A managed but noncompliant device is a useful security state, not proof that enrollment failed.
Device retirement completes the lifecycle. Document how to remove assignments, revoke certificates and tokens, wipe or retire corporate devices as authorized, and update inventory and Autopilot records where appropriate. Reassignment needs its own process; handing a laptop to the next employee without correctly resetting identities and local data can cross privacy boundaries. Your runbook should account for lost devices, damaged hardware, employees who never return devices and machines that cannot contact the service to receive their final command.
The most useful MD-102 enrollment study method is to begin every scenario with four questions: Who owns the device? Which operating system and join state does it use? Who performs provisioning? What evidence shows the device is both enrolled and receiving policy? These questions lead to the correct enrollment choice more reliably than memorizing one set of console screens, and they translate directly into fewer endpoint deployment surprises.