Mastering Windows Autopilot device preparation

Are you still waiting for hardware hashes to sync before your devices can complete provisioning?

Windows Autopilot device preparation changes the game entirely. After months of previewing this technology, I am convinced this is the direction every cloud-native organization should be heading. If you have not started exploring Windows Autopilot device preparation yet, now is the time.

What is Windows Autopilot device preparation?

Windows Autopilot device preparation represents Microsoft’s next-generation approach to device provisioning. While traditional Windows Autopilot has served us well for years, it comes with a fundamental requirement: devices must be pre-registered with their hardware hash before enrollment can succeed. This creates a dependency on OEM partners, resellers, or manual hash collection that can slow down deployments.

Windows Autopilot device preparation eliminates this requirement. Devices are enrolled directly through Microsoft Entra ID join, with policy-driven configuration applied during the out-of-box experience. No hardware hash pre-registration needed.

For organizations embracing a cloud-native strategy, this is a significant step forward. The future of device management is cloud-first, and Windows Autopilot device preparation aligns perfectly with this vision.

Why the urgency to go cloud-native?

If you are still running Hybrid Windows Autopilot or relying heavily on on-premises infrastructure for device provisioning, I encourage you to reconsider your approach. The industry is moving rapidly toward cloud-native solutions, and for good reason:

• Reduced infrastructure dependency: No need for line-of-sight to domain controllers during provisioning.
• Simplified network requirements: Devices can be provisioned from anywhere with internet connectivity.
• Faster deployment cycles: No waiting for hardware hash synchronization or partner registration.
• Better user experience: Streamlined OOBE with clear progress indicators.

This is not just about simplifying IT operations - it is about positioning your organization for the future. Microsoft’s investments are clearly focused on cloud-native scenarios, and the message from Redmond has been unmistakably clear:

All development is happening in cloud-native. You have six months to catch up, otherwise you will be left behind on the platform.

Windows Autopilot device preparation is a direct result of this cloud-first focus. It assumes devices will join Microsoft Entra ID directly and receive their configuration from Microsoft Intune - no on-premises dependencies required. Organizations still anchored to Hybrid join or Configuration Manager will find themselves with fewer new features and less investment over time. The sooner you start testing cloud-native provisioning, the better prepared you will be.

Key improvements over traditional Windows Autopilot

Having worked with both traditional Windows Autopilot and Windows Autopilot device preparation, I can highlight several improvements that make the new approach compelling:

Enrollment time grouping

This is perhaps the most significant improvement. With traditional Windows Autopilot, devices are added to dynamic groups based on their properties after enrollment completes. This means policies and applications assigned to those groups only start applying after the device is already enrolled and the group membership is calculated.

Windows Autopilot device preparation introduces enrollment time grouping. Devices are added to a designated security group during the enrollment process itself. This means your policies and applications start flowing immediately, resulting in faster and more reliable setups.

Think about it: instead of waiting for dynamic group evaluation, your device is already a member of the target group before the enrollment status page even starts processing applications.

Real-time reporting and monitoring

Traditional Windows Autopilot provides limited visibility during deployment. You often have to wait until enrollment completes (or fails) to understand what happened. Troubleshooting a failed deployment typically involves collecting logs and piecing together what went wrong.

Windows Autopilot device preparation introduces near real-time reporting. You can see the deployment progress as it happens, including the status of individual applications and PowerShell scripts. This granular visibility makes troubleshooting significantly easier and faster.

When something fails, you know immediately - not hours later when the user calls support.

Improved user experience

The out-of-box experience with Windows Autopilot device preparation feels more polished. Users see clear progress indicators showing what is being installed and configured. When setup completes, they receive a clear message confirming their device is ready for use.

This improved visibility reduces user anxiety during setup. Instead of staring at a spinning wheel wondering if the device is stuck, users can see exactly what is happening.

Available scenarios

Windows Autopilot device preparation currently supports the following scenarios:

The user-driven Microsoft Entra join scenario is what most organizations will use for physical devices. The user signs in during OOBE, and the device preparation policy takes over from there.

Prerequisites

Before implementing Windows Autopilot device preparation, ensure your environment meets these requirements:

Setting up Windows Autopilot device preparation

The setup process involves several components working together. Here is an overview of what you need to configure:

Create the required groups

You need two groups in Microsoft Entra ID:

1. User group: Contains the users who are allowed to use Windows Autopilot device preparation. This group is assigned to the device preparation policy.

2. Device group: This is the group where devices will be added during enrollment (enrollment time grouping). The Intune Provisioning Client service principal must be added as an owner of this group.

The device group is particularly important. Applications, scripts, and configuration policies assigned to this group will be applied during the device setup phase of enrollment.

Create the device preparation policy

Navigate to Devices > Enrollment > Device preparation policies in the Microsoft Intune admin center and create a new policy. The policy links together:

• The user group (who can use this policy)
• The device group (where devices will be placed)
• OOBE customization settings

Assign applications and scripts

Unlike traditional Windows Autopilot where you might rely on the Enrollment Status Page to block on applications, Windows Autopilot device preparation works differently. You assign applications and scripts directly to the device group created earlier.

My recommended approach:

• Assign essential applications as Required to the device group
• Include Microsoft 365 Apps, Company Portal, and any critical line-of-business applications
• Add platform scripts for additional configuration as needed

Keep the list focused. Fewer applications during initial setup means faster deployment and fewer potential failure points.

Deployment order

Understanding the deployment sequence helps you design your scripts and applications correctly. Windows Autopilot device preparation follows this order:

1. Device joins Microsoft Entra ID and enrolls in Microsoft Intune
2. Intune Management Extension installs
3. User account type enforced (standard user or administrator)
4. MDM policies sync (but policy application is not tracked during deployment)
5. LOB and Microsoft 365 apps install
6. PowerShell scripts run
7. Win32, Microsoft Store, and Enterprise App Catalog apps install
8. Deployment completes and user reaches the desktop

Note that policies assigned to the device group will sync during deployment, but Windows Autopilot device preparation does not track whether they are fully applied. Policies may be applied during deployment or after the user reaches the desktop.

Application deployment best practices

Not all applications behave the same during Windows Autopilot device preparation. Understanding the nuances can save you hours of troubleshooting.

Supported application types

Windows Autopilot device preparation supports the following application types during the device setup phase:

• Win32 applications - The most flexible option with full control over installation behavior
• Line-of-business (LOB) applications - MSI-based applications uploaded directly to Microsoft Intune
• Microsoft Store apps - Including the new Microsoft Store experience

With traditional Windows Autopilot, mixing Win32 and LOB apps during ESP could cause installation failures because both app types might attempt to use the Trusted Installer service simultaneously. Windows Autopilot device preparation explicitly supports deploying both Win32 and LOB applications in the same deployment . That said, my experience shows that sticking with Win32 apps exclusively still provides the most reliable and consistent deployment experience.

Application selection guidance

The device preparation policy allows you to select a maximum of 10 applications. These are the essential applications that must be installed before the user can start using the device. You can assign additional applications directly to the device group - these will install in the background after the user reaches the desktop, but they are not part of the device preparation policy itself.

When deciding which applications to include in your device preparation policy, consider:

• Essential applications only: Include only what users need immediately. Microsoft 365 Apps, Company Portal, and critical LOB applications are good candidates.
• Avoid large applications: Applications over 1 GB significantly increase deployment time. Consider deploying these after the user reaches the desktop.
• Test dependencies carefully: If Application B depends on Application A, ensure the dependency is properly configured in Microsoft Intune.
• Consider detection rules: Win32 apps with complex detection rules may take longer to validate. Simple detection rules speed up the process.

For more detailed strategies on optimizing application deployment, see my post on 3 ways to optimize any Windows Autopilot scenario.

PowerShell script considerations

PowerShell scripts extend the capabilities of Windows Autopilot device preparation, allowing you to configure settings that are not available through standard Microsoft Intune policies.

Execution context

Scripts assigned to the device group during Windows Autopilot device preparation run in the SYSTEM context by default. This means:

• Scripts have full administrative privileges
• User-specific configurations are not possible during device setup
• Environment variables like $env:USERNAME will return the system account, not the user

Script limits and timeouts

Keep these limits in mind when designing your scripts:

Best practices for scripts

Based on my experience, these practices have proven most valuable when writing scripts for Microsoft Intune:

• Structure scripts well: With only 10 script slots available, consolidate related tasks into well-organized scripts. Use functions, clear comments, and logical sections to keep scripts maintainable and easy to troubleshoot.
• Include proper error handling: Scripts should exit with appropriate exit codes. Exit code 0 indicates success; non-zero indicates failure.
• Use UTF-8 encoding without BOM: Microsoft Intune requires scripts to be encoded in UTF-8 . When script signature checking is enabled, scripts must use UTF-8 without the Byte Order Mark (BOM). Editors like VS Code save UTF-8 without BOM by default, while PowerShell ISE adds a BOM that can cause issues.
• Log your actions: Write to a log file for troubleshooting. The C:\ProgramData\Microsoft\IntuneManagementExtension\Logs folder is a good location.
• Test thoroughly: Test scripts on a clean device before adding them to your device preparation policy.

Example script structure

# Description: Example script structure for Windows Autopilot device preparation
# Elevation is required - Script runs in SYSTEM context during device setup

$LogPath = "C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\DevicePrep.log"

function Write-Log {
    param([string]$Message)
    $Timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
    "$Timestamp - $Message" | Out-File -FilePath $LogPath -Append
}

try {
    Write-Log "Script started"
    # Your configuration logic here
    Write-Log "Script completed successfully"
    exit 0
}
catch {
    Write-Log "Error: $_"
    exit 1
}

End-user experience

Understanding what users see during Windows Autopilot device preparation helps you set expectations and reduces support calls.

The provisioning flow

When a user powers on a new device configured for Windows Autopilot device preparation, they experience the following:

1. Standard OOBE screens: Region, keyboard layout, and network connection
2. Sign-in prompt: User signs in with their Microsoft Entra ID credentials
3. Device preparation screen: A progress indicator shows the setup status with percentage complete
4. Application installation: Users see which applications are being installed
5. Completion message: A clear notification when the device is ready

Progress visibility

Unlike traditional Windows Autopilot where users often see vague “Setting up your device” messages, Windows Autopilot device preparation provides:

• Percentage progress: Users see exactly how far along the setup is
• Current activity: The screen shows what is currently being installed or configured
• Time estimates: Users get a sense of how long the process will take

This transparency significantly improves user satisfaction. In my experience, users are more patient when they can see progress versus staring at an indeterminate spinner.

When things go wrong

If an application or script fails during device preparation, the user sees an error screen with options to:

• Try again: Retry the failed component
• Continue anyway: Skip the failed component and proceed (if allowed by policy)
• Collect logs: Export diagnostic logs for IT support

The ability to export logs directly from the device is a significant improvement over traditional Windows Autopilot troubleshooting.

Monitoring and reporting

One of the standout features of Windows Autopilot device preparation is the improved monitoring experience. Here is how to make the most of it.

Accessing deployment reports

To view Windows Autopilot device preparation deployments:

1. Sign in to the Microsoft Intune admin center 
2. Navigate to Devices > Monitor > Windows Autopilot device preparation
3. Select a deployment to view details

The report shows all devices that have gone through Windows Autopilot device preparation, with status information updated in near real-time.

Understanding deployment statuses

Each deployment can have one of the following statuses:

Drilling into details

For each device, you can see:

• Profile information: Which device preparation policy was applied
• Application status: Each application with its installation status and timing
• Script status: Each PowerShell script with execution results
• Deployment duration: How long the entire process took

This level of detail makes troubleshooting significantly easier. You can identify exactly which component failed and when.

Troubleshooting common issues

Even with improved reporting, deployments occasionally fail. Here are the most common issues I have encountered and how to resolve them.

Application installation failures

Symptom: An application shows as failed in the deployment report.

Common causes:

• Application content not yet replicated to CDN (wait 15-30 minutes after uploading)
• Detection rule not matching post-installation state
• Dependency application not installed first
• Insufficient disk space on the device

Resolution steps:

1. Check the application status in the deployment report for error codes
2. Verify the application installs successfully on a test device outside of device preparation
3. Review detection rules and ensure they match the installed state
4. Check Microsoft Intune for any app assignment conflicts

Script execution failures

Symptom: A PowerShell script shows as failed in the deployment report.

Common causes:

• Script timeout (exceeded 60 minutes)
• Script returned non-zero exit code
• Script depends on components not yet installed
• Network-dependent operations failed

Resolution steps:

1. Check the script output in the deployment report
2. Review logs at C:\ProgramData\Microsoft\IntuneManagementExtension\Logs
3. Test the script manually on a device in the same state
4. Ensure the script handles errors gracefully and returns appropriate exit codes

Device not receiving policy

Symptom: Device completes OOBE but does not go through Windows Autopilot device preparation.

Common causes:

• User not a member of the user group assigned to the policy
• Device has an existing Windows Autopilot profile (takes precedence)
• Multiple device preparation policies with conflicting assignments

Resolution steps:

1. Verify the user is in the correct user group
2. Check if the device is registered in Windows Autopilot (if so, remove it)
3. Review policy assignments for conflicts
4. Ensure the device meets the Windows version requirements

Collecting diagnostic logs

When troubleshooting fails, collect comprehensive logs:

1. From the device during OOBE: Press Shift+F10 to open a command prompt, then run:

# Description: Collect diagnostic logs during Windows Autopilot device preparation
# Elevation is not required - Command prompt in OOBE runs with system privileges

mdmdiagnosticstool.exe -area Autopilot -cab C:\temp\AutopilotDiag.cab

2. From the Microsoft Intune admin center: Use the deployment report to view application and script logs directly.

3. Post-enrollment: Navigate to C:\ProgramData\Microsoft\IntuneManagementExtension\Logs for Intune Management Extension logs.

Current limitations

Windows Autopilot device preparation is not a complete replacement for traditional Windows Autopilot - at least not yet. There are several gaps to be aware of:

These limitations are worth understanding, but they should not stop you from exploring the technology. For many scenarios, especially in cloud-native organizations, the benefits outweigh these gaps.

A word about enrollment restrictions

You might wonder whether you need enrollment restrictions when using Windows Autopilot device preparation. The short answer: it depends on your security requirements.

Since Windows Autopilot device preparation does not rely on hardware hash pre-registration, Microsoft Intune cannot automatically distinguish between corporate and personal devices. If you block personally owned devices through enrollment restrictions, you will need to pre-register device identifiers (manufacturer, model, serial number) so Microsoft Intune recognizes them as corporate-owned.

I am planning a deeper exploration of this topic, examining whether enrollment restrictions are truly necessary in a world where identity-centric security controls exist. Stay tuned.

Take the first step

If you have not yet explored Windows Autopilot device preparation, I strongly encourage you to set up a test environment and try it. The experience is genuinely improved over traditional Windows Autopilot, and the enrollment time grouping feature alone makes it worth investigating.

My recommendation is to run both Windows Autopilot versions in parallel during the transition. Keep your existing traditional Windows Autopilot profiles for devices that need them, while introducing Windows Autopilot device preparation for new deployments. This approach ensures compatibility across your device fleet and gives you time to address any gaps before fully committing.

Start small:

1. Create the required groups in Microsoft Entra ID
2. Configure a device preparation policy with basic settings
3. Assign a few applications to the device group
4. Test with a virtual machine or spare device

See the resources section below for links to the official documentation, including a comprehensive step-by-step walkthrough for the user-driven Microsoft Entra join scenario.

Wrapping up

Windows Autopilot device preparation represents a meaningful evolution in how we provision Windows devices. The elimination of hardware hash requirements, combined with enrollment time grouping and real-time reporting, addresses many pain points we have experienced with traditional Windows Autopilot.

Is it perfect? No. There are gaps, and some organizations will still need traditional Windows Autopilot for specific scenarios. But the direction is clear: cloud-native provisioning is the future, and Windows Autopilot device preparation is a significant step on that journey.

If your organization is committed to a cloud-first strategy, start testing Windows Autopilot device preparation now. The sooner you understand its capabilities and limitations, the better positioned you will be when it becomes the standard approach for device provisioning.

–Jesper

Header image attribution: Image created with help from Microsoft Copilot