Windows Autopilot 注册失败排查完全指南（2026）：ESP 卡死、错误代码与白手套部署修复

更新时间：2026年6月19日

Windows Autopilot 注册失败几乎总是由这五类根因之一引起：设备硬件哈希未正确上传、目标 Entra ID 用户许可证或组成员资格缺失、Enrollment Status Page (ESP) 在等待某个超时的 Win32 应用或脚本、条件访问策略在零接触场景中触发 MFA，或者本地网络阻断了关键的 Microsoft 端点。本文按 IT 运维的真实排查顺序，把 Intune Autopilot 2026 版本中最常见的失败模式拆解为可执行的修复步骤，覆盖错误代码、日志收集、ESP 调试和白手套（白手套预配置 / Pre-provisioning）回退方案。说实话，我自己上次给一批 Surface 现场重做 Autopilot 时，光是 0x80180014 这一个代码就处理了三天，所以这篇是踩坑笔记，不是漂亮话。

• Intune 2025 年 11 月起将 Pre-provisioning（原"白手套"）默认要求 Windows 11 23H2 或更新版本，旧 22H2 镜像将提前进入失败路径。
• 错误代码 0x80180014 和 0x801c03ea 几乎总是 MDM 注册阶段许可证或组分配延迟所致，不要在客户端反复重置。
• ESP 卡在"账户设置 / Account setup"超过 60 分钟，95% 的情况是某个 Win32 应用安装失败或对依赖检测脚本超时。
• 从 2026 年 1 月起，Autopilot 设备预登记必须使用新的 Hardware Hash V2 或 Corporate Identifier；旧 CSV 在新租户上传会静默丢弃。
• 诊断必跑：mdmdiagnosticstool.exe -area "Autopilot;DeviceEnrollment;TPM" -cab 一次性收集 90% 你需要的证据。
• 不要在故障设备上反复 Sysprep；用 Intune 的"Reset device"或全新映像，比手动清理 PII 数据更快、更可靠。

Autopilot 注册流程：失败发生在哪一步

排查 Autopilot 失败的前提是知道它现在卡在哪一个阶段。Microsoft Intune 2026 的端到端流程可以分为四个清晰的关卡，每一个都有独立的失败信号和日志位置：

1. OOBE 与 Autopilot 配置文件下载： 设备首次联网后，会用硬件哈希向 Autopilot 服务请求配置文件（profile）。如果哈希未登记、租户错误或设备在错误的部署组，OOBE 会跳到普通本地账户流程，这就是"完全没进 Autopilot"的症状。
2. Entra ID（旧 Azure AD）加入： 用户输入 UPN 后，设备执行 Entra ID Join 或 Hybrid Join。失败常见为 0x801c03ea（许可证缺失）、0x801c044e（用户不在允许加入设备的组）。
3. MDM 注册： 设备调用 Intune MDM 端点 manage.microsoft.com 注册并下载策略。0x80180014 几乎全部发生在这一步。
4. Enrollment Status Page (ESP)： 显示三段进度，依次是设备准备 / 设备设置 / 账户设置。账户设置阶段会等待所有"被追踪的应用"安装完成，超时默认 60 分钟。

动手前先问设备主人一句：屏幕上看到的是"组织登录页"还是"准备您的设备"？这一句话能省下半小时的猜测。如果你还要在公司内同时处理 VPN 和 Autopilot 配合的问题，我们之前写的企业 Always On VPN 与 Intune 配合的排查指南把零接触场景下 VPN 触发的常见冲突列得很全，可以与本文配合使用。

硬件哈希上传与设备登记错误

Autopilot 的第一关是设备能不能识别"自己属于这家公司"，依据就是上传到租户的硬件哈希（Hardware Hash，又称 4K HH）。2026 年的新坑主要有三类：

哈希格式变更（V2）

2026 年 1 月起，Intune 接受的硬件标识有两种：传统 4K Hardware Hash V1 和新的 V2（包含 TPM 2.0 证明信息）。OEM 直接推送（OEM Direct）和 Microsoft Partner Center 自动上传的设备使用 V2；老的 PowerShell Get-WindowsAutoPilotInfo 默认仍生成 V1。如果你混用同一 CSV，新租户会忽略不规范行而不报错（我前不久就被这条静默丢弃坑过半个下午）。最稳的做法是分两次导入：

# 安装最新模块（2026.4 及以上才支持 V2 标志）
Install-Script -Name Get-WindowsAutoPilotInfo -Force

# 显式生成 V2 哈希（推荐）
Get-WindowsAutoPilotInfo.ps1 -OutputFile C:\hash-v2.csv -AppendV2

# 然后用 Intune 控制台分批导入并标记不同的 Group Tag，
# 失败时可以一眼看出是格式问题还是策略问题

租户配额与导入延迟

许多团队遇到"哈希上传成功但设备分配不到配置文件"。控制台显示"已分配"，设备在 OOBE 时却得不到 profile。原因：Autopilot 的设备同步任务在大租户上可能延迟 15–45 分钟。开个工单之前，先在 PowerShell 强制同步：

Connect-MgGraph -Scopes "DeviceManagementServiceConfig.ReadWrite.All"
Invoke-MgGraphRequest -Method POST `
  -Uri "https://graph.microsoft.com/beta/deviceManagement/windowsAutopilotSettings/sync"

序列号重复与"Ghost 设备"

主板更换、镜像克隆或 Surface 系列保修换机会导致同一序列号出现在多个租户。Intune 的去重逻辑会优先保留最新登记记录，但旧记录会保留"已分配"状态，造成 OOBE 显示"该设备已注册到其他组织"。处理方式：用 Get-AutopilotDevice -Serial <SN> 查询所有匹配项，删除旧条目，再让设备重启进 OOBE。

ESP 卡死最常见的 6 种原因

ESP（Enrollment Status Page）的"账户设置"阶段，是 IT 运维最害怕的一屏。它会在静默状态下等待最多 60 分钟，然后要么放行，要么显示通用错误。下面这六种根因，覆盖了我处理过的 ESP 卡死工单的 90% 以上：

症状	根因	初步定位方法	修复
卡在 "Identifying"	哈希不匹配或 profile 未分配	查看 OOBE 日志中 AutopilotV2 条目	重新分配 profile、强制同步
卡在 "Preparing your device"	TPM Attestation 失败	tpm.msc 状态、固件 TPM 是否启用	BIOS 启用 fTPM、升级固件
卡在 "Setting up your device"	某条 DCM 策略冲突	Intune → Devices → Configuration → Per-setting status	移除冲突策略并重试
卡在 "Account setup" 5–60 分钟	必装的 Win32 应用安装失败	客户端 IME 日志 / Win32 app status	修复 intunewin 检测规则
"Something went wrong" + 0x80180014	MDM 注册被 CA 策略阻断	Entra 登录日志 → 注册流	排除 Autopilot 在 CA 范围外
"Account setup" 完成但桌面无图标	跟踪应用未标记 "Block until installed"	ESP profile 中"被跟踪应用"列表	调整 ESP profile

2026 年新增的复杂度来自 Win32 App Supersedence（应用替代）：被替代的旧版本若被 ESP 跟踪，会因为"既要卸载又要安装"产生死循环。检查方法是 Intune Apps → Monitor → Discovered apps，看是否有同名两个版本同时显示 "Required"。如果你刚好也在升级 Windows 11，可以参考Windows 11 企业更新故障排除指南，里面对补丁与 ESP 跟踪应用之间的相互影响做了详细案例。

2026 年最常见的 Autopilot 错误代码速查

把错误代码记在手边能让排查效率提高一倍。下面是 2026 年 Intune 工单中频率最高的代码，配以"先查什么"的提示：

• 0x80180014： MDM 注册失败。99% 是用户没有 Intune 许可证、不在 MDM Scope 中，或者条件访问策略阻断了注册。首先检查 Entra ID 登录日志中"Microsoft Intune"应用是否有失败记录。
• 0x801c03ea： 不能将设备加入 Entra ID。许可证（Entra ID P1/P2 或 EMS）缺失，或"设备可以加入的用户"配置不正确。
• 0x801c044e： 用户超过设备配额。默认每用户 50 台，超出后即使账户合法也会注册失败。修改 Entra ID → Devices → Device settings → "Maximum number of devices per user"。
• 0x800705b4： ESP 超时。这并不是真正的错误，而是 Win32 应用未在 60 分钟内安装完成。延长 ESP 超时并修复目标应用。
• 0x80070774： DNS / 网络解析失败。设备无法到达 login.microsoftonline.com 或 enterpriseregistration.windows.net。检查代理与 SSL 拦截。
• 0x80180005： 设备已在另一 MDM 中注册。常见于二手机器或更换租户后未清理。需要在客户端 dsregcmd /leave 然后重新 Sysprep。
• 0xC1036501（新）： 2026 年 3 月起出现，对应 ESP 配置文件中 blocking apps 与 Autopilot V2 profile 的版本不匹配。需要重新创建 ESP profile。

白手套（Pre-provisioning）部署失败修复

Pre-provisioning（前身白手套 / White Glove）允许技术人员在公司侧先完成大部分配置，再封箱寄给最终用户。2026 年它有三个关键变化值得 IT 团队留意：

• 必须使用 Windows 11 23H2 或更高版本。Microsoft 在 2025 年 11 月正式弃用 22H2 的预配置技术预览。
• 预配置阶段不再支持用户分配的应用，只识别"设备组目标"应用（Device-assigned）。这意味着部分企业商店的用户许可证软件（如 Adobe Acrobat 命名用户版）必须改为设备目标或推迟到用户阶段。
• 从 2026 年 4 月起，Pre-provisioning 完成后产生的 reseal 包包含 TPM 证明令牌，如果在传输过程中超过 30 天未交付给最终用户，令牌过期，需要重新走一遍预配置。

"在预配置阶段安装应用 X 时失败"

这是预配置失败最常见的两个原因：

1. 应用按用户分配： 把所有 ESP 跟踪应用改为分配给设备组（按 Autopilot Group Tag 动态成员资格）。
2. 依赖关系链断裂： Win32 应用依赖于另一个 Win32 应用，但被依赖者本身也未在预配置阶段完成。Intune 不会跨阶段串行依赖。

# 用 Graph 查询当前 ESP 跟踪应用并打印谁是 user-assigned
Connect-MgGraph -Scopes "DeviceManagementApps.Read.All"

$apps = Invoke-MgGraphRequest -Method GET `
  -Uri "https://graph.microsoft.com/beta/deviceAppManagement/mobileApps?\$top=200"

$apps.value |
  Where-Object { $_.assignments } |
  ForEach-Object {
      foreach ($a in $_.assignments) {
          [PSCustomObject]@{
              App     = $_.displayName
              Target  = $a.target.'@odata.type'
              Intent  = $a.intent
          }
      }
  } | Format-Table -AutoSize

Reseal 后用户阶段失败

预配置成功，封箱发给用户，用户登录后却卡死，通常是 用户 ESP 配置文件（不同于设备 ESP）所跟踪的应用对 Entra 用户许可证有依赖。用 %ProgramData%\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log 看具体哪一个 appId 报 4xx。

条件访问与 MFA 阻断零接触

条件访问（Conditional Access，CA）是 2026 年 Autopilot 失败排查中最容易被忽略的根因。安全团队为了合规启用"所有应用都要求 MFA / 设备合规"，但 Autopilot 注册流本身需要 在设备成为合规之前 写入策略，这就是典型的鸡生蛋问题。

诊断步骤：

1. 打开 Entra ID → Sign-in logs，过滤 "Application: Microsoft Intune" 和失败用户。
2. 查看 "Conditional Access" 标签页，看具体哪条策略触发了 Block 或 Require。
3. 常见误触发："All apps" + "Require compliant device"。新设备显然还没合规。

正确的做法是为 Autopilot 流量配置一条排除：在 CA 策略的 "Cloud apps" 排除 Microsoft Intune Enrollment（First-party app）。Microsoft 现在还提供了一个"Device registration"过滤器（在 Conditions → Filters for devices），可以基于注册阶段动态豁免。Microsoft 官方 Autopilot 已知问题列表会持续更新这些 CA 配合细节。

使用 MDM 诊断日志定位根因

诊断工具是 Autopilot 排查的核心武器。Windows 11 自带 MDMDiagnosticsTool.exe，可以一次性收集事件日志、注册表、Autopilot 配置文件、ESP 状态与策略 CSP。命令行用法：

# 完整收集（推荐）
MDMDiagnosticsTool.exe -area "Autopilot;DeviceEnrollment;DeviceProvisioning;TPM" `
  -cab C:\diag-%COMPUTERNAME%.cab

# 仅看实时 Autopilot 状态
MDMDiagnosticsTool.exe -autopilot

展开 cab 后，重点看：

• MDMDiagReport.xml：顶层概览，包含 Entra ID Join 状态、MDM 注册 URL、用户主体。
• MDMDiagHtmlReport.html：人类可读，包含已下发策略列表。失败策略会用红色标记。
• microsoft-windows-shell-core%4operational.evtx：OOBE 真实步骤序列。
• microsoft-windows-aad%4operational.evtx：Entra ID 加入失败的真实错误代码（不要看 OOBE 屏幕上的"友好"提示）。
• microsoft-windows-moderndeployment-diagnostics-provider%4autopilot.evtx：这才是 Autopilot 自己写的日志，最权威。

对于 ESP 卡死场景，另外要在客户端拿 C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log 和 AgentExecutor.log。Win32 应用安装失败的真正 exit code 都在这里。如果你想深入了解 Intune 日志的字段含义，可以查阅 Microsoft Intune 帮助台操作员官方文档。

在 Intune 控制台远程触发收集

设备已离开 IT 之手时，可以在 Intune → Devices → 选中设备 → "Collect diagnostics" 远程触发，最多 60 分钟内 cab 会上传到控制台，不需要用户操作。结合Active Directory 账户锁定排查指南中介绍的 PowerShell 日志关联手法，可以在不打扰用户的前提下找到 Hybrid Join + 频繁锁定这种复合故障的根源。

何时该重置、何时该重新映像

排查到一定深度之后，决定"放手"反而是关键技能。下面这个判断框架来自我们 IT 团队 2025–2026 年的内部统计：

• 从 OOBE 屏幕就没看到品牌页： 哈希 / 配置文件问题。不要重置，回到控制台修复源头。
• ESP 第一段（Device prep）失败： TPM / BitLocker 状态混乱。优先用 Intune 的 "Wipe" + "Continue at PowerOn"，或者重新映像。
• ESP 账户设置阶段超时 ≥3 次： 锁定具体应用，修复后用 "Fresh Start" 而不是 Reset。Reset 不会清掉 MDM 隔离状态。
• 设备处于 Hybrid Join 失败状态： 通常需要在域控侧 nltest /sc_reset 然后客户端 dsregcmd /forcerecovery。如果是云端注册被卡，可以参考 Entra Hybrid Join 故障排除官方文档。

2026 年新增的 Autopilot Device Preparation (V2) 提供了"Reset and reapply Autopilot"的一键流，但只在租户启用 V2 且设备运行 Windows 11 24H2 时可用。它的优势是不需要重启 OOBE，可以在用户已使用一段时间后远程重置回零接触状态。

常见问题解答

错误 0x80180014 到底是什么意思？

0x80180014 是 MDM 注册被拒绝的通用代码。在 2026 年 Intune 中，90% 的情况是用户没有 Intune 许可证、不在允许注册的组里，或者条件访问策略阻断了 "Microsoft Intune Enrollment" 应用。先去 Entra ID 登录日志里搜该用户、过滤"Microsoft Intune"应用，查看真实 CA 失败原因。

为什么我的 Autopilot ESP 一直卡在 "Identifying"？

设备在向 Autopilot 服务请求配置文件但没有匹配。原因通常是硬件哈希未上传、设备不在分配给该 profile 的 Entra ID 组、或者租户未完成同步。在客户端按 Shift+F10 运行 mdmdiagnosticstool.exe -autopilot 可以看到具体匹配状态；控制台侧用 Graph 的 sync 命令强制刷新。

白手套 / Pre-provisioning 部署需要哪个 Windows 版本？

2026 年起 Intune 正式要求 Windows 11 23H2 或更新版本。22H2 仍可启动预配置但不再受支持，Microsoft 不修复其问题。如果你的 OEM 映像还是 22H2，应优先升级镜像或在预配置阶段加入功能更新策略。

Autopilot 部署需要多长时间？

典型 Autopilot 端到端在 30–60 分钟之间，主要时间花在 ESP 账户设置阶段安装必装应用。我们建议把 ESP 跟踪应用控制在 5 个以内（< 1 GB 总大小），其余应用走"Available"模式，把首启时间压到 20 分钟以下。

如何重置已注册的 Autopilot 设备？

用 Intune 控制台的 "Wipe" 操作，并启用 "Continue at PowerOn"，这会让设备自动回到 Autopilot OOBE 流程。不要 在客户端用 sysprep /generalize，它会破坏 Entra ID 加入和 BitLocker TPM 状态。Windows 11 24H2 + Autopilot V2 也提供了一键 "Reset and reapply" 远程操作。

硬件哈希 V1 和 V2 有什么区别？

V1 是传统 4K Hardware Hash，仅包含设备识别信息；V2 额外包含 TPM 2.0 证明数据，使设备能直接进入"已认证"状态，避免 ESP 阶段重新做 TPM 证明。2026 年起 OEM 直接推送和 Partner Center 自动上传均默认使用 V2；老的 PowerShell 脚本默认仍生成 V1，可以加 -AppendV2 参数升级。