Windows Autopilot Device Preparation v2: Step-by-Step Setup in Microsoft Intune

• Confirm Windows edition and version: the device must be running a supported Windows 11 edition (for example, Pro or Enterprise) and meet the minimum version/update requirements.
• Confirm licensing: ensure users who will enroll devices have the required Microsoft Entra ID + Intune capabilities through an eligible subscription (for example, Microsoft 365 Business Premium, M365 E3/E5, EMS E3/E5, or Entra ID P1/P2 + Intune).
• Confirm automatic MDM enrollment is configured for the target users in your tenant.
• Confirm users targeted by the pilot have permission to join devices to Microsoft Entra ID.
• Confirm outbound connectivity for core services (at minimum HTTP/HTTPS and NTP). Ensure UDP 123 to time.windows.com is reachable.
• If you use proxies or restrictive egress controls, review Intune and Autopilot networking requirements and allow the documented endpoints.

Verification Commands

Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber
Test-NetConnection -ComputerName time.windows.com -Port 123

Verification Checklist

• Windows 11 version/build meets your target baseline (24H2+ recommended).
• A pilot user can complete Entra sign-in and Intune auto-enrollment in a controlled test.

Common Errors

• Using an unsupported Windows version/build (Device Preparation won't start).
• Blocking UDP 123 (time sync issues can break sign-in and enrollment).
• Missing licenses for users (enrollment fails or policies won't apply).

• In Microsoft Entra ID (or Intune group management), create a Security group named DP_Users_Pilot (or your naming convention).
• Use Assigned membership for your initial pilot and add a small set of test users (5--10 is a practical start).
• Document the group purpose clearly (pilot scope, support contact, rollback plan).

Verification Checklist

• Pilot users are visible as members of DP_Users_Pilot.
• You can reference this group during policy assignment in Intune.

Rollback Procedure

Remove users from the group to stop targeting them with the policy.

Common Errors

• Targeting the wrong group type (for example, Microsoft 365 group instead of Security group).
• Over-scoping the pilot group (too many users too early).

• Create a Security group named DP_Devices_Pilot using Assigned membership.
• Leave the group empty initially. Devices will be added during enrollment via enrollment time grouping.
• Open the group and add the service principal named Intune Provisioning Client as an Owner (in some tenants it may appear with a different display name, but the AppID must match the documented value).
• Confirm ownership is saved before proceeding---this is a common reason policies fail to save or devices fail to group during enrollment.

Verification Commands

`Connect-MgGraph  -Scopes "Directory.Read.All"  Get-MgGroupOwner  -GroupId "<GROUP_ID>"  |  Select-Object DisplayName, Id `

Verification Checklist

• Intune Provisioning Client appears under group Owners.
• The Device Preparation policy wizard allows selecting the device group without errors.

Rollback Procedure

• Remove the owner if you no longer use enrollment time grouping for this group.
• Replace the group with a new dedicated DP device group (recommended instead of repurposing unrelated groups).

Common Errors

• Forgetting to add Intune Provisioning Client as owner (devices won't be added during enrollment).
• Adding users/devices manually and later losing track of what was added by enrollment time grouping.

• List apps required before the user can start work (for example: Microsoft 365 Apps, Teams, Company Portal, VPN agent, core security agent).
• Limit OOBE to essentials because Device Preparation supports up to 10 managed apps and up to 10 PowerShell scripts during OOBE.
• Ensure each selected app is compatible with installation during OOBE (no interactive prompts).
• For Win32 apps, confirm they can install in System context because no user is signed in during OOBE.
• For PowerShell scripts, ensure they run in System context (do not use logged-on credentials).

Verification Checklist

• Your selected OOBE apps count is 10 or fewer.
• Your selected OOBE scripts count is 10 or fewer.

Rollback Procedure

Move non-essential apps/scripts to post-OOBE assignment (device group or standard app deployment).

Common Errors

• Including too many apps (exceeds limits; OOBE tracking/install will not behave as expected).
• Selecting apps that require user interaction or cannot install in System context.

• For each required application, assign it as Required to DP_Devices_Pilot.
• For Win32 apps, validate installation behavior supports System context installation during OOBE.
• For Microsoft Store apps, confirm the app type is supported for Device Preparation (Store apps must support WinGet).
• For PowerShell scripts intended to run during OOBE, assign them to DP_Devices_Pilot and set them to run as System (not using logged-on credentials).

Verification Checklist

• Each OOBE app shows an assignment to DP_Devices_Pilot as Required.
• Each OOBE script shows an assignment to DP_Devices_Pilot and is configured to run as System.

Rollback Procedure

Remove the DP_Devices_Pilot Required assignment and reassign the app/script post-OOBE.

Common Errors

• Assigning apps to the user group instead of the device group (apps won't install in the Device Preparation flow).
• Store apps that don't support WinGet (unsupported during Device Preparation).

• Go to Intune admin center → Devices → Windows → Windows enrollment → Device preparation policies → Create.
• Set Deployment mode to User-driven and Join type to Microsoft Entra joined.
• Select DP_Devices_Pilot as the Device group.
• Configure User account type (Standard User is recommended for least privilege).
• Set the allowed minutes before failing the deployment (this is the overall deployment window, not per-app).
• In Apps, select up to 10 essential applications to be tracked/installed during OOBE (these apps must already be assigned to DP_Devices_Pilot).
• In Scripts, select up to 10 essential PowerShell scripts to be tracked/run during OOBE (these scripts must already be assigned to DP_Devices_Pilot).
• In Assignments, target your DP_Users_Pilot user group (Required).
• Save the policy and note its priority if multiple policies exist.

Verification Checklist

• Policy is created without errors and shows DP_Devices_Pilot as the device group.
• DP_Users_Pilot is listed in Assignments as Required.
• Apps/Scripts are listed under Allowed and match your planned essentials.

Rollback Procedure

• Unassign DP_Users_Pilot from the policy to stop new enrollments from using it.
• Delete the policy after unassignment if you are decommissioning the pilot.

Common Errors

• Device group selection fails or won't save when Intune Provisioning Client isn't an owner of the device group.
• Selecting apps in the policy that are not assigned to the device group (they won't install as expected).

• If you plan to block personal Windows enrollments, create or update Enrollment restrictions (Device platform restrictions) accordingly.
• If personal enrollments are blocked, upload Corporate device identifiers for your corporate fleet so eligible devices can enroll successfully.
• Prepare a CSV using manufacturer, model, and serial number values for devices you want to allow.

Verification Commands

wmic csproduct get vendor,name,identifyingnumber

Verification Checklist

• Enrollment restriction policy applies to your test users.
• A test corporate device is recognized as corporate and can proceed through OOBE.

Rollback Procedure

• Relax or remove enrollment restrictions if you need to permit additional scenarios temporarily.
• Remove uploaded corporate identifiers if they were added incorrectly (and re-upload corrected values).

Common Errors

• Blocking personal devices without uploading corporate identifiers (corporate devices may be treated as personal and fail enrollment).
• Incorrect CSV formatting or mismatched serial numbers.

• Use a brand-new device or reset an existing test device back to OOBE.
• Boot the device and complete basic OOBE prompts (region/keyboard/network).
• Sign in with a user in DP_Users_Pilot.
• Allow the Device Preparation flow to run through configuration, app installs, and scripts.
• If a failure occurs, capture the exact screen message and timestamp for later correlation in Intune monitoring.

Verification Checklist

• User reaches desktop without being blocked in provisioning.
• Required apps are present and launch successfully.

Rollback Procedure

If the pilot fails, reset the device again after correcting the root cause (policy/app assignment/OS updates/network).

Common Errors

• Device is still registered as a classic Autopilot device (classic Autopilot takes precedence).
• OS build is below minimum required update level.

• Verify Entra join and MDM enrollment state on the device.
• Confirm the device is present in Intune and shows the expected Primary user.
• Confirm the device appears in DP_Devices_Pilot membership (added during enrollment time grouping).
• Confirm essential apps are installed using a non-disruptive inventory method (avoid Win32_Product).

Verification Commands

`dsregcmd /status Get-ItemProperty  "HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*"  ,  "HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*"  |  Select-Object DisplayName, DisplayVersion |  Sort-Object DisplayName `

Verification Checklist

• dsregcmd /status shows AzureAdJoined : YES and MDM enrollment present.
• Device record exists in Intune and matches the enrolling user.
• Device is a member of DP_Devices_Pilot.

Rollback Procedure

• Remove the device from DP_Devices_Pilot (if needed) and unassign the policy from the user to stop future attempts.
• Factory reset the device to rerun OOBE after corrections.

Common Errors

• Expecting apps to install when they were only selected in the policy but not assigned to the device group.
• Using Win32_Product for inventory (slow and can trigger MSI self-repair).

• In Intune, open your Device Preparation policy and review provisioning status monitoring.
• Correlate failures to specific apps/scripts and adjust payload accordingly.
• Enable and use diagnostics links/log collection options so users (or IT) can retrieve logs when failures occur.
• Track patterns: network failures, specific app installers, or timeouts.

Verification Checklist

• Provisioning status shows devices moving through phases with app/script status.
• Failures in pilot can be tied to a specific app/script or prerequisite.

Rollback Procedure

Reduce OOBE payload to essentials and move non-essential deployments post-OOBE to improve reliability.

Common Errors

• Treating OOBE failures as 'random' instead of isolating the specific app/script causing timeouts.
• Not collecting logs at failure time, making troubleshooting much harder.

• Expand DP_Users_Pilot gradually or create department-based user groups (for example: DP_Users_Finance).
• Clone the policy as needed for different app sets, keeping each policy's OOBE payload minimal.
• If devices are registered in classic Autopilot, deregister them before attempting Device Preparation on those devices; classic Autopilot takes precedence.
• For devices transitioning from classic Autopilot, plan a reset/redeployment window to re-enter OOBE under the new flow.

Verification Checklist

• New enrollments use Device Preparation policy and are visible in monitoring.
• Devices intended for Device Preparation are not present in classic Autopilot device registration.

Rollback Procedure

• Pause rollout by removing users from the targeting group(s).
• Keep classic Autopilot profiles active for scenarios Device Preparation doesn't cover in your environment.

Common Errors

• Attempting Device Preparation on devices still registered as classic Autopilot devices (wrong flow runs).
• Scaling app payload too aggressively and increasing failure rates.

For best results with Windows Autopilot Device Preparation (v2):

• Keep the OOBE payload minimal (only essential apps/scripts).
• Always assign apps/scripts to the device group used for enrollment time grouping.
• Ensure Intune Provisioning Client is an owner of that device group.
• Validate OS build and network requirements before scaling.
• Expand in waves with clear success metrics (completion time, failure rate by app, and user readiness at first sign-in).