{"id":3264,"date":"2026-10-08T12:10:37","date_gmt":"2026-10-08T12:10:37","guid":{"rendered":"https:\/\/www.examtopics.biz\/blog\/microsoft-md-102-autopilot-profiles-vs-device-preparation\/"},"modified":"2026-10-17T11:36:35","modified_gmt":"2026-10-17T11:36:35","slug":"microsoft-md-102-autopilot-profiles-vs-device-preparation","status":"publish","type":"post","link":"https:\/\/www.examtopics.biz\/blog\/microsoft-md-102-autopilot-profiles-vs-device-preparation\/","title":{"rendered":"Microsoft MD-102: Windows Autopilot Deployment Profiles vs Device Preparation"},"content":{"rendered":"

Microsoft now has two cloud-based provisioning approaches that sound similar but have different operating models: classic Windows Autopilot deployment profiles and Windows Autopilot Device Preparation. The current MD-102<\/a> guide explicitly asks candidates to choose between them and then choose among classic Autopilot modes such as user-driven, pre-provisioned, and self-deploying.<\/p>\n

Device Preparation is not simply a new name for every Autopilot scenario. Current Microsoft guidance shows that Device Preparation supports a simplified Windows 11, Microsoft Entra join model for user-driven physical devices plus newer automatic Windows 365 scenarios, while classic Autopilot still provides pre-provisioning, self-deploying, existing-device, reset, and Microsoft Entra hybrid join options. The correct choice depends on how much pre-staging, customization, device registration, and unattended deployment the organization requires.<\/p>\n

Classic Autopilot uses registered devices and deployment profiles<\/h2>\n

Traditional Windows Autopilot normally begins with devices registered in the Autopilot service, often by an OEM or reseller or through an import process. Administrators assign deployment profiles and Enrollment Status Page behavior to groups so the out-of-box experience can join the device, enroll it into Intune, and apply policies and applications.<\/p>\n

This model provides broad scenario coverage and detailed OOBE customization. Registered-device identity also enables organizations to target profiles before a user ever signs in. That is useful for device-specific deployment control, but it creates lifecycle work around registration, ownership changes, hardware replacement, and stale Autopilot records. The tradeoff is more setup around device registration, group targeting, profile assignment, and scenario-specific prerequisites.<\/p>\n

Device Preparation simplifies user-driven provisioning<\/h2>\n

Windows Autopilot Device Preparation is designed for a simpler user-driven Microsoft Entra join experience on Windows 11. Devices do not need the same pre-registration process used by classic Autopilot. Administrators configure a Device Preparation policy and an Intune device security group used during provisioning.<\/p>\n

Only device-targeted configuration is delivered during the Device Preparation OOBE. Microsoft recommends putting security policy and essential applications into that device-focused phase and allowing less critical user software to arrive after enrollment. This reduces the number of OOBE dependencies that can block a user from reaching the desktop. Current comparison guidance allows up to 25 essential applications and up to 10 PowerShell scripts in the Device Preparation policy. This is intentionally bounded to improve provisioning reliability and get the user productive faster.<\/p>\n

User-driven classic Autopilot remains flexible<\/h3>\n

Classic Autopilot user-driven mode is designed for a device assigned to one user. The user receives the device, connects it to the internet, signs in with organizational credentials, and the device completes Entra join or supported hybrid-join behavior plus Intune enrollment.<\/p>\n

Use this mode when the user can complete OOBE and the organization needs classic Autopilot capabilities such as registered devices, richer profile behavior, user-targeted Enrollment Status Page processing, or Microsoft Entra hybrid join. Measure user setup time separately from total provisioning time because the device can spend a large portion of OOBE waiting for required apps and policies.<\/p>\n

Pre-provisioning moves device work to IT or the supplier<\/h2>\n

Pre-provisioned Autopilot splits deployment into a technician phase and a user phase. IT, an OEM, or a reseller applies device-targeted policies and applications before the device reaches the employee. The device is resealed, then the user completes the remaining identity and user-targeted steps.<\/p>\n

This improves first-login time for heavily managed single-user devices. It also transfers operational responsibility to the technician or supplier performing the first phase. Standardize how devices are validated before reseal, and confirm that assigned profiles, critical device apps, certificates, and security policy are complete before shipping. It requires supported TPM 2.0 attestation and a physical-device workflow. Current Microsoft guidance recommends cloud-native Microsoft Entra join for new devices rather than designing new hybrid-join dependencies where they are not necessary.<\/p>\n

Self-deploying mode fits kiosks and shared devices<\/h2>\n

Classic Autopilot self-deploying mode minimizes user interaction and does not assign a user during provisioning. It is designed for scenarios such as kiosks, digital signage, and shared devices. The device joins Microsoft Entra ID and enrolls in Intune using hardware-based trust.<\/p>\n

Self-deploying mode requires TPM 2.0 and device attestation and is intended for physical devices. Network availability matters because the device must reach Microsoft services during OOBE without a user troubleshooting complex authentication or proxy issues. Kiosk deployment should therefore include wired or well-controlled wireless connectivity whenever possible. Because there is no assigned user during OOBE, the application and policy design should be device-centric. Do not choose it for a normal one-user laptop merely because hands-off deployment sounds attractive.<\/p>\n

Device Preparation does not currently replace every classic mode<\/h2>\n

Microsoft\u2019s current comparison guidance is explicit: Device Preparation supports user-driven deployment and newer automatic Windows 365<\/a>-related scenarios, but classic pre-provisioned and self-deploying modes remain part of Windows Autopilot. Device Preparation also differs in Windows version support and uses Microsoft Entra join rather than the classic hybrid-join scenario.<\/p>\n

This matters for migration planning. An organization cannot simply convert every deployment profile to Device Preparation and expect identical behavior. Inventory the existing scenarios first, especially pre-provisioned devices, shared kiosks, hybrid join, reset workflows, and applications that depend on classic ESP behavior.<\/p>\n

Application targeting differs between the approaches<\/h2>\n

Device Preparation delivers a limited set of essential applications and scripts during OOBE and expects additional software to arrive after the desktop becomes available. Use that limit to force prioritization: endpoint protection, certificates, required connectivity, and the applications needed for first-day work belong earlier than large optional packages or software users can receive later. Microsoft positions this as a reliability improvement and supports both Win32 and line-of-business applications in the Device Preparation flow.<\/p>\n

Classic Autopilot can deliver a larger application set and has separate device and user ESP phases depending on the scenario. Heavy OOBE application targeting can lengthen provisioning and increase failure risk, so even classic profiles should limit setup to what users genuinely need before first productivity.<\/p>\n

Troubleshooting starts with enrollment stage and dependency<\/h2>\n

Provisioning failures can come from assignment, licensing, network reachability, device registration, TPM attestation, application install, script execution, Enrollment Status Page, or Intune enrollment. Capture timestamps and the phase in which failure occurs so help-desk teams do not start by wiping the device. Repeated resets can hide a consistent policy or application defect. The troubleshooting path should first identify which provisioning model and stage is active.<\/p>\n

Collect device diagnostics before repeated resets erase useful evidence. For classic Autopilot, verify the registered device, assigned profile, group membership, ESP, and app targeting. For Device Preparation, verify the policy, security group ownership, device eligibility, and the bounded set of essential apps and scripts.<\/p>\n

Choose the provisioning model from the device scenario<\/h2>\n

Use Device Preparation when the organization wants a simpler Windows 11, Entra-joined, user-driven provisioning path with bounded essential setup and no classic device-registration requirement. Use classic user-driven Autopilot when broader customization or hybrid join is required. Use pre-provisioning when IT should perform the expensive device phase before delivery, and self-deploying for shared or kiosk devices.<\/p>\n

Standardize a small number of approved profiles or policies rather than creating one per team. Track provisioning success rate, median OOBE duration, application failure, and manual intervention by deployment model. Those metrics show whether a simpler Device Preparation path is actually improving reliability or whether the organization still depends on classic Autopilot capabilities. Document prerequisites, ownership, application limits, recovery steps, and success metrics such as provisioning time and failure rate. Modern provisioning becomes easier to operate when each scenario has a clear purpose instead of being chosen by familiarity.<\/p>\n

For migration, pilot both models with the same hardware class and a representative application set. Measure enrollment success, technician effort, user OOBE time, required resets, application failures, and help-desk contacts. Device Preparation can simplify a cloud-native Windows 11 fleet, but organizations with pre-provisioning, kiosk, hybrid-join, or existing-device workflows may continue using classic Autopilot for those cases. A mixed strategy is valid when each deployment path has a documented purpose and support model.<\/p>\n

Keep the deployment decision separate from the application-management strategy after enrollment. Autopilot gets the device through OOBE; Intune still owns ongoing configuration, updates, compliance, applications, security baselines, and support. A successful provisioning design should therefore hand the device into a predictable steady-state management model, with naming, grouping, update rings, compliance policy, and ownership already established.<\/p>\n

Device identity cleanup is also part of provisioning quality. Remove stale Autopilot registrations, retired Intune records, duplicate Entra device objects, and abandoned group assignments when hardware is replaced or redeployed. Old records can cause confusing profile targeting and ownership behavior, especially when devices move between users, business units, or deployment models.<\/p>\n

Keep a tested wipe-and-retry path for failed deployments so support teams can recover devices without manual reimaging whenever the scenario supports reset. Document when a device record must be deleted or reassigned before the next attempt.<\/p>\n

Keep the support workflow simple enough that first-line teams can identify the active provisioning model immediately.<\/p>\n

The choice should also reflect lifecycle after OOBE. Autopilot or Device Preparation gets the device enrolled, but Intune still owns updates, compliance, security baselines, application delivery, Defender configuration, and steady-state support. Define the post-provisioning group, filters, update ring, compliance policies, and application assignments before rollout so successfully provisioned devices do not land in an inconsistent management state.<\/p>\n

For classic pre-provisioning, monitor the technician phase separately from the user phase. A failure before reseal points to device-targeted policy, app, TPM, network, or registration problems; a failure after delivery may involve user-targeted policy or identity. Device Preparation has a deliberately bounded OOBE payload, so its troubleshooting should focus on the essential device apps and scripts selected in the preparation policy rather than the much larger set of applications assigned for later installation.<\/p>\n

Pilot both provisioning approaches with the same hardware class and representative applications. Track enrollment success, OOBE duration, technician effort, application failures, resets, and help-desk contacts. Clean up stale Autopilot registrations, Entra device objects, and Intune records when hardware is replaced or reassigned. A mixed deployment strategy is acceptable when each path has a documented purpose\u2014cloud-native user-driven Device Preparation, classic pre-provisioning, kiosks, or hybrid scenarios\u2014rather than one team choosing a different method by habit.<\/p>\n","protected":false},"excerpt":{"rendered":"

Microsoft now has two cloud-based provisioning approaches that sound similar but have different operating models: classic Windows Autopilot deployment profiles and Windows Autopilot Device Preparation. […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[29,134,47,36],"tags":[],"class_list":["post-3264","post","type-post","status-publish","format-standard","hentry","category-certifications","category-exam-md-102","category-microsoft-certifications","category-systems-infrastructure"],"_links":{"self":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts\/3264","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/comments?post=3264"}],"version-history":[{"count":2,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts\/3264\/revisions"}],"predecessor-version":[{"id":4736,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts\/3264\/revisions\/4736"}],"wp:attachment":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/media?parent=3264"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/categories?post=3264"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/tags?post=3264"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}