Streamline Device Provisioning with Intune and Autopilot

A Blueprint for the Design, Deployment, and Operation of Windows Autopilot at Scale 

Audience and Purpose 

This reference is intended for Endpoint Architects, Intune Administrators, Engineering Managers, and Service Owners. Its objective is to deliver a pragmatic, evidence-driven framework, in alignment with Microsoft’s latest recommendations and supported by real-world experience, to guide the design, deployment, and operation of Windows Autopilot at enterprise scale. 

Executive Summary 

Optimal Autopilot implementations should default to cloud-native approaches, leveraging Device Preparation (v2) for Microsoft Entra-joined devices wherever feasible. Classic Autopilot (v1) should be reserved for scenarios necessitating advanced Out-of-Box Experience (OOBE) customisation, pre-provisioning, or hybrid join requirements. The Enrolment Status Page (ESP) serves as a critical readiness checkpoint, emphasising Tier-0 validations such as endpoint detection and response (EDR), network and Wi-Fi configuration, certificate deployment, and essential remediation measures. It is recommended to extend timeouts and enable diagnostics for ESP. Non-essential tasks should be deferred until post-ESP, utilising the Company Portal for user-driven self-service. Security standards should be established early through the adoption of the latest Intune Security Baselines, further refined by the Settings Catalog, while avoiding the deployment of conflicting or obsolete baselines. Hybrid join configurations should be implemented only where strictly necessary, ensuring deployment of the current Intune Connector for Active Directory (MSA), verification of organisational unit permissions and domain controller connectivity, and planning for potentially extended ESP durations in these environments. 

1. Architectural Considerations: Classic (v1) vs. Device Preparation (v2) 

Selecting the most suitable Autopilot solution for each use case is crucial, as it significantly influences reliability, operational complexity, and time-to-productivity. 

1.1 Comparative Overview 

Adopting Entra join with Device Preparation (v2) streamlines the Out-of-Box Experience and provides a faster, more consistent onboarding process, facilitated by enrolment-time grouping and enhanced reporting capabilities. Classic (v1) remains essential for instances requiring extensive OOBE customisation, pre-provisioning, and hybrid join support. 

1.2 Design Review: Pros & Cons 

A detailed review should weigh the advantages and disadvantages of each architectural option, factoring in operational requirements, user experience, and deployment complexity. 

Category	Autopilot v1 (Classic)	Autopilot Device Preparation (v2)
Pros	Full OOBE customization; preprovisioning supported; hybrid join supported.	No hardware hash import; cloudfirst reliability; enrollmenttime grouping and near realtime status.
Cons	Requires hardware hash; more OOBE surface → higher ESP stall risk if overconfigured; hybrid adds moving parts.	Entra join only; fewer OOBE knobs; still evolving toward full parity.
Use when…	You need hybrid, deep OOBE control, or preprovisioned technician/OEM flow.	You want fast, lowfriction cloudnative onboarding and simpler operations.

2. End-to-End Workflow 

The workflow follows these sequential stages: establishing network connectivity, downloading profiles, authenticating users, Entra joining, enrolling in MDM (Intune), completing ESP (Device Preparation/Setup; optionally Account Setup), and finally reaching the desktop environment. Structure monitoring and troubleshooting activities according to this progression. 

3. Device & Image Integrity (Critical Prerequisites) 

• Verify that TPM 2.0 is enabled and operating correctly on devices designated for self-deployment or pre-provisioning. 

• Maintain updated firmware and drivers via Windows Update. 

• Utilise OEM-optimised images, retaining all built-in components. 

• Restrict preloaded applications to Microsoft 365 Apps in order to reduce inconsistencies during OOBE and ESP across device fleets. 

4. Enrolment Strategy and Controls 

• Configure Enrollment Restrictions to specify device eligibility and limits: 

• Device Platform: Prevent enrollment of personal Windows devices where only corporate ownership is permitted. 

• Device Limit: Set per-user quotas ranging from 1 to 15 devices. 

Apply policies in order of priority; higher-priority rules override defaults. Note that these controls govern device allocation and are not intended for use as security measures. 

5. ESP (Enrolment Status Page): Intentional Access Control 

• Display installation progress and restrict desktop access exclusively for Tier-0 device-phase requirements, including EDR/AV agents, VPN/ZTNA, Wi-Fi/certificates, essential remediation scripts, and compliance prerequisites such as BitLocker, firewall, and Windows Hello. 

• Extend timeouts beyond 60 minutes when deploying large device-phase applications or within hybrid environments. 

• Enable diagnostic tools and customised support messaging to streamline troubleshooting processes. 

• Avoid initiating device reboots during ESP installations; configure restart settings within Intune application configurations to minimise disruption. 

• Where possible, disable Account Setup during the user phase and deliver user-specific applications following ESP completion. 

ESP Application Checklist 

• Include (gate at ESP): EDR, VPN/ZTNA, Wi-Fi/certificates, compliance prerequisites. 

• Exclude (post-ESP or Company Portal): Microsoft 365 Apps, Teams, OneDrive, large Win32 LOB applications, and any software requiring intermediate reboot operations. 

Recommended Lean ESP App Policy 

Category	ESP	Post ESP (Intune Required)	Company Portal (SelfService)
Security Agent / EDR	✅	—	—
VPN / ZTNA client	✅	—	—
Certificate / WiFi Config	✅	—	—
BitLocker / Security Baseline enforcement	✅	—	—
Microsoft 365 Apps	❌	Optional → Required after ESP	✔ Recommended
Teams / OneDrive	❌	Optional → Required after ESP	✔ Recommended
LOB / Packaging apps	❌	✔ Required (postESP)	✔ Optional
Large Win32 apps	❌	✔ Required (postESP)	✔ Optional

6. Pre-Provisioning (White Glove) Guidance 

• Allocate intensive setup tasks to the technician or OEM stage, then reseal and ship devices so users complete setup rapidly upon receipt. 

• Requirements include TPM 2.0, a device-targeted ESP, and awareness that redeployment may require deleting the device record before re-enrolment. 

• Appropriate for VIP deployments, bandwidth-limited sites, complex application stacks, or mass refreshes. 

7. Security Baselines: Rapid Deployment and Refinement 

• Deploy the latest Intune Security Baselines (Windows, Edge, Defender) initially and test with pilot groups. 

• Update promptly to maintain editable profiles, as older versions become read-only. 

• Prevent overlapping or conflicting baseline policies. 

• For greater accuracy, migrate to Settings Catalog profiles over time. 

8. Hybrid Join: Exception Management 

Microsoft recommends cloud-native, Entra-joined endpoints for new deployments. If hybrid join is unavoidable: 

• Install and validate the updated Intune Connector for AD (Managed Service Account model, least privilege). 

• Confirm OU permissions, domain/DC connectivity, and synchronisation scope. 

• Plan for longer ESP durations due to Active Directory object creation and sync timing; adjust timeouts accordingly. 

9. Application Delivery Best Practices 

• Reserve ESP for Tier-0, device-phase, security-critical applications. 

• Deploy line-of-business (LOB) applications post-ESP as needed. 

• Leverage Company Portal for self-service application delivery to reduce provisioning risks and enhance user autonomy. 

10. Monitoring, Telemetry, and Troubleshooting 

• Reference the Autopilot workflow and verify sequential stages: profile, authentication, Entra join, MDM enrolment, and ESP phases. 

• Utilise AutopilotDiagnostic.json, Provisioning-Diagnostics-Provider event logs, and integrated Autopilot Diagnostics features for issue resolution. 

• Consult Microsoft training modules for common issue walkthroughs and review FAQs for process explanations and known concerns. 

11. Implementation Runbook (Abbreviated) 

1. Select the appropriate model per scenario: prefer Device Preparation; use Classic for pre-provisioning or hybrid cases. 

2. Ensure device health: TPM 2.0 active, OEM image utilised, drivers maintained via Windows Update. 

3. Configure and prioritise enrolment restrictions (platform and device limits). 

4. Define ESP profile: display progress, block desktop for Tier-0, increase timeout, activate diagnostics. 

5. Curate applications for essential device-phase inclusion; postpone bulk/user apps to post-ESP or Company Portal. 

6. Deploy current security baselines to pilot groups; mitigate conflicts; refine using Settings Catalog. 

7. For hybrid scenarios: install updated AD connector (MSA), confirm OU permissions and domain/DC reachability, allow extra time. 

8. Use pre-provisioning where it notably improves activation time; recognise re-enrolment requirements. 

9. Adhere to disciplined troubleshooting: follow the established workflow, gather diagnostics, document resolutions. 

12. Operational Metrics 

• Track time-to-desktop (OOBE initiation to usable desktop) by workflow type (v2 vs v1; pre-provisioned vs standard). 

• Monitor ESP failure rates by application and phase; identify and address problematic apps and reboot patterns. 

• Evaluate baseline drift/conflicts and policy update latency during rollout cycles. 

• Measure hybrid join queue times: connector status, OU write permissions, directory sync intervals. 

In conclusion, navigating the complexities of Windows Autopilot deployment requires careful consideration of hardware requirements, configuration options, and security measures. By leveraging the guidance provided in this blog, IT professionals can streamline device provisioning, optimise enrolment processes, and enhance security across their organisation. With the right preparation and best practises in place, your team will be well-equipped to address challenges and maximise the benefits of modern device management solutions.