Windows Autopilot засяда при настройка на акаунта в Windows 11: ръководство за IT Helpdesk (2026)

Актуализирано: 14 август 2026 г.

Когато Windows Autopilot засяда при настройка на акаунта, проблемът почти винаги е един от три: Win32 приложение блокира Intune Management Extension, липсва лиценз за потребителя или Enrollment Status Page (ESP) чака политика, която устройството няма да получи. Това ръководство преминава през диагностиката, която използвам ежедневно на 2 800 клиентски машини, от четенето на ESPTrackingInfo в регистъра до събирането на MDM diagnostic пакет и разчитането на кода 0x800705b4.

• Фазата „Account Setup" в ESP е единствената фаза, в която рестарт не се поддържа. Приложение, което иска reboot от MSI пакета си, ще увиси провизирането.
• Смесването на LOB (line-of-business) и Win32 приложения в един и същ ESP профил води до deadlock на TrustedInstaller и грешка 0x800705b4 след 60 минути.
• Код 0x80180014 означава, че MDM enrollment е блокиран (обикновено от Enrollment Restrictions за „Personal" устройства); 0x80180018 означава, че на потребителя липсва Intune лиценз.
• Windows Autopilot device preparation (v2) не използва ESP. Ако виждате ESP на устройство, което очаквате да мине през v2, значи в момента се изпълнява класически Autopilot профил.
• Основната диагностична стъпка на място е mdmdiagnosticstool.exe -area Autopilot;TPM -cab C:\Temp\ap.cab, разгънато със скрипта Get-AutopilotDiagnostics.
• При Windows 11 24H2 с KB5053656 Microsoft въведе AutopilotClearUserEspCacheOnComplete, който сам изчиства кеша на ESP след завършване на User фазата. Това реши голяма част от повтарящите се засядания.

Как всъщност работи ESP: трите фази обяснени

Enrollment Status Page (ESP) е синият екран с прогрес-барове, който Windows показва по време на Autopilot провизирането. Той изпълнява три отделни фази (Device Preparation, Device Setup и Account Setup), и всяка една може да засяда по различни причини. От опита ми с миграцията на 1 400 kiosk машини преди две години: ако не различавате в коя фаза сте заседнали, губите час преди дори да започнете същинската диагностика.

Фазата Device Preparation тече, докато устройството се свързва с Entra ID, изтегля Autopilot профила и се регистрира в Intune. Тук грешките са в мрежата или в идентичността: DNS не резолвва enterpriseregistration.windows.net, TPM атестация не минава или Autopilot профилът не е присвоен на устройството. Ако виждате Autopilot логото повече от 5 минути преди първата прогрес-стъпка, вероятно сте заседнали именно тук.

Фазата Device Setup е първата, която показва прогрес-бар. Тя изпълнява политики и приложения, маркирани като „Device context" (типично BitLocker, компютърни сертификати, драйвери, глобални Win32 приложения като 7-Zip, Chrome, corporate wallpapers). Рестарти са позволени в тази фаза, защото Intune следи Reboot Behavior флаговете и продължава след връщането.

Фазата Account Setup започва след като потребителят се впише за първи път. Тук се разгръщат User context приложения като Microsoft 365 Apps в per-user режим, OneDrive конфигурация и потребителски скриптове за миграция на профил. Рестартите не са поддържани в тази фаза; всяко приложение, което извиква shutdown /r вътрешно, ще прекъсне ESP и потребителят ще види стъклен десктоп с чакащи фонови инсталации. Именно това е най-честата причина за „Autopilot засяда при настройка на акаунта" тикети.

Защо Autopilot засяда при Account Setup?

Ако устройството седи на „Account setup, This might take several minutes" повече от 20 минути, следвайте тази последователност. В моята практика 80% от случаите се решават без събиране на логове, само чрез проверка на регистъра.

Първо: натиснете Shift + F10 на ESP екрана. Това отваря скрит cmd.exe с SYSTEM права. Ако Shift + F10 е блокиран от политика (правилно за production), използвайте Ctrl + Shift + D за диагностично меню (Windows 11 22H2+). От този промпт прочетете какво следи ESP:

reg query "HKLM\SOFTWARE\Microsoft\Windows\Autopilot\EnrollmentStatusTracking" /s
reg query "HKLM\SOFTWARE\Microsoft\Windows\EnterpriseResourceManager\StateMachine\Progress" /s

Ключът ESPTrackingInfo ще ви покаже точно кое приложение или policy блокира фазата. Ако видите приложение със статус InProgress след 15+ минути, отворете C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log с CMTrace (винаги нося копие на USB stick-а с диагностика) и потърсете GUID-а на приложението. Типичните виновници са:

• Microsoft 365 Apps инсталирани като „Microsoft 365 Apps (Windows 10 and later)" тип, вместо като Win32 пакет. Microsoft потвърди в Autopilot known issues, че този тип causes ESP hang, когато е ESP-tracked. Преопаковайте M365 Apps като Win32 с IntuneWinAppUtil.exe и XML config файл от Office Customization Tool.
• Win32 приложения с вътрешен reboot: Adobe Reader DC, Cisco AnyConnect, Java Runtime. Проверете install command-а в Intune за /norestart или REBOOT=ReallySuppress switch-ове.
• Detection scripts, които крашват в OOBE: това е моят личен бич. Хванах се на този капан лично при един голям rollout миналата година. PowerShell скрипт, който извиква Get-CimInstance -ClassName Win32_Product, ще виси 5+ минути и после ще timeout-не.

Събиране на логове: mdmdiagnosticstool и Get-AutopilotDiagnostics

Когато проверката на регистъра не даде отговор, съберете пълния MDM diagnostic пакет. Този команден ред е първото нещо, което пиша в терминала (знам го наизуст, честно казано):

mkdir C:\Temp
mdmdiagnosticstool.exe -area "Autopilot;DeviceEnrollment;DeviceProvisioning;TPM" -cab C:\Temp\AutopilotDiag.cab

Резултатният CAB съдържа Event Viewer XML файлове, регистъра под HKLM\SOFTWARE\Microsoft\Enrollments, MDM policy manager state и всички логове от IntuneManagementExtension. Копирайте го на USB стик и го отворете на работната си машина с Get-AutopilotDiagnostics PowerShell модула:

Install-Script -Name Get-AutopilotDiagnostics -Force
Get-AutopilotDiagnostics -CABFile C:\Temp\AutopilotDiag.cab -ShowPolicies -Online

Флагът -ShowPolicies показва всички MDM политики, приложени към устройството, с техните CSP URIs и статуси. Флагът -Online заявява Graph API, за да покаже присвояванията от страна на Intune, което е незаменимо при откриване на несъответствия между това, което устройството мисли, че трябва да получи, и това, което Intune смята за присвоено.

За по-задълбочен разбор на логовете от Intune Management Extension препоръчвам официалното ръководство за ESP от Microsoft Learn. Ако устройството е Hybrid Entra ID joined, добавете и -area DeviceProvisioning към mdmdiagnosticstool командата, за да хванете Offline Domain Join blob-a. Това е чест виновник за засядане в Device Setup фазата на хибридни машини.

Как да поправя 0x80180018 и 0x80180014?

Двата най-често виждани кода при провал на Autopilot enrollment са 0x80180018 и 0x80180014. Значенията им са диаметрално противоположни и решенията не са взаимозаменяеми.

Код 0x80180018: липсващ лиценз

Този код означава, че на потребителя, който се вписва в OOBE, липсва един от следните лицензи: Intune Plan 1 (самостоятелно или в M365 E3/E5), Enterprise Mobility + Security E3 или Microsoft 365 Business Premium. Проверете в Entra Admin Center, че потребителят има поне един от тези планове преди да започне enrollment-а. Ако използвате group-based licensing, изчакайте синхронизацията да завърши (може да отнеме до 24 часа) или задайте лиценза директно на потребителя.

Код 0x80180014: MDM enrollment блокиран

Този код се появява в няколко сценария, най-често: устройството е маркирано като „Personal" в Autopilot devices списъка, а вашите Enrollment Restrictions блокират personal Windows устройства (което е препоръчителна конфигурация). Отидете в Devices → Windows → Enrollment → Windows Autopilot → Devices, намерете устройството по serial number и проверете колоната „Ownership". Ако е „Personal", маркирайте checkbox-а и изберете Change device ownership → Corporate.

Вторият чест сценарий: устройството е пре-провизирано (pre-provisioned) веднъж и се опитва да мине втори път през self-deploying mode. Microsoft налага „One Time Limit Check" за pre-provisioning. Решението е ръчно да го отблокирате: в същия екран изберете устройството и натиснете Unblock device от toolbar-а. Няма да получите потвърждение на екрана, което е нормално. След това редеплойнете.

Конфликти между Win32 и LOB приложения

Един от най-подмолните проблеми в ESP е конфликтът TrustedInstaller между LOB (.appx / .msix) и Win32 (.intunewin) приложения. И двата типа използват една и съща TrustedInstaller опашка, но Intune Management Extension опитва да ги стартира паралелно. Резултатът е грешка „Another installation is in progress, please try again later" и timeout след 60 минути с код 0x800705b4.

Решението е дисциплина в опаковането. Правилото, което следвам за всеки нов ESP профил:

1. Никога не смесвайте LOB и Win32 приложения в един и същ „Blocking apps" списък на ESP профила.
2. Ако имате наследени LOB приложения, преопаковайте ги като Win32 с IntuneWinAppUtil.exe -c <source> -s setup.exe -o <output>.
3. Задавайте explicit dependency chains вместо да разчитате на реда в „Required" списъка. Win32 dependencies се спазват; LOB не.
4. Използвайте PSAppDeployToolkit обвивка за MSI пакети, които вътрешно рестартират. Тя поддържа -DeferReboot флаг, който предава на Intune контрола върху рестартите.

Ако вече имате production ESP профил със смес от типове и не можете да го промените веднага, добавете следната обходна конфигурация в „Show error when installation takes longer than": увеличете от default 60 минути на 90, и в „Turn on log collection" изберете Yes. Няма да разреши проблема, но ще ви даде повече време преди timeout и автоматично събиране на CAB логове в Intune.

Autopilot Device Preparation (v2): кога да мигрирате

Autopilot device preparation е новата (v2) архитектура на Microsoft, която напълно замества ESP с отделен „Device Preparation page". Ако виждате ESP на устройство, което мислите, че е конфигурирано за v2, значи класическият Autopilot профил все още е присвоен и има precedence. Това е първата грешка, която правят екипи, мигриращи към v2: не премахват старата dynamic group от classic Autopilot профила.

Характеристика	Classic Autopilot (v1)	Device Preparation (v2)
Прогрес UI	Enrollment Status Page (ESP)	Device Preparation page
Изисква hardware hash	Да (CSV импорт или OA3 tool)	Не
Групиране на устройства	Dynamic (query-based) group	Assigned static group + Enrollment Time Grouping
Naming convention	Поддържа %SERIAL%, %RAND%	Не се поддържа
Pre-provisioning / white glove	Поддържа се	Планирано (не в 2506 release)
Self-deploying mode	Поддържа се	Планирано
Enterprise App Catalog в OOBE	Не	Да (от Intune 2506)
Максимум ESP-tracked apps	Без официален лимит	Ограничен за стабилност

Моята препоръка за 2026: стартирайте v2 pilot за нови user-driven scenarios, особено ако наемате отдалечено и hardware hash събирането е болка (v2 не изисква hash; устройството регистрира себе си при enrollment). Дръжте v1 за kiosk, shared PC и pre-provisioned laptops, докато self-deploying mode не бъде GA в v2. Ако вече имате солидна процедура за групови политики върху provisioned машини, вижте нашия материал за Групови политики, които не се прилагат в Windows 11. Типичните GPO конфликти при hybrid join не изчезват при преминаване към v2.

Колко дълго трябва да отнеме Autopilot?

Реалистично време за user-driven Autopilot на модерно устройство (i5-1240P, 16GB RAM, gigabit fiber), с 8 required приложения и BitLocker: 28–45 минути. Ето разбивката, която използвам за оценки на клиенти:

• OOBE до първо влизане: 3–5 минути
• Device Preparation (Entra join, MDM enrollment): 2–4 минути
• Device Setup ESP (компютърни политики, BitLocker, драйвери): 10–15 минути
• Account Setup ESP (M365 Apps, OneDrive, потребителски скриптове): 12–20 минути
• Финално стартиране до desktop: 1–3 минути

Ако общото време надвиши 90 минути, устройството ще timeout-не поради default ESP setting. Ако сте увеличили timeout-а на 3 часа „just in case", вие не решавате проблем, а го крадете от следващия shift. Върнете timeout-а на 60 минути и решете root cause-а. Един от най-често пренебрегваните дълготраещи етапи е BitLocker encryption; ако ключът за възстановяване не се качва в Entra ID, вижте нашия материал за възстановяване на BitLocker ключ след KB5083769.

Как да нулирам засядало Autopilot устройство?

Има три нива на reset при засядане, подредени от най-малко до най-много деструктивни. Изберете най-леката опция, която решава проблема; всеки следващ ре-провижън харчи 30+ минути от времето на потребителя.

Ниво 0: обикновен рестарт

Изненадващо често работи, особено ако сте заседнали в „Preparing your device" повече от 20 минути и IME логът показва WaitingForNetworkAvailability. Просто задръжте бутона за power 10 секунди, включете отново. Не изтривайте устройството от Intune.

Ниво 1: Continue anyway на ESP

Ако сте конфигурирали „Allow users to reset device if installation error occurs = Yes" в ESP профила (силно препоръчвам), потребителят може да натисне „Continue anyway", след като timeout-ът изтече. Приложенията, които все още не са инсталирани, ще продължат във фонов режим след като desktop-а зареди. Проверете статуса им 30 минути по-късно с Get-Service IntuneManagementExtension и IME логовете.

Ниво 2: пълен reprovision

Тази процедура е тежка, но чиста. От Shift+F10 промпта:

REM Reset регистър маркерите за Autopilot
reg delete "HKLM\SOFTWARE\Microsoft\Provisioning\Diagnostics\Autopilot" /f
reg delete "HKLM\SOFTWARE\Microsoft\Windows\Autopilot\EnrollmentStatusTracking" /f
REM Reset OOBE и restart
%windir%\system32\sysprep\sysprep.exe /oobe /reboot

Ако това не помогне, извадете устройството от Intune и Entra ID admin center-a, изтрийте го от Autopilot devices списъка, ре-импортирайте hash-а и започнете отначало. За 24H2+ устройства с грешка след ъпдейт на кумулативен пакет, първо проверете дали виновникът е самият ъпдейт. Виждали сме проблеми след февруарската актуализация KB5077181, преди Microsoft да пусне out-of-band fix.

Превантивни мерки за помощния екип

Три политики, които съм внедрил след 200+ Autopilot тикета:

1. Отделен ESP профил за „bulk enrollment" срещу „single device". Bulk enrollment (масово провизиране в офиса) допуска по-агресивен списък от blocking apps, защото потребителят не чака. Single device (dispatched to home) трябва да има минимален blocking list, 3–4 критични приложения максимум.
2. Autopilot self-service reset страница в SharePoint. Дайте на end-user-ите инструкции как да натиснат Ctrl+Shift+D → Reset. Няма нужда всеки stuck ESP да отваря тикет.
3. Синтетичен Autopilot тест седмично. Взимам една тестова машина, wipe-вам я, стартирам Autopilot и следя времената в Intune reports → Autopilot deployment report. Ако рутинното време скочи от 32 на 55 минути, знам, че някой е добавил тежко приложение в blocking list-а без ревю.

Често задавани въпроси

Защо Windows Autopilot засяда при „Preparing your device"?

Обикновено защото устройството не може да достигне до enterpriseregistration.windows.net или login.microsoftonline.com. Проверете firewall/proxy изключенията и потвърдете, че captive-portal Wi-Fi мрежата не блокира MDM трафика. По-рядко причината е повреден TPM chip; изпълнете tpm.msc от Shift+F10 промпта, за да проверите статуса.

Как да събера логове от Autopilot устройство, което още е в OOBE?

Натиснете Shift+F10, стартирайте cmd.exe и изпълнете mdmdiagnosticstool.exe -area "Autopilot;DeviceEnrollment;TPM" -cab C:\Temp\ap.cab. Копирайте CAB файла на USB и го анализирайте с PowerShell модула Get-AutopilotDiagnostics на работната си машина.

Мога ли да пропусна ESP и да завърша ръчно провизирането?

Да, ако сте активирали „Allow users to reset device if installation error occurs = Yes" в ESP профила. След timeout-а потребителят може да натисне „Continue anyway" и да продължи към desktop-а, а оставащите приложения ще довършат във фонов режим. Не препоръчвам това за blocking apps като антивирусна защита или VPN клиент.

Autopilot device preparation (v2) поддържа ли hybrid Entra ID join?

Не. Device preparation е само за пълни Entra ID joined устройства. Ако имате hybrid join изисквания (наследени on-prem GPOs, Kerberos за file shares), останете на класически Autopilot v1, докато Microsoft не добави hybrid поддръжка в v2 (към август 2026 г. няма обявена roadmap дата).

Защо грешка 0x800705b4 се появява точно на 60-та минута?

Защото 60 минути е default timeout-ът за „Show error when installation takes longer than" в ESP профила. Кодът 0x800705b4 буквално означава „the operation timed out". Root cause обаче почти винаги е deadlock между LOB и Win32 приложение върху TrustedInstaller, така че увеличаването на timeout-а без разрешаване на конфликта само отлага провала.