คู่มือแก้ปัญหา Microsoft Intune Autopilot และ ESP สำหรับทีม IT Helpdesk: 0x800705B4, TPM Attestation และ Log Files

วินิจฉัยและแก้ปัญหา Microsoft Intune Autopilot และ Enrollment Status Page (ESP) บน Windows 11 ครบทุก error: 0x800705B4, 0x81039023, 0x801c03f3, TPM attestation, Entra ID join failure พร้อมวิธีเก็บ log ด้วย MdmDiagnosticsTool และ CTRL+SHIFT+D สำหรับทีม IT Helpdesk ปี 2026

แก้ Intune Autopilot ESP คู่มือ IT Helpdesk 2026

เอาตรง ๆ ครับ ในปี 2026 การ deploy เครื่อง Windows 11 ผ่าน Microsoft Intune Autopilot กลายเป็นเรื่องปกติของบริษัทขนาดกลาง-ใหญ่ในไทยไปแล้ว แต่ทุกครั้งที่ Enrollment Status Page (ESP) ค้างอยู่ที่ "Identifying" นานเกิน 5 นาที หรือเด้ง error code อย่าง 0x800705B4, 0x81039023, 0x801c03f3 ทีม IT Helpdesk ก็ต้องวิ่งหาคำตอบให้ผู้ใช้แทบทุกครั้ง (และมักจะรีบเพราะเจ้านายรอเครื่องอยู่)

บทความนี้ผมรวบรวมมาจากเคสจริงที่เคยทำในหน้างาน ตั้งแต่การเปิด Autopilot Diagnostic Page ด้วย CTRL+SHIFT+D, การเก็บ log ผ่าน MdmDiagnosticsTool.exe, ไปจนถึงการแก้ปัญหา TPM Attestation, Entra ID join failure และ ESP timeout ที่เจอบ่อยที่สุด ลองอ่านไล่ตามลำดับนะครับ — ผมเรียงตามขั้นตอนที่ใช้งานจริง

เริ่มจากความเข้าใจพื้นฐาน: Autopilot กับ ESP ทำงานยังไง

Windows Autopilot คือกระบวนการ provisioning ที่ทำงานในขั้น Out-of-Box Experience (OOBE) — เครื่องจะวิ่งติดต่อ Microsoft Entra ID และ Microsoft Intune เพื่อรับ profile, นโยบาย, แอป และการตั้งค่าด้านความปลอดภัย

ส่วน Enrollment Status Page (ESP) คือหน้าที่แสดง progress ระหว่างที่ Intune กำลัง apply การตั้งค่าเหล่านั้น แบ่งเป็น 3 phase หลัก:

  1. Device preparation — TPM attestation, Entra ID device registration
  2. Device setup — apply policies, install required apps ที่ assign ระดับ device
  3. Account setup — apply user policies, install user-assigned apps

เมื่อ phase ใด phase หนึ่งล้มเหลว ESP จะแสดง error ทันที ค่า default timeout ของ ESP คือ 60 นาที แต่ที่หลายคนไม่รู้คือ ภายในยังมี internal timeout อีกชุดที่ 1800 วินาที (30 นาที) ซึ่งเป็นต้นเหตุของ 0x800705B4 ในเคสจำนวนมาก

Phase ไหนของ ESP ที่ล้มเหลวบ่อยสุดในปี 2026

จากที่ผมไล่ดูใน Microsoft Q&A และ Tech Community ของปีนี้ ปัญหา ESP ที่ทีม Helpdesk เจอเรียงตามลำดับคือ:

  • ค้างที่ "Identifying" หรือ "Installing apps" จนหมดเวลา (ESP timeout)
  • TPM attestation ล้มเหลวบนเครื่อง Lenovo ThinkPad / HP EliteBook รุ่นปี 2019–2021
  • Entra ID device join ติด DeviceNotFound เพราะ stale object
  • Conditional Access บล็อกผู้ใช้ระหว่าง OOBE
  • Proxy/firewall ปิด endpoint สำคัญ เช่น *.manage.microsoft.com

ขั้นแรกก่อนทำอะไร: เปิด Autopilot Diagnostic Page

อย่าเพิ่งกระโดดไปแก้รายตัวครับ เปิด diagnostic ก่อนเสมอ มันจะประหยัดเวลาคุณ 30 นาทีต่อเคสได้เลย กดปุ่มลัดนี้เพื่อเปิดหน้าที่แสดง policy ทุกตัวที่ tracked, app installation status, และ error code แบบละเอียด:

CTRL + SHIFT + D

ถ้ากดแล้วเงียบ ไม่มีอะไรเกิดขึ้น แสดงว่าตอนสร้าง ESP profile ลืมเปิดออปชั่นที่จำเป็น กลับไปที่ Intune admin center → Devices → Enrollment → Enrollment Status Page → เลือก profile แล้วเปิด:

  • Show app and profile configuration progress = Yes
  • Turn on log collection and diagnostics page for end users = Yes
  • Allow users to use device if installation error occurs = Yes (อันนี้พิจารณาตาม policy ความปลอดภัยขององค์กรนะครับ บางที่เปิดไม่ได้)

เมื่อหน้า diagnostic ขึ้นแล้ว ปุ่ม "Export logs" จะให้คุณสร้างไฟล์ ZIP เพื่อส่งให้ Microsoft Support หรือเก็บไว้วิเคราะห์เอง

เก็บ Log ครบชุดด้วย MdmDiagnosticsTool

ถ้าเครื่องผ่าน OOBE ไปแล้ว หรือคุณเข้าถึงเครื่องได้ผ่าน Shift+F10 ระหว่าง OOBE ก็เปิด Command Prompt แล้วรันคำสั่งนี้ มันจะรวบรวม log ทั้งหมดที่เกี่ยวกับ Autopilot, MDM Enrollment และ TPM ในไฟล์เดียว:

MdmDiagnosticsTool.exe -area Autopilot;DeviceEnrollment;DeviceProvisioning;Tpm -cab C:\Temp\AutopilotLogs.cab

ไฟล์ CAB ที่ได้จะมีไฟล์สำคัญ 3 ไฟล์ที่ผมเปิดบ่อยสุด:

  • MDMDiagReport.xml — แสดง Autopilot profile ที่ Intune apply ลงเครื่องจริง
  • MDMDiagHtmlReport.html — รายละเอียด Policy CSP, certificate, แอป ในรูปแบบที่อ่านง่าย (เปิดในเบราว์เซอร์ได้เลย)
  • MDMDiagReport_RegistryDump.Reg — registry key ทั้งหมดที่เกี่ยวกับ MDM enrollment

ตำแหน่ง Log Files ที่ Helpdesk ควรจำให้ขึ้นใจ

กรณีต้องการดู log แบบ real-time หรือไล่หา error เฉพาะจุด ตำแหน่งเหล่านี้ผมแนะนำให้ทำ shortcut ไว้บนเครื่องของทีม:

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\
C:\ProgramData\Microsoft\Windows\ESPLogs\
C:\Users\Public\Documents\MDMDiagnostics\
C:\Windows\Logs\CBS\

ใน Event Viewer ให้ดูที่ path: Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider และ Provisioning-Diagnostics-Provider > AutoPilot สำหรับ event ที่เกี่ยวกับการลงทะเบียน MDM และ Autopilot โดยตรง

แก้ปัญหา ESP Timeout และ Error 0x800705B4

พูดตรง ๆ 0x800705B4 คือ error ที่กำกวมที่สุดเท่าที่เคยเจอ เพราะมีต้นเหตุได้หลายแบบ ทีม Helpdesk ต้องแยกให้ออกก่อนว่ามาจาก timeout หรือ TPM attestation

วิธีแยกง่าย ๆ คือดูว่า error เกิดในช่วง "Device preparation" (มักเป็น TPM) หรือช่วง "Installing apps" (มักเป็น timeout)

กรณีที่ 1: ESP ค้างเพราะมีแอปเยอะเกินไป

นี่คือสาเหตุอันดับหนึ่งของจริงในปี 2026 หลายองค์กรตั้ง required apps ไว้กว่า 20 ตัว ซึ่งแต่ละตัวกินเวลาติดตั้ง 2–4 นาที รวมแล้วเกิน 60 นาทีง่าย ๆ วิธีแก้:

  1. ใน ESP profile เลือก Block device use until these required apps are installed = "Selected" แทนที่จะเป็น "All"
  2. เลือกเฉพาะแอปที่จำเป็นจริง ๆ เช่น VPN client, EDR/AV, แอป LOB หลัก
  3. แอปอื่น ๆ ให้ assign แบบ available หรือ required แต่ไม่ track ใน ESP

ส่วนตัวผมตั้งไว้ไม่เกิน 5 ตัวเสมอ — เกินกว่านั้นไม่คุ้มค่ากับการที่ผู้ใช้ต้องรอ

กรณีที่ 2: แอปบางตัวค้าง — ตรวจ IntuneManagementExtension.log

เปิดไฟล์ log ด้วย CMTrace.exe หรือ One TraceView Utility (ผมชอบ CMTrace มากกว่า มัน highlight error สีแดงให้):

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log

คำที่ควรค้นหา (Ctrl+F):

  • [Win32App] — ติดตามขั้นตอน download/install ของ Win32 app
  • ExecManager — แสดงคำสั่ง install command line ที่รันจริง
  • DetectionResult — ผล detection rule หลัง install
  • MSI installation failed หรือ Exit Code: 1603 — แอปติดตั้งล้มเหลว

สาเหตุที่เจอบ่อยของแอปค้างมีอยู่ 3 อย่าง: คำสั่ง silent install ผิด, แอปต้อง reboot ก่อนตรวจ detection, และ detection rule เขียน path ผิด (อันนี้เจอเยอะที่สุด เพราะคนชอบลืมว่า %ProgramFiles% กับ %ProgramFiles(x86)% มันคนละที่กัน)

กรณีที่ 3: Co-management และ Configuration Manager Client

ถ้าองค์กรของคุณใช้ co-management ระหว่าง Intune กับ Configuration Manager แล้ว ESP ค้างที่ "Identifying" หรือ "Installing apps" ราว ๆ 30 นาที — ส่วนใหญ่จะติด internal timeout ของ ESP (1800 วินาที) ที่แยกจาก Intune timeout

วิธีแก้:

  1. ตรวจ BITS throttling: GPO ที่จำกัดแบนด์วิดท์ของ BITS ในเวลาทำงานอาจทำให้ CCMSetup.exe ดาวน์โหลดไม่ทัน
  2. ดู log: C:\Windows\ccmsetup\Logs\ccmsetup.log
  3. พิจารณาแยก co-management ออกจาก Autopilot phase แล้วให้ install หลัง ESP จบ — เป็นวิธีที่ผมชอบใช้ที่สุด สะอาดและ debug ง่าย

แก้ปัญหา TPM Attestation Failure

เรื่อง TPM นี่ต้องเข้าใจก่อนว่า attestation มีผลเฉพาะ Self-deploying mode และ Pre-provisioning (White Glove) เท่านั้น สำหรับ User-driven mode มาตรฐาน TPM attestation ไม่ได้บังคับ

เมื่อ TPM attestation ล้มเหลว จะแสดง error เหล่านี้:

  • 0x800705B4 — ในช่วง device preparation
  • 0x81039023 — TPM attestation timeout บน Windows 11
  • 0x80190190 — บางครั้งเจอร่วมกับ 0x800705B4

เช็คลิสต์การแก้ TPM Attestation

  1. อัปเดต TPM firmware ผ่านหน้า driver ของ OEM (Lenovo Vantage, HP Image Assistant, Dell Command Update) — รุ่นที่มีปัญหา attestation บ่อยคือ Lenovo ThinkPad ปี 2019–2021, HP EliteBook G6/G7 และ Dell Latitude 5400/7400 series
  2. Clear TPM ใน BIOS/UEFI ถ้าเครื่องเคยถูกใช้งานมาก่อน — ใน Windows ก็ใช้ tpm.msc → Clear TPM แต่ในกรณี OOBE ต้องทำผ่าน BIOS โดยตรงนะครับ
  3. ตั้งเวลา BIOS ให้ถูก — TPM attestation ใช้ certificate ที่ time-sensitive ถ้า clock skew เกิน 5 นาทีจะ fail ทันที (ข้อนี้เคยทำให้ผมหัวล้านไปครึ่งหัวมาแล้ว)
  4. ตรวจสอบ TPM mode — TPM 2.0 ที่ตั้งเป็น "discrete" ทำงานได้ดีกว่า "firmware TPM (fTPM)" ในเครื่องเก่า

คำสั่ง PowerShell ตรวจสถานะ TPM (รันใน Shift+F10 ระหว่าง OOBE):

Get-Tpm
Get-WmiObject -Namespace "root\cimv2\security\microsofttpm" -Class Win32_Tpm | Format-List *

ถ้าผล TpmReady = False หรือ ManufacturerVersion ต่ำกว่าเวอร์ชันที่ Microsoft แนะนำ ให้ flash firmware ใหม่ก่อน retry

แก้ปัญหา Entra ID Join Failure (0x801c03f3)

error 0x801c03f3 มักจะมาคู่กับข้อความนี้:

{"Code":"AuthenticationError","Subcode":"DeviceNotFound","Message":"A device with the expected device identifiers was not found"}

แปลแบบบ้าน ๆ คือ Entra ID หา device object ที่คาดหวังไม่เจอ มีต้นเหตุได้ 4 อย่างหลัก ๆ:

1. Stale Device Object

เครื่องเคยถูก enroll มาก่อน object เก่ายังค้างอยู่ ทำให้ device identity (hardware hash + serial) ขัดกัน วิธีแก้:

  1. ใน Intune admin center → Devices → All devices → ค้นด้วย serial number
  2. ลบ device record เก่า
  3. ใน Entra admin center → Devices → All devices → ลบ object เก่าด้วยเช่นกัน
  4. รอ 15 นาทีให้ sync แล้วค่อย retry (อย่าใจร้อน — ผมรีบจน sync ไม่ทันมาแล้ว)

2. Hardware Hash ไม่ได้อยู่ใน Autopilot Devices

ถ้า IT/OEM ลืม upload hardware hash หรือ vendor ส่งไฟล์ผิด เครื่องจะไม่ match กับ Autopilot profile ตรวจด้วย PowerShell บนเครื่องอื่น:

Connect-MgGraph -Scopes "DeviceManagementServiceConfig.Read.All"
Get-MgDeviceManagementWindowsAutopilotDeviceIdentity -Filter "contains(serialNumber,'PFXXXX123')"

ถ้าไม่เจอ ต้องเก็บ hardware hash จากเครื่องด้วย Get-WindowsAutopilotInfo script แล้ว upload เข้า Intune ใหม่

3. Conditional Access บล็อก Device Registration

policy CA บางตัวบังคับ MFA หรือ compliant device สำหรับ "Microsoft Intune Enrollment" ระหว่าง OOBE — ผู้ใช้อาจทำ MFA ผ่าน FIDO2 key หรือ Windows Hello ไม่ได้ในขั้นนี้ วิธีแก้:

  1. สร้าง CA policy exclusion สำหรับ cloud apps: Microsoft Intune Enrollment และ Microsoft Intune
  2. หรือใช้ Temporary Access Pass (TAP) สำหรับผู้ใช้ที่ต้อง onboard ใหม่

4. Per-User Device Limit

Entra ID มี per-user device limit (default 50) เช็คใน Entra → Devices → Device settings → "Maximum number of devices per user" ถ้าผู้ใช้มีอุปกรณ์ครบโควตาแล้วจะ join ไม่ได้ — ลบเครื่องเก่าออก หรือเพิ่ม limit ขึ้นไปก็ได้ครับ

แก้ปัญหา Network และ Proxy ระหว่าง OOBE

ระหว่าง OOBE Windows ยังไม่ได้ apply proxy setting จาก GPO หรือ Intune (เพราะมันยังไม่ join domain หรือ enroll เลย) ถ้าเครือข่ายขององค์กรบังคับใช้ proxy คุณต้องเตรียม WPAD หรือ PAC file ไว้บน DHCP option 252

Endpoint ที่ต้องเปิดใน Firewall (Allowlist)

  • *.manage.microsoft.com — Intune endpoint หลัก
  • *.azureedge.net — CDN สำหรับ download payload
  • *.officeconfig.msocdn.com
  • login.microsoftonline.com — Entra ID authentication
  • graph.microsoft.com
  • device.login.microsoftonline.com
  • enterpriseregistration.windows.net
  • portal.manage.microsoft.com
  • www.msftconnecttest.com — NCSI

ถ้าใช้ Wi-Fi ที่ต้องการ certificate-based authentication (เช่น 802.1X) จะใช้ใน OOBE ไม่ได้แบบตรง ๆ ต้องสร้าง Wi-Fi profile บน Autopilot Profile หรือใช้ pre-provisioned cert จาก SCEP/PKCS connector

ใช้ Collect Diagnostics จาก Intune Portal

ฟีเจอร์ที่ผมว่ามีประโยชน์มากในปี 2026 คือ "Collect Diagnostics" remote action ที่ดึง log จากเครื่องโดยไม่รบกวนผู้ใช้เลย

  1. ใน Intune admin center → Devices → ค้นเครื่องที่มีปัญหา
  2. คลิก "..." → Collect Diagnostics
  3. รอประมาณ 5–15 นาที จากนั้น download ZIP จาก Device Diagnostics

เครื่องเดียวเก็บได้ 1 ชุด log ต่อวัน เก็บไว้ 28 วัน รวมสูงสุด 10 ชุด นอกจากนี้ยังเปิด auto-collect on Autopilot failure ได้ใน Tenant administration → Settings → Diagnostics — ทำให้เมื่อ ESP fail ระบบจะ upload log อัตโนมัติให้ทีม Helpdesk เข้าไปดูได้ทันที (อย่าลืมเปิดอันนี้ ทำชีวิตง่ายขึ้นมาก)

Decision Tree สำหรับ Helpdesk Tier 1

เพื่อให้ทีมหน้างานวิ่งเร็ว ใช้ flow นี้กรองเคสได้เลย:

  1. ESP ไม่ขึ้นเลย เครื่องค้างที่ "Setting up your device" → เช็ค network, proxy, endpoint allowlist
  2. ESP ค้างที่ Identifying > 5 นาที → กด CTRL+SHIFT+D ดูจำนวน apps ที่ tracked / ตรวจ IntuneManagementExtension.log
  3. ESP fail ใน Device preparation → TPM attestation issue → ตรวจ Get-Tpm, อัปเดต TPM firmware
  4. ESP fail ที่ "Joining your organization" → Entra ID join issue → ตรวจ stale object, hardware hash, CA policy
  5. ESP ผ่าน แต่ user sign-in fail → MFA หรือ user license issue → ตรวจ Entra Sign-in Logs

Best Practices ลด ESP Failure ในระยะยาว

  • Pilot ใหม่ทุก Windows feature update — ทดสอบ Autopilot ใหม่ทุกครั้งที่ Microsoft ปล่อย Windows 11 24H2/25H2 หรือ Intune service update
  • กำหนด required apps ใน ESP ≤ 5 ตัว — แอปอื่นใช้ available หรือ deferred
  • ตั้ง ESP timeout เป็น 90 นาที สำหรับเครือข่ายที่ช้า หรือเครื่องที่ต้องลง LOB ขนาดใหญ่
  • เปิด Auto-collect Diagnostics เพื่อให้ทีมมี log ทันทีเมื่อมีเคส
  • สร้าง Conditional Access exclusion สำหรับ Microsoft Intune Enrollment apps แต่ใช้ "Require compliant device" ใน CA หลักหลังจาก ESP จบแล้ว
  • มี knowledge base ภายในองค์กร สำหรับ error code ที่เคยเจอ — จากประสบการณ์ผม อันนี้ลด MTTR ของเคสซ้ำได้กว่า 50% จริง ๆ

ทิ้งท้ายนิดนึงครับ — Intune Autopilot ไม่ใช่ระบบที่ "set and forget" ผมแนะนำให้ทีม Helpdesk ทำ dry-run ทุกไตรมาส กับเครื่องตัวอย่างจริง เพื่อให้แน่ใจว่า profile ยังใช้ได้กับ Windows update รุ่นล่าสุด เพราะ Microsoft ขยับ behavior ของ ESP แทบทุก feature update

คำถามที่พบบ่อย (FAQ)

Q: error code 0x800705B4 ใน Autopilot คืออะไร แก้ยังไง?

A: 0x800705B4 มี 2 ความหมายคือ ESP timeout (เกิน 30 นาทีของ internal timeout) หรือ TPM attestation failure ให้แยกด้วยตำแหน่งที่ error เกิด ถ้าเกิดในช่วง "Device preparation" ให้ตรวจ TPM firmware และ clock skew ถ้าเกิดในช่วง "Installing apps" ให้ลดจำนวน required apps ใน ESP profile หรือเพิ่ม timeout เป็น 90 นาที

Q: เปิด Autopilot Diagnostic Page ระหว่าง ESP ยังไง?

A: กด CTRL + SHIFT + D บนหน้า ESP ถ้ากดแล้วเงียบไม่มีอะไรขึ้น แสดงว่า ESP profile ไม่ได้เปิด "Turn on log collection and diagnostics page for end users" ต้องกลับไปแก้ใน Intune admin center และ provision เครื่องใหม่

Q: log Autopilot ESP เก็บไว้ที่ไหน?

A: log หลักอยู่ที่ C:\ProgramData\Microsoft\Windows\ESPLogs ส่วน Intune Management Extension log อยู่ที่ C:\ProgramData\Microsoft\IntuneManagementExtension\Logs และ MDM diagnostics อยู่ที่ C:\Users\Public\Documents\MDMDiagnostics หรือใช้ MdmDiagnosticsTool.exe -area Autopilot;DeviceEnrollment;Tpm -cab C:\Temp\Logs.cab รวบรวมทุก log ในไฟล์เดียวก็ได้

Q: error 0x801c03f3 DeviceNotFound แก้ยังไง?

A: error นี้หมายความว่า Entra ID หา device object ที่คาดหวังไม่เจอ ตรวจ 4 จุด: (1) ลบ stale device object ใน Entra ID และ Intune (2) ตรวจว่า hardware hash อยู่ใน Autopilot devices ของ tenant (3) สร้าง Conditional Access exclusion สำหรับ Microsoft Intune Enrollment app (4) ตรวจ per-user device limit ใน Entra Device Settings

Q: ต้องเปิด endpoint อะไรบ้างใน firewall ให้ Autopilot ทำงานได้?

A: endpoint หลักที่ต้อง allow คือ *.manage.microsoft.com, *.azureedge.net, login.microsoftonline.com, graph.microsoft.com, device.login.microsoftonline.com, enterpriseregistration.windows.net และ www.msftconnecttest.com สำหรับ NCSI ถ้าใช้ Microsoft Store apps หรือ Win32 apps ขนาดใหญ่ต้องเปิด CDN domains เพิ่มด้วย

Q: ESP ค้างที่ "Identifying" นานมาก ต้องทำยังไง?

A: ส่วนใหญ่เกิดจากจำนวน required apps ใน ESP มากเกินไป กด CTRL+SHIFT+D เพื่อดูจำนวน apps ที่ tracked ถ้าเกิน 10 ตัวให้พิจารณาย้ายแอปที่ไม่จำเป็นออกจาก ESP โดยตั้ง "Block device use until these required apps are installed" = "Selected" แล้วเลือกเฉพาะแอป security/VPN/LOB หลัก ส่วนแอปอื่นยังคง assign แบบ required ปกติให้ติดตั้งหลัง ESP จบ

เกี่ยวกับผู้เขียน Editorial Team

Our team of expert writers and editors.