Windows Autopilot MDM Log Collection: Complete Troubleshooting Reference

The problem: stuck in OOBE or ESP with no error on screen

A device powers on, hits the Windows out-of-box experience or the Enrollment Status Page, and stops. No helpful error message. No progress. The admin is staring at a blue screen with a spinner, or at an ESP page that has been counting down for 45 minutes. The fix is almost always in the logs — but those logs are not in an obvious place, and in OOBE they disappear the moment the device reboots.

This post is the single reference for every log collection method across every Autopilot scenario. It covers the commands, what’s inside the collected files, every registry key the MDM stack writes, every Autopilot event ID, every error code, and the system binaries involved. An IT engineer who has never opened an MDM diagnostic cab before should be able to follow this from start to finish and know exactly what went wrong.

How the MDM log pipeline works

Two tools are involved and they are often confused with each other. They do different things:

MdmDiagnosticsTool.exe is a collection tool. It snapshots the current MDM state — registry values, event logs, ETL traces, policy summaries — and packages everything into a cab or zip file. You run it on the broken device to get the data out.

Get-AutopilotDiagnostics is an analysis tool. It reads an existing cab file and produces a human-readable summary of what it finds. You run it on your admin workstation after you have the cab.

The workflow is always: collect with MdmDiagnosticsTool.exe → transfer the cab → analyse with Get-AutopilotDiagnostics or open the files directly.

Quick reference: which command to run

Jump to the row that matches your situation. Every command below is expanded in detail in the sections that follow.

Method 1: MdmDiagnosticsTool.exe — all variants

MdmDiagnosticsTool.exe is built into Windows 10 version 1809 and later at %windir%\System32\MdmDiagnosticsTool.exe. It must be run as Administrator. During OOBE, the Shift+F10 command prompt is already elevated.

Combined command (recommended — use this in all cases)

C:\> MdmDiagnosticsTool.exe -area Autopilot;TPM;DeviceProvisioning;DeviceEnrollment -cab C:\Users\Public\Documents\MDMDiagnostics\MDMDiagReport.cab

Collection started...
Area: Autopilot        … complete
Area: TPM              … complete
Area: DeviceProvisioning … complete
Area: DeviceEnrollment … complete
Cab file created: C:\Users\Public\Documents\MDMDiagnostics\MDMDiagReport.cab

Per-area variants (if you only need one area)

# Autopilot profile and enrollment logs only
MdmDiagnosticsTool.exe -area Autopilot -cab C:\MDM\Autopilot.cab

# TPM attestation logs (required for self-deploying / White Glove)
MdmDiagnosticsTool.exe -area TPM -cab C:\MDM\TPM.cab

# Runtime provisioning (provisioning packages, multivariant conditions)
MdmDiagnosticsTool.exe -area DeviceProvisioning -cab C:\MDM\DeviceProvisioning.cab

# MDM enrollment logs
MdmDiagnosticsTool.exe -area DeviceEnrollment -cab C:\MDM\DeviceEnrollment.cab

# ZIP output (equivalent to the Settings UI export)
MdmDiagnosticsTool.exe -area "DeviceEnrollment;DeviceProvisioning;Autopilot" -zip "C:\Users\Public\Documents\MDMDiagReport.zip"

What is inside the CAB file

Extract the cab with any archive tool (right-click › Extract All in Windows Explorer, or expand -F:* MDMDiagReport.cab .\output\). Start with the files in priority order — the registry dump resolves most ESP problems without needing to open the ETL traces.

Method 2: Get-AutopilotDiagnostics — decode the cab

Get-AutopilotDiagnostics reads a cab file collected by MdmDiagnosticsTool.exe and produces a human-readable summary of every Autopilot session, policy, app, and error code. It is the fastest way to get from raw cab to “here is what went wrong”.

Run this on your admin workstation after transferring the cab from the target device.

# Step 1 — set execution policy for this session if not already set
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass

# Step 2 — install the script from PSGallery (one-time)
Install-Script -Name Get-AutopilotDiagnostics -Force

# Step 3 — go to root so relative paths work
cd\

# Step 4 — Shift+right-click the cab → "Copy as path", paste after -CABFile
Get-AutopilotDiagnostics -AllSessions -CABFile .\mdmlogs1.cab

# Example with a full path (paste the copied path here)
Get-AutopilotDiagnostics -AllSessions -CABFile "C:\Users\ionutmarin\OneDrive\Intune\Cases\DiagLogs\mdmlogs1.cab"

--- Sample output ---
Autopilot profile settings:
  TenantMatched          : True
  AadTenantId            : xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
  IsAutopilotDisabled    : 0
Win32 app installation:
  CompanyPortal          : Installed (state 3)
  SalesForce CRM         : Error    (state 4)  <— ESP blocker

Method 3: Settings UI export (enrolled device)

The easiest method on a device that has successfully enrolled. No command line needed — any user with access to the work or school account settings can trigger the export.

Output path: C:\Users\Public\Documents\MDMDiagnostics\

The exported file is a zip containing the same files as MdmDiagnosticsTool.exe — registry dump, HTML report, EVTX event logs, and ETL traces. The zip is equivalent to running mdmdiagnosticstool.exe -area DeviceEnrollment;DeviceProvisioning;Autopilot -zip.

Method 4: Intune Admin Center remote collection

For enrolled devices that are online, you can trigger log collection remotely from the Intune portal without touching the device or logging on locally.

After clicking Collect diagnostics, Intune sends a remote command to the device. The device runs the MDM diagnostics collection automatically and uploads the result to Intune. Depending on the device’s check-in cycle this may take 15–30 minutes. Once complete, the cab appears in the device’s Diagnostics section and can be downloaded from the portal.

Method 5: ESP “Collect logs” button and the Windows 11 diagnostics page

During the Enrollment Status Page, a Collect logs button appears if the ESP profile has “Turn on log collection and diagnostics page for end users” set to Yes. The button is visible to the end user (or technician) at the point of failure — no admin intervention required at the machine.

Clicking it lets the user copy the logs to a USB drive. The files are the same as a MdmDiagnosticsTool.exe collection.

On Windows 11 only, if the Autopilot diagnostics page is enabled, pressing CTRL+SHIFT+D at any point during ESP or OOBE opens a detailed diagnostics page showing every app, policy, and certificate deployment in real time — the most readable view available without any additional tools.

Method 6: Hardware hash collection for device registration

Before a device can participate in Autopilot it must be registered — its hardware hash uploaded to the Intune admin center. The hardware hash is a unique fingerprint of the device’s hardware that cannot be spoofed. The Get-WindowsAutoPilotInfo script collects it from WMI and exports it to a CSV for import.

# Create a staging directory
New-Item -Type Directory -Path "C:\HWID"
Set-Location -Path "C:\HWID"

# Add the PowerShell scripts folder to the session PATH
$env:Path += ";C:\Program Files\WindowsPowerShell\Scripts"

# Allow script installation for this process
Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned

# Install the hash collection script from PSGallery (one-time)
Install-Script -Name Get-WindowsAutoPilotInfo

# Collect the hardware hash and export to CSV
Get-WindowsAutoPilotInfo -OutputFile AutoPilotHWID.csv

Hardware hash saved to: C:\HWID\AutoPilotHWID.csv
Import this file in: Intune › Devices › Windows › Enrollment › Autopilot › Devices › Import

After collecting the CSV, import it in Intune Admin Center › Devices › Windows › Enrollment › Windows Autopilot › Devices › Import. Allow up to 15 minutes for the device to appear and for Autopilot to sync the profile assignment.

If the CSV import fails with a Base64 error

Autopilot expects padded Base64. Devices occasionally export unpadded hashes. Validate the hash first:

# Paste the hash value from the CSV between the quotes below
[System.Text.Encoding]::ascii.getstring(
    [System.Convert]::FromBase64String("PASTE_HASH_HERE")
)

# If this throws "Invalid length for a Base-64 char array" —
# add one or two = characters at the end of the hash and retry the import
# Error in Intune: "Cannot convert the literal '[HASH]' to the expected type 'Edm.Binary'"

Registry keys: what the MDM stack writes and what to look for

The registry dump from the cab (MdmDiagReport_RegistryDump.reg) is the fastest path to diagnosing most Autopilot and ESP failures. Open it in Notepad and use Ctrl+F to search for the values below.

Autopilot profile settings

HKLM\SOFTWARE\Microsoft\Provisioning\Diagnostics\Autopilot

ESP FirstSync settings

HKLM\SOFTWARE\Microsoft\Enrollments\{EnrollmentGUID}\FirstSync

ESP Win32 app tracking — finding the blocker

HKLM\SOFTWARE\Microsoft\Windows\Autopilot\EnrollmentStatusTracking\Device\Setup\Apps\Tracking\Sidecar\

InstallationState values are universal across all ESP tracking subkeys:

AutoAdminLogon conflict check

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
Value: AutoAdminLogon

If this value is set to 0, Autopilot breaks completely — the device cannot complete the autologon steps required during provisioning. This is sometimes set by imaging tools or security hardening scripts. If Autopilot fails at the very first OOBE screen, check this value before investigating anything else.

Event IDs: Autopilot channel reference

Event logs are in the Applications and Services Logs › Microsoft › Windows › ModernDeployment-Diagnostics-Provider › Autopilot channel in Event Viewer, or inside the EVTX file extracted from the diagnostic cab.

Error codes and common error messages

Common verbatim error messages and what they mean

System binaries and DLL files involved in Autopilot

Understanding which binary is responsible for each step helps when a failure message is cryptic or when a log references a component by name.

ODJ Connector logs (Hybrid Entra Join only)

For Hybrid Entra Join scenarios, the Intune Connector for Active Directory (ODJ Connector) is responsible for creating the computer object in on-premises AD during Autopilot. When it fails, the logs are in a different location than most engineers expect.

Minimum required connector version: 6.2501.2000.5. Check the installed version in Programs and Features before troubleshooting connector issues — older versions have known failures with current Autopilot profiles.

Policies and settings that break Autopilot

Autopilot is sensitive to policies that interfere with autologon, service state, and MSI installation. The following are the most commonly encountered conflicts, confirmed by Microsoft.

TrustedInstaller conflict: LOB MSI and Win32 apps installing simultaneously

Both LOB (MSI) app deployments and Win32 app installers use the Windows Modules Installer (TrustedInstaller). TrustedInstaller does not allow two installations to run at the same time. If both types attempt to install concurrently during ESP, one will fail with “Another installation is in progress, please try again later.”

The Microsoft Teams Machine-Wide Installer, which is bundled inside the Microsoft 365 Click-to-Run package, is an MSI component that ESP does not track. It can start at the same time as other Win32 MSI installs, causing random and hard-to-reproduce failures.

Mitigations:

• Deploy Microsoft Teams as a separate Win32 app after Autopilot completes (remove from the Click-to-Run bundle).
• Deploy Microsoft 365 Click-to-Run after ESP completes, not as a tracked ESP app.
• Enable “Continue on error” in the ESP profile for apps that are not critical to block on — Teams will not install but ESP will not fail.
• Use Windows Autopilot Device Preparation, which does not use ESP and supports mixed LOB and Win32 deployments.

Proof it worked: what clean output looks like

After resolving the issue and re-running the provisioning flow, collect a new diagnostic cab and run Get-AutopilotDiagnostics. A clean, successful session produces output similar to this:

Autopilot profile:
  TenantMatched          : True
  IsAutopilotDisabled    : 0
  AadTenantId            : xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
  CloudAssignedTenantId  : xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx  (match ✓)

ESP — Device Setup phase:
  CompanyPortal          : Completed  (InstallationState 3)
  CorporateVPN           : Completed  (InstallationState 3)
  SalesApp               : Completed  (InstallationState 3)

ESP — Account Setup phase:
  UserCerts              : Completed
  WiFiProfile            : Completed

Registry check:
  InstallationState = 4 found : 0 occurrences  ✓
  AutoAdminLogon             : 1  ✓
  wlidsvc status             : Running  ✓

In the Intune Admin Center, a fully provisioned device shows as Compliant and the last check-in time is recent (within the last 15 minutes post-OOBE):

References

• Understand and troubleshoot the Enrollment Status Page — Microsoft Learn
• Collect MDM logs (MdmDiagnosticsTool.exe reference) — Microsoft Learn
• Windows Autopilot troubleshooting FAQ — Microsoft Learn
• Add devices to Windows Autopilot (hardware hash) — Microsoft Learn
• Get-AutopilotDiagnostics v5.6 — PowerShell Gallery
• Format-IntuneDiagData (FIDD) — GitHub