Deploying Windows Autopilot Device Preparation for New Hires

#Operational requirement

A new starter opens their laptop on day one and expects to be working inside forty-five minutes: joined to Entra ID, enrolled in Intune, with the right apps and policies present, and no helpdesk ticket required. If provisioning is not deterministic, you get inconsistent builds, tickets raised in week one, and a device that drifts out of compliance before it has even been used properly. Windows Autopilot device preparation (the newer, faster successor to the older Autopilot profile flow for Entra-joined devices) is designed specifically for this scenario: fast, self-service, zero-touch provisioning for corporate-owned Windows devices, with a hard timeout so users are not left stuck in setup. Getting this wrong in production means either onboarding chaos or a security gap where devices reach the desktop before required configuration and compliance policies have applied.

This tutorial walks a newly hired systems administrator through configuring device preparation end-to-end: registering hardware, building the deployment profile, assigning apps and policies against the correct Entra ID security group, and testing the flow with evidence you can hand to a change board.

#Prerequisites and required permissions

You need an Intune tenant with Windows Autopilot enabled, and the following role assignments. Use least privilege; do not run this as Global Administrator.

You also need change-management sign-off for the deployment profile before it goes to a production group, and a rollback plan agreed in advance — not written after something breaks.

#Step 1: Register device hardware identifiers

If your OEM or reseller supports Autopilot registration (most Tier 1 vendors do via CSV or API integration with Microsoft), confirm the tenant ID they registered against matches production, not a test tenant. For devices already in the field or for a pilot batch, export the hardware hash manually.

1Install-Script -Name Get-WindowsAutoPilotInfo -Force
2Get-WindowsAutoPilotInfo.ps1 -OutputFile C:\Autopilot\devices.csv -GroupTag "HQ-Standard"

Expected result: a CSV containing Serial Number, Hardware Hash, and the Group Tag you specified. Import this into Intune under Devices > Enrollment > Windows Autopilot devices > Import. Import can take up to fifteen minutes to sync before the device appears in the Autopilot devices list.

Evidence to capture: the CSV file, a screenshot of the imported device list showing Serial Number and Group Tag populated, and the timestamp of import.

Checkpoint: do not proceed until the device shows a status of Assigned against a profile — even a test profile — confirming registration succeeded.

#Step 2: Build the device preparation policy

Navigate to Intune admin center > Devices > Enrollment > Windows Autopilot > Deployment profiles > Create profile > Windows PC > Device preparation policy. Configure the following, matching your organisation’s naming convention:

1Policy name: DPP-HQ-Standard-Prod
2Deployment mode: User-driven
3Join type: Microsoft Entra joined
4Account type: Standard user (or Local administrator if genuinely required)
5Timeout: 60 minutes (default; reduce for tighter SLAs)
6Allowed apps: whitelist only apps required pre-desktop
7Assigned group: SG-Autopilot-DevicePrep-Pilot

Set the timeout deliberately. If it is too long, users sit at a blank screen wondering if the machine is broken; if too short, slow network links or large app packages will cause a hard failure mid-provisioning. Sixty minutes is a sane starting point for a corporate network; test it against your actual app payload before trusting it in production.

Assign the profile to a pilot security group first — never to All Devices or a dynamic group with broad membership rules. Evidence to capture: exported profile JSON via Graph, and a screenshot of the assignment blade showing the pilot group only.

1Connect-MgGraph -Scopes "DeviceManagementServiceConfig.Read.All"
2Get-MgDeviceManagementWindowsAutopilotDeploymentProfile | Select-Object DisplayName, Id, CreatedDateTime

#Step 3: Attach apps, compliance policy and configuration profiles

Device preparation is not just OOBE automation — it is the mechanism that ensures required apps and compliance settings apply before the user reaches the desktop. In Apps > Windows, mark the required baseline apps (VPN client, endpoint protection, LOB apps) with assignment intent Required and scope them to the same pilot group. In Endpoint security > Compliance policies, confirm your Windows compliance policy (BitLocker status, minimum OS build, Defender status) is assigned to the same group so compliance evaluation starts immediately on first sign-in, not hours later.

Checkpoint: run Devices > Monitor > Enrollment failures after your first pilot run and confirm zero entries. Any failure here at pilot stage must be resolved before wider rollout — do not treat enrolment failures as noise to fix later.

#Step 4: Pilot the enrolment and record evidence

Unbox or reset a genuine pilot device, connect it to a network matching a real user’s, and sign in with a pilot user account that is a member of SG-Autopilot-DevicePrep-Pilot. Time the run from first sign-in screen to desktop.

Evidence to capture: elapsed time, screenshot of Devices > All devices showing the device as Entra joined and Intune managed, and the compliance state (should read Compliant within a further 15 minutes as policy evaluates in the background). Log this in your change record with device serial number and profile version.

#Verification and evidence

Confirm success against three data points, not one. First, Entra ID device object exists with join type Microsoft Entra joined. Second, Intune shows the device with a compliance state of Compliant, not In grace period, within your agreed SLA window. Third, the enrolment log (Event Viewer > Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider) shows no errors during the ESP-equivalent phase. Retain the pilot CSV, deployment profile JSON export, and a screenshot bundle as your change evidence pack — auditors and future you will want this.

#Failure Modes and Common Traps

The most common failure is a device stuck at Account setup indefinitely — usually caused by a required app assignment referencing an app with a broken install script or an expired certificate, which blocks the whole phase since device preparation treats required apps as blocking by default unless configured otherwise. Check Apps > Monitor > App install status for the specific device.

A second trap: the Autopilot device shows as Assigned in the portal but the physical device never picks up the profile. This is almost always a Group Tag mismatch between the CSV import and the dynamic group’s membership rule — verify the rule syntax, for example (device.devicePhysicalIDs -any (_ -eq "[OrderID]:HQ-Standard")), matches exactly what you set during hash export.

A third: users report the device hard-times-out and dumps them to a local account or restart screen. This is the timeout value being shorter than actual provisioning time under real network conditions — pilot on the slowest realistic network link, not the office backbone, before setting a production timeout.

Do not assign device preparation profiles to a broad or dynamic-all group during pilot. Scope creep here has bricked onboarding for an entire new-starter cohort in more than one organisation.

#Realistic Failure Symptom: Silent App Failure

A less obvious symptom worth documenting separately: the device reaches the desktop within the timeout window, reports as Entra joined and Intune managed, yet a required app silently failed to install without triggering a hard timeout. This occurs when an app is marked as available rather than required, or when a required app’s detection rule is misconfigured and Intune incorrectly reports success. Verify actual app presence on a sample of pilot devices manually, using Get-AppxPackage or checking installed programs, rather than trusting the portal’s reported install status alone during early pilot runs.

#Rollback

If the pilot or production rollout causes failures, reverse in this order, not simultaneously:

11. Remove the pilot/production security group from the deployment profile assignment blade (Devices > Enrollment > Windows Autopilot > Deployment profiles > DPP-HQ-Standard-Prod > Assignments > Remove group)
22. Confirm no new enrollments are picking up the profile by checking Monitor > Enrollment failures for new entries over the next 30 minutes
33. Delete affected device objects from Entra ID (Devices > All devices > select > Delete) if they enrolled in a broken state
44. Re-import the affected serial numbers into Windows Autopilot devices list if a clean re-run is required
55. Restore the previous known-good deployment profile JSON if the profile itself was edited, using Graph or manual reconfiguration

Never leave a broken profile assigned while you investigate — unassign first, diagnose second. Users should not keep hitting a known-bad configuration while you troubleshoot.

#Monitoring and Alerting Configuration

Do not rely on ad-hoc portal checks once the profile leaves pilot. Configure a scheduled query against the Intune reporting endpoint or Log Analytics workspace (if diagnostic export is enabled) to surface enrolment failures on a recurring basis rather than discovering them from a new starter’s complaint. A workable baseline query against the IntuneDeviceEnrollmentEvents table filters on failed states within the last 24 hours:

1IntuneDeviceEnrollmentEvents
2| where EnrollmentState == "Failed"
3| where TimeGenerated > ago(24h)
4| project TimeGenerated, DeviceName, SerialNumber, FailureReason

Set an alert threshold at two or more failures within a rolling four-hour window during business hours; a single isolated failure may be a network blip, but a cluster indicates a broken app package or certificate expiry that will affect the next cohort. Route this alert to the identity or endpoint engineering channel, not a general helpdesk queue, since first-line support cannot remediate a broken deployment profile.

#Change-Control Record Requirements

Your change board will expect a record that goes beyond a screenshot bundle. At minimum, log the deployment profile version (capture the lastModifiedDateTime property from the Graph export), the pilot group membership count at time of test, the specific hardware models and firmware versions tested, and the named approver who signed off the production assignment. Retain this record for at least one full audit cycle, typically twelve months, since compliance reviewers may ask to trace a specific device back to the profile version active on its enrolment date.

#Escalation Thresholds

Define escalation triggers before go-live rather than during an incident. A single stuck device during pilot is a diagnostic task for the engineer running the pilot. Three or more stuck devices within a single cohort, or any failure that affects a VIP or executive onboarding, should escalate immediately to the Intune administrator on call rather than waiting for the next standup. If enrolment failures exceed ten percent of a daily new-starter cohort, treat this as a production incident and invoke the rollback procedure without waiting for root cause analysis first — restore service, then investigate.

#Operational Summary

You have registered hardware into Windows Autopilot, built a scoped device preparation policy, attached required apps and compliance policy to the same assignment group, piloted the flow with timed evidence, and rehearsed a safe rollback path. The deliverable for your change record is the evidence pack: import CSV, profile JSON export, pilot timing log, and compliance state screenshot. Before promoting this profile beyond pilot, run it against at least three hardware models and two network conditions, and get explicit sign-off from whoever owns the new-starter onboarding SLA. Once this profile is stable in production, the next task on your list is almost certainly building the matching decommissioning path for when these same devices leave the estate.