عیب‌یابی استقرار Windows Autopilot در Intune: راهنمای کامل تکنسین‌های هلپ دسک (۲۰۲۶)

آخرین به‌روزرسانی: ۲ ژوئن ۲۰۲۶

اگر استقرار Windows Autopilot در Intune شکست خورده است، در ۸۰٪ موارد ریشه مشکل یکی از این سه چیز است: پروفایل Autopilot به دستگاه assign نشده، صفحه Enrollment Status Page (ESP) روی نصب یک Win32 app گیر کرده، یا hash سخت‌افزار با rebuild برد اصلی تغییر کرده است. صادقانه بگویم، در سه سال گذشته‌ام در میز کمک تقریباً همه‌ی این سناریوها را زنده دیده‌ام. در این راهنما، با تمرکز بر تجربه میدانی و فلوی جدید Autopilot Device Preparation که از سال ۲۰۲۴ به‌صورت GA منتشر شد، روش تشخیص دقیق هر سه سناریو، خواندن کدهای خطای ESP و استخراج لاگ‌های MDM را گام‌به‌گام مرور می‌کنیم.

• پنل Intune در مسیر Devices > Enrollment > Windows enrollment > Autopilot deployments وضعیت دقیق هر دستگاه و کد خطای آخر را نمایش می‌دهد و اولین جایی است که باید بررسی شود.
• کدهای خطای ESP معمولاً به فرمت 0x800705B4 (timeout)، 0x80180014 (شکست join Entra ID) و 0x81036502 (شکست نصب Win32 app اجباری) هستند.
• فلوی جدید Autopilot Device Preparation نیازی به آپلود hash سخت‌افزار ندارد و فقط برای دستگاه‌های Entra ID-joined و user-driven کار می‌کند.
• برای استخراج لاگ کامل، دستور MdmDiagnosticsTool.exe -area Autopilot;TPM -cab C:\Temp\AutopilotLogs.cab همه چیز را در یک فایل CAB جمع می‌کند.
• تنظیم سخت‌گیرانه‌ی ESP روی Block device use until all apps and profiles are installed با timeout پیش‌فرض ۶۰ دقیقه، شایع‌ترین علت پیام «Something went wrong» است.

Autopilot در سال ۲۰۲۶ چه تفاوتی کرده است؟

Windows Autopilot در سال ۲۰۲۶ دو فلوی موازی دارد: فلوی کلاسیک (مبتنی بر hash سخت‌افزار و پروفایل deployment) که از ویندوز ۱۰ به ارث رسیده، و فلوی جدید Autopilot Device Preparation (AP-DP) که در سپتامبر ۲۰۲۴ به GA رسید و در طول ۲۰۲۵ به‌سرعت در سازمان‌های متوسط جایگزین فلوی کلاسیک شد. مهم‌ترین تفاوت برای هلپ دسک این است که در AP-DP دیگر نیازی نیست hash سخت‌افزار را به‌صورت دستی یا از طریق OEM وارد Intune کنید؛ دستگاه با ورود کاربر در صفحه OOBE و کافی بودن لایسنس و عضویت در یک گروه امنیتی مناسب، خودش provision می‌شود.

برای هلپ دسک، این یعنی روش‌های تشخیص قدیمی مثل «بررسی اینکه hash آپلود شده یا نه» در دستگاه‌های AP-DP بی‌فایده است. در عوض باید بررسی کنید که کاربر در گروه Autopilot Device Preparation Users هست یا نه، و policy assignment روی همان گروه قرار گرفته است. علاوه بر این، Microsoft از اوایل ۲۰۲۶ هشدار رسمی منتشر کرده که فلوی کلاسیک self-deploying و pre-provisioning به‌مرور deprecate خواهد شد، بنابراین در پروژه‌های جدید، AP-DP پیش‌فرض است.

چرا استقرار Autopilot من شکست می‌خورد؟

وقتی کاربر در میانه‌ی ESP پیام «Something went wrong» می‌بیند، در ۹ بار از ۱۰ بار یکی از این علل پشت پرده است: (۱) پروفایل Autopilot یا گروه assignment به دستگاه نرسیده، (۲) یک Win32 app یا اسکریپت PowerShell که در ESP به‌عنوان «required» علامت خورده، با کد غیرصفر خارج می‌شود، (۳) timeout پیش‌فرض ۶۰ دقیقه ESP در شبکه‌های کند یا با اپلیکیشن‌های بزرگ (مثل M365 Apps حدود ۳ گیگابایت) به اتمام می‌رسد، یا (۴) دستگاه نمی‌تواند به Entra ID join شود به دلیل DNS، پروکسی یا policy موجود در Intune که device platform restriction ایجاد کرده است.

قبل از هر کاری، اطلاعات زیر را در ذهن داشته باشید: ESP در دو فاز اجرا می‌شود، یعنی Device Preparation (پیش از login کاربر) و Account Setup (پس از login). اگر خطا قبل از صفحه‌ی ورود کاربر رخ دهد، مشکل از join یا پیکربندی دستگاه است؛ اگر بعد از ورود کاربر باشد، تقریباً همیشه به نصب Win32 app یا اسکریپت اختصاص داده‌شده مربوط است. این تمایز ساده در ۱۰ ثانیه‌ی اول، نوع کاوش بعدی شما را تعیین می‌کند.

یک مثال میدانی واقعی: تکنسینی گزارش می‌داد لپ‌تاپ‌های جدید Dell پس از ۶۰ دقیقه با کد 0x800705B4 fail می‌شوند. بررسی لاگ نشان داد که اسکریپت تنظیم باز کردن Group Policy Object برای BitLocker در حلقه‌ی reboot گیر کرده بود. این دقیقاً همان نوع مشکلی است که با خواندن چندخط لاگ مشخص می‌شود ولی بدون لاگ، می‌توانست ساعت‌ها وقت بگیرد. اگر می‌خواهید درک عمیق‌تری از تشخیص مشکلات Group Policy روی ویندوز ۱۱ پیدا کنید، راهنمای کامل ما در عیب‌یابی Group Policy در ویندوز ۱۱ مکمل عالی این مقاله است.

رایج‌ترین کدهای خطای ESP و معنی هر یک

صفحه‌ی Enrollment Status Page (ESP) خودش پنجره‌ای کوچک به سمت بسیار بزرگ‌تری از وضعیت دستگاه است. وقتی یک خطا نمایش داده می‌شود، روی صفحه می‌توان جزئیات (Details) را باز کرد و کد hex را دید. جدول زیر شایع‌ترین کدهایی که در سال ۲۰۲۶ از تیم‌های پشتیبانی Intune دیده‌ایم را خلاصه می‌کند:

کد خطا	معنی	اولین اقدام تشخیصی
0x800705B4	Timeout، یک فاز ESP بیش از مقدار تعیین‌شده طول کشید	بررسی Intune > Apps > Monitor و نگاه به status نصب apps در آن دستگاه
0x80180014	شکست Entra ID Join، معمولاً DNS، پروکسی یا restriction	بررسی dsregcmd /status و Conditional Access policy روی device platform
0x81036502	یک Win32 app اجباری با کد بازگشتی غیرصفر تمام شد	باز کردن IntuneManagementExtension.log در C:\ProgramData\Microsoft\IntuneManagementExtension\Logs
0x80070774	دستگاه نتوانست URL لازم Microsoft را resolve کند	تست Test-NetConnection enrollment.manage.microsoft.com -Port 443
0x80004005	خطای عمومی COM، معمولاً نشان‌دهنده اسکریپت ناقص یا policy متضاد	جمع‌آوری MdmDiagnosticsTool برای بررسی stack کامل
0x80070032	عملیات پشتیبانی‌نشده، اغلب نسخه ویندوز پایین‌تر از نیاز پروفایل	بررسی Build دستگاه؛ AP-DP حداقل Windows 11 23H2 می‌خواهد

نکته‌ی مهم: کد خطایی که ESP نشان می‌دهد همیشه دقیق نیست. در دو سناریوی واقعی که در سال ۲۰۲۵ مستند کردیم، کاربر 0x80004005 می‌دید ولی لاگ MDM به‌وضوح نشان می‌داد که علت اصلی timeout TPM attestation بوده. به همین خاطر همیشه پس از دیدن کد روی صفحه، لاگ‌ها را هم استخراج کنید. (به این موضوع در بخش جمع‌آوری لاگ‌ها برمی‌گردیم.)

Autopilot Device Preparation در برابر فلوی کلاسیک

تفاوت‌های عملیاتی این دو فلو از زاویه‌ی هلپ دسک خلاصه می‌شود به: hash، گروه‌بندی، و سرعت. در فلوی کلاسیک شما باید برای هر دستگاه hash 4K (یا OA3 از طریق OEM) را در Intune وارد می‌کردید، آن را به یک گروه Autopilot اضافه می‌کردید و پروفایل به همان گروه assign می‌شد. در AP-DP این کل زنجیره ساده شده: کاربر یک حساب در گروه Corporate Identities دارد، یک Device Preparation policy به همان گروه assign شده، و در لحظه‌ی ورود، Intune به‌صورت داینامیک دستگاه را وارد گروهی موقتی می‌کند که اپلیکیشن‌های ESP به آن assign هستند.

مزایا و معایب از نگاه هلپ دسک

مزیت اصلی AP-DP این است که شما دیگر درگیر «این لپ‌تاپ hash ندارد» نمی‌شوید — یکی از زمان‌برترین تیکت‌ها در سازمان‌های متوسط. اما اشکال آن این است که اگر دستگاه قبلاً Entra ID-joined شده باشد یا کاربر در گروه نباشد، خطای اولیه نه روی صفحه ESP بلکه به‌صورت یک «You can't sign in here» نمایش داده می‌شود که برای کاربر گیج‌کننده است. بنابراین در سناریوی AP-DP، اولین چیزی که باید بپرسید این نیست که «hash آپلود شده؟» بلکه این است که «کاربر در گروه AP-DP عضو است؟»

چگونه لاگ‌های Autopilot را جمع‌آوری کنیم؟

بدون لاگ، عیب‌یابی Autopilot حدس و گمان است. مایکروسافت ابزار رسمی MdmDiagnosticsTool را در همه‌ی نسخه‌های اخیر ویندوز ۱۱ تعبیه کرده است. روی صفحه‌ی ESP، با فشردن Shift + F10 یک Command Prompt محلی باز می‌شود. این نقطه‌ی شروع همه‌ی کاوش‌های میدانی است.

:: Open elevated Command Prompt from the OOBE error screen (Shift + F10)
:: Then collect a full diagnostic CAB with Autopilot, MDM, and TPM areas

mkdir C:\Temp
MdmDiagnosticsTool.exe -area Autopilot;DeviceProvisioning;TPM -cab C:\Temp\AutopilotLogs.cab

:: Or, if you only have PowerShell access, use the cmdlet form
Get-AutopilotDiagnostics -Online -CABFilePath C:\Temp\AutopilotLogs.cab

:: For Intune Management Extension specifically (Win32 app failures)
type C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log | more

فایل CAB حاصل شامل MDMDiagReport.xml، event logها، dsregcmd /status و لاگ‌های Intune Management Extension است. برای آنالیز سریع، اسکریپت متن‌باز و رایگان Get-AutopilotDiagnosticsCommunity.ps1 از Oliver Kieselbach (یکی از MVPهای Microsoft) خروجی CAB را در ترمینال به‌صورت رنگی و خوانا نمایش می‌دهد و دقیقاً مرحله‌ای را که شکست خورده هایلایت می‌کند.

یک اشتباه رایجی که خودم هم زمانی مرتکب می‌شدم: بسیاری از تکنسین‌ها قبل از reset دستگاه لاگ نمی‌گیرند، چون تصور می‌کنند با reset پیام خطا تکرار می‌شود. در ۳۰٪ موارد این درست نیست، مخصوصاً وقتی مشکل به وضعیت موقتی شبکه یا backend Microsoft Graph وابسته باشد. همیشه قبل از هر اقدام درمانی، CAB را بگیرید و در یک USB یا share شبکه ذخیره کنید.

کپی فایل CAB از دستگاه OOBE

روی صفحه‌ی OOBE نه drive map شده دارید و نه Explorer. ساده‌ترین راه‌ها: (الف) چسباندن یک USB FAT32 و کپی با copy C:\Temp\AutopilotLogs.cab E:\؛ (ب) باز کردن یک share موقتی به همان دستگاه از یک ماشین دیگر در شبکه؛ یا (ج) آپلود مستقیم با curl به یک endpoint داخلی شرکت اگر شبکه از داخل OOBE فعال است.

چگونه یک دستگاه Autopilot را reset کنیم؟

سه نوع reset برای Autopilot وجود دارد و انتخاب اشتباه می‌تواند ساعت‌ها وقت تلف کند. اول، Autopilot Reset از داخل Intune (Devices > پیدا کردن دستگاه > Autopilot Reset): این فقط برای دستگاه‌هایی کار می‌کند که حداقل یک بار با موفقیت enroll شده‌اند. دوم، Fresh Start که شبیه به ریست به تنظیمات کارخانه است ولی پروفایل ادامه می‌یابد. سوم و در عمل پرکاربردترین، OOBE Reset با فشردن CTRL+Win+R در صفحه‌ی ورود یا انتخاب «Reset this PC» از Recovery Environment.

برای دستگاهی که در ESP گیر کرده است، تکنیک امتحان‌شده این است: روی صفحه ESP لاگ بگیرید (Shift+F10، سپس MdmDiagnosticsTool)، سپس از همان CMD اجرا کنید: shutdown /r /t 0. اگر مجدداً به همان مرحله گیر کرد، از Recovery Environment وارد شوید و گزینه‌ی Reset this PC > Remove everything را با حالت Local reinstall اجرا کنید. این کار diagnostic data و رجیستری Autopilot را به وضعیت اولیه برمی‌گرداند.

مدیریت hash سخت‌افزار و سناریوی تعویض برد اصلی

در فلوی کلاسیک Autopilot، hash سخت‌افزار (که Microsoft به آن 4K hardware hash می‌گوید) ترکیبی از TPM ID، serial number، MAC آدرس‌ها و چند پارامتر سطح firmware است. وقتی بردهای اصلی تعویض می‌شود یا TPM clear می‌شود، این hash تغییر می‌کند و دستگاه به‌عنوان «ناشناخته» در نظر گرفته می‌شود. این یکی از زمان‌برترین تیکت‌های هلپ دسک برای ناوگان ۵۰۰+ دستگاهی است.

راه‌حل عملیاتی: قبل از تعمیر بدنه/مادربرد، با اجرای دستور Get-WindowsAutopilotInfo.ps1 -Online hash جاری را در Intune ثبت یا حذف کنید. پس از تعمیر، hash جدید را با همان اسکریپت آپلود کنید. اسکریپت رسمی از PowerShell Gallery (Get-WindowsAutopilotInfo) در دسترس است و توسط Michael Niehaus از تیم اصلی Autopilot مایکروسافت نگهداری می‌شود.

# Capture and upload the hardware hash directly to Intune
# Run from an elevated PowerShell on a freshly imaged or repaired machine

Install-Script -Name Get-WindowsAutopilotInfo -Force
Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned

# -Online uploads in one step; -GroupTag categorizes the device for dynamic groups
Get-WindowsAutopilotInfo.ps1 -Online -GroupTag "FieldEngineering-2026" -AssignedUser "[email protected]"

# To remove a stale device record after a motherboard swap
Connect-MgGraph -Scopes "DeviceManagementServiceConfig.ReadWrite.All"
$device = Get-MgDeviceManagementWindowsAutopilotDeviceIdentity -Filter "serialNumber eq 'ABC123XYZ'"
Remove-MgDeviceManagementWindowsAutopilotDeviceIdentity -WindowsAutopilotDeviceIdentityId $device.Id

برای محیط‌های در حال مهاجرت به Autopilot Device Preparation، این دردسر به‌کلی حذف می‌شود، اما تا زمانی که فلوی کلاسیک برای hybrid join استفاده می‌شود، این فرآیند بخش لاینفک کار هلپ دسک باقی می‌ماند. در راهنمای مفصل استقرار Windows LAPS، مدلی مشابه برای مدیریت رمز عبور admin محلی پس از تعمیر سخت‌افزار بررسی کرده‌ایم.

چک‌لیست پیشگیری برای استقرارهای آینده

راستش، بسیاری از تیکت‌های Autopilot قابل پیشگیری هستند اگر در زمان تنظیم پروفایل به چند نکته توجه شود. این چک‌لیست، که از تجربه‌ی مستندسازی بیش از ۲۰۰ استقرار در سال ۲۰۲۵ استخراج شده، می‌تواند نرخ شکست را تا ۷۰٪ کاهش دهد:

• Timeout ESP را روی ۱۲۰ دقیقه تنظیم کنید: مقدار پیش‌فرض ۶۰ دقیقه برای M365 Apps + Defender + هر دو سه Win32 app کافی نیست. ۱۲۰ دقیقه سقف امن است.
• Win32 appهای ESP-required را به حداقل برسانید: فقط اپلیکیشن‌های واقعاً ضروری برای روز اول (مثل antivirus سازمانی و VPN client) را در required بگذارید. بقیه را به فاز «Available» منتقل کنید.
• یک Conditional Access exclusion برای پروفایل اولیه: اگر CA policy دارید که MFA را برای همه‌ی sign-inها اجباری می‌کند، یک exclusion برای دستگاه‌های در حال Autopilot ایجاد کنید — تجربه‌ی کاربر را بسیار بهتر می‌کند.
• تست با یک VM در Hyper-V: قبل از gold image جدید، یک VM با Windows 11 23H2 یا بالاتر بسازید و فلوی Autopilot را روی آن اجرا کنید. این کار ۲۰ دقیقه می‌گیرد و یک هفته تیکت را حذف می‌کند.
• گزارش هفتگی Autopilot deployment report: در Intune > Reports > Windows Autopilot deployment، شما می‌توانید پر-تکرارترین خطاها را در یک نگاه ببینید. این گزارش هدف اول standup تیم هلپ دسک باشد.

برای تیم‌های هلپ دسک که در حال یکپارچه‌سازی Autopilot با مدیریت کلی مایکروسافت ۳۶۵ هستند، راهنمای کامل مدیریت Microsoft 365 مرجع تکمیلی مهمی است که بخش‌های Conditional Access و licensing را پوشش می‌دهد.

پرسش‌های متداول

چقدر طول می‌کشد تا Autopilot دستگاه را آماده کند؟

در یک شبکه‌ی شرکتی استاندارد با اینترنت ۱۰۰Mbps و مجموعه‌ی متعارفی از Win32 apps (M365 Apps، Defender، یک VPN client)، یک استقرار کامل بین ۴۵ تا ۹۰ دقیقه طول می‌کشد. اگر بیشتر از ۹۰ دقیقه شد، تقریباً به‌طور قطع timeout اپلیکیشن یا مشکل شبکه دارید.

آیا می‌توان Autopilot را بدون اتصال اینترنت اجرا کرد؟

خیر. Autopilot نیاز به دسترسی به ge.cloudpc.microsoft.com، login.microsoftonline.com و چندین endpoint دیگر دارد. تنها استثنا فلوی Pre-provisioning است که در آن دستگاه از پیش در یک مرکز فناوری اطلاعات آماده شده و سپس برای کاربر ارسال می‌شود.

چرا دستگاه پس از Autopilot Reset همان خطا را تکرار می‌کند؟

Autopilot Reset رکورد دستگاه را در Intune پاک نمی‌کند، فقط ویندوز را reset می‌کند. اگر مشکل از پروفایل assignment، policy متضاد، یا یک Win32 app معیوب باشد، با reset دوباره به همان حالت می‌رسید. در این موارد ابتدا پروفایل و apps را اصلاح کنید، سپس reset کنید.

چطور بفهمم پروفایل Autopilot به دستگاه assign شده است؟

در Intune به مسیر Devices > Windows > Windows enrollment > Devices بروید، روی serial number دستگاه کلیک کنید و در بخش Profile status ببینید که آیا «Assigned» نمایش داده می‌شود. اگر «Not assigned» باشد، یا دستگاه در گروه assignment نیست یا گروه داینامیک هنوز refresh نشده (تا ۶۰ دقیقه صبر کنید یا گروه را به‌صورت دستی refresh کنید).

آیا فلوی کلاسیک Autopilot در سال ۲۰۲۶ منسوخ می‌شود؟

مایکروسافت تاریخ deprecate رسمی برای فلوی کلاسیک تا اواخر ۲۰۲۶ اعلام نکرده، اما در پیام‌رسانی رسمی و کنفرانس Ignite 2025 به‌وضوح گفته که Autopilot Device Preparation فلوی پیش‌فرض است و سرمایه‌گذاری روی فلوی کلاسیک فقط در حد bug fix خواهد بود. در پروژه‌های جدید، AP-DP را پیش‌فرض قرار دهید.