Autopilot device preparation rarely fails loudly. The device joins Entra, lands on the desktop, and the apps you expected simply never show up. This article walks through a read-only PowerShell script that checks every tenant-side link of the Autopilot v2 chain in one run, and explains how to read and act on its report.

01 – Why Autopilot v2 fails silently

Windows Autopilot device preparation (DPP, often called Autopilot v2) was re-architected around one key idea: no hardware hash registration. The user signs in during OOBE, the device joins Microsoft Entra ID, enrolls in Intune, and the Intune Provisioning Client service principal adds the device to a pre-defined security group. Apps and scripts assigned as Required to that group are then delivered in a serialized way before the user reaches the desktop.

That design removes the hash import burden, but it moves the complexity elsewhere. A successful deployment depends on a dozen independent objects configured in two different portals: Entra ID and Intune. When one of them is wrong, DPP does not always throw a clear error. It may just skip the device preparation phase entirely, and the user gets a bare desktop.

• Silent skip : The user is not targeted by any DPP policy. OOBE completes, but no device preparation page ever appears.
• Empty group : The Intune Provisioning Client is not owner of the device group, so the device is never added and nothing installs.
• Wrong precedence : A leftover Autopilot v1 registration takes precedence and the device follows the classic profile instead.

Troubleshooting these cases by clicking through the portals is slow and error-prone, especially in tenants that run v1 and v2 side by side during a migration. The script presented here turns that checklist into a single, repeatable, read-only audit.

02 – The dependency chain the script audits

Every DPP deployment walks the same path. Each step depends on tenant-side objects, and each object maps to one section of the script.

03 – Read-only by design

A diagnostic tool that runs in production must be safe to hand to a level 2 technician or to run during an incident. The script enforces that at two independent levels.

• Level 1: the token
  • Only *.Read.All delegated scopes are requested at connection time. Even if the code were modified, a token without write scopes cannot change anything in the tenant. If an existing Graph session already carries ReadWrite scopes, the script warns you and recommends reconnecting.
• Level 2: the code
  • Every Graph request goes through a single function, Get-Graph, which only issues GET calls, follows @odata.nextLink paging, and returns an { Ok; Data; Error } object so that “empty result” and “access denied” are never confused.

04 – Running the diagnostic

Parameters

Three ways to use it

# 1. Tenant health check (no user, no device): prerequisites, CA, policies, groups, apps
.\Test-AutopilotDevicePrep-EN.ps1 -ExportPath C:\Temp\DPP

# 2. Incident on one device: full chain for a user and a serial number
.\Test-AutopilotDevicePrep-EN.ps1 -UserPrincipalName jdoe@contoso.org -SerialNumber 5CG1234XYZ -ExportPath C:\Temp\DPP

# 3. Automation: keep only blocking items and feed them to another tool
$r = .\Test-AutopilotDevicePrep-EN.ps1 -UserPrincipalName jdoe@contoso.org -PolicyName 'DPP*' -PassThru
$r | Where-Object Status -eq 'FAIL' | Format-Table Category, Check, Remediation -Wrap

05 – The Audit script

check the script directly on my Github repo :

https://github.com/aymenjaz/PowerShell/blob/main/1%20-%20Microsoft%20365/Intune/Test-AutopilotDevicePrep-EN.ps1

06 – Reading the report

Each check produces one row with five columns: Status, Category, Check, Detail, Remediation. The HTML report follows the system light or dark theme; the CSV is ready for Excel or Power BI.

Example of HTML report page

Autopilot device preparation diagnostic

User: jdoe@contoso.org | Serial number: 5CG1234XYZ | Generated on 2026-11-09 09:14
PASS 23 | WARN 9 | FAIL 9 | INFO 38 | SKIP 0

Thanks