One of the most useful things Microsoft 365 tenant administration gives you is the ability to ship a brand new laptop straight to someone’s house and have it configure itself completely on first boot — no imaging, no USB sticks, no IT visit required. This is Windows Autopilot, and getting it working reliably across a fleet of devices touches Entra ID, Intune, and a fair bit of planning.
The end goal
A new device arrives at an end user’s desk still sealed in its box. They open it, connect to WiFi, sign in with their work account, and from that point everything else happens automatically — domain join, app installation, policy application, security baseline — all without IT ever touching the physical device.
Registering devices with Autopilot
Before any of this works, a device’s hardware hash needs to be registered with Autopilot. For devices bought through a Microsoft CSP partner, this often happens automatically at point of sale — the reseller registers the hash on your behalf as part of fulfilment. For devices you already have in hand, you can extract the hash manually:
Install-Script -Name Get-WindowsAutoPilotInfo -Force
Get-WindowsAutoPilotInfo.ps1 -OutputFile devicehash.csv
That CSV then gets uploaded to Intune → Devices → Enrollment → Windows Autopilot devices → Import.
This has to be run before the device is factory-reset or reimaged for the end user — it needs to run against the OEM’s original Windows install, since it’s reading hardware identifiers that OEM imaging tools populate. Running it against an already-wiped or third-party-imaged device sometimes returns a blank or invalid hash, which is a frustrating discovery partway through a deployment.
Deployment profiles
Once devices are registered, a Deployment Profile controls what the actual out-of-box experience looks like. Configured under Intune → Devices → Windows → Enrollment → Deployment Profiles:
Deployment mode: User-driven
Join type: Microsoft Entra joined
User account type: Standard (not local admin)
Language: Operating system default
Automatic redeployment: Enabled
Skip privacy settings: Yes
Skip EULA: Yes
Hide change account: Yes
Turning off the various “skip” prompts removes friction from the setup screens an end user has to click through — the fewer decisions someone unfamiliar with IT has to make, the smoother the whole thing goes. User account type: Standard is a deliberate security choice, not just a default left alone — giving every end user local admin rights on their own machine by default significantly widens the blast radius of a compromised account or a user installing something they shouldn’t.
Enrollment Status Page
The Enrollment Status Page (ESP) is what keeps the device on a “setting up your device” screen until all the required apps and policies have actually applied — rather than dropping the user onto a desktop that looks ready but is still silently installing things in the background.
Show progress to user: Yes
Block device use until required apps installed: Yes
Allow users to reset device on error: Yes
Timeout: 60 minutes
This is worth tuning carefully — set it too strict and a single failed app installation blocks the whole enrollment indefinitely (with the user staring at a spinner and no clear way forward except calling IT); set it too loose and users end up on a half-configured desktop believing setup is complete when critical policies haven’t actually landed yet. Allow users to reset device on error is the safety valve for the strict setting — without it, a genuinely stuck ESP has no user-accessible recovery path at all.
Compliance and Conditional Access
Once a device is enrolled, Intune compliance policies define what “healthy” looks like — BitLocker enabled, up to date, not jailbroken, antivirus active. Devices that fall out of compliance can then be blocked from accessing company resources via Conditional Access:
Compliance policy requires:
- BitLocker: Required
- Firewall: Required
- Antivirus: Required
- Minimum OS version: Windows 11 22H2+
Conditional Access policy:
Users: All users
Cloud apps: Office 365
Conditions: Device platforms = Windows
Grant: Require device to be marked as compliant
This is the piece that actually enforces the value of Autopilot beyond convenience — a device that hasn’t gone through proper enrollment, or that later falls out of compliance (BitLocker gets disabled, Defender gets turned off), loses access automatically rather than silently remaining trusted. It’s worth testing this Conditional Access policy in report-only mode first against a small pilot group before enforcing tenant-wide — a compliance policy with an unexpectedly strict setting (a minimum OS build that excludes devices mid-update-rollout, for instance) can lock out a wider group than intended if switched straight to enforced.
App deployment
Line-of-business apps and standard tooling get pushed via Intune app assignments, targeted at device or user groups rather than individuals — new starters just need adding to the right group and Autopilot handles the rest:
Required apps (auto-install):
- Microsoft 365 Apps
- Company VPN client
- Endpoint security agent
Available apps (self-service via Company Portal):
- Adobe Reader
- Additional line-of-business tools
Required apps are the ones the Enrollment Status Page actually blocks on if Block device use until required apps installed is enabled — so it’s worth keeping that list to genuinely essential software rather than everything the organisation happens to use, or every new device deployment takes noticeably longer waiting on installs that aren’t actually needed on day one.
Result
A device that ships directly from a distributor to an end user’s home, gets unboxed, signed into once, and is fully configured — apps installed, policies applied, compliant and Conditional-Access-ready — entirely without IT hands-on time. For a distributed workforce this removes what used to be one of the most time-consuming parts of onboarding, and the compliance-plus-Conditional-Access pairing means that value doesn’t erode the moment a device’s security posture changes after initial setup.