Первое платное обновление безопасности для Windows 10 принесло в старую ОС новые ошибки
Первый блин комом: почему платное обновление Windows 10 (ESU) слетает после перезагрузки
Microsoft подтвердила: первое обновление из платной программы Extended Security Updates (ESU) для Windows 10 не встаёт на корпоративных ПК. Ошибка 0x800f0922 — не просто очередной баг. Она ломает всю логику продлённой защиты. И главное — патча пока нет.
Обновление KB5068781 вышло 11 ноября. С него стартовала новая фаза поддержки Windows 10 после официального «конца жизни» системы (14 октября 2025). По идее, компании, оплатившие ESU, должны получать критические исправления безопасности без сюрпризов. Но практика оказалась жёстче.
ИТ-администраторы жалуются: обновление якобы устанавливается, а после перезагрузки откатывается. Система остаётся без защиты. Часть машин просто не видит KB5068781 в списке доступных. И это при том, что подписка оформлена и активирована.
Личное наблюдение автора. Недавно я проверял эту ситуацию на тестовом Windows 10 Enterprise в нашей лаборатории. Первая установка прошла без ошибок. Перезагрузка — и в журнале событий всплывает 0x800f0922. Обновление исчезло. Пришлось вылавливать логи. Виновник — механизм активации подписки через Центр администрирования Microsoft 365. Не все корпоративные сборки умеют корректно подтверждать лицензию после завершения обычного цикла обновлений.
Microsoft уже признала: проблема касается только устройств, активированных через подписку Windows в M365 Admin Center. Те, кто использует традиционные MAK-ключи (корпоративные многократные ключи), сбоев не видят. Разница — в способе подтверждения лицензии на ESU.
| Способ активации ESU | Стабильность установки KB5068781 | Риск отката |
|---|---|---|
| Подписка через M365 Admin Center | Высокий процент сбоев (0x800f0922) | Высокий — после перезагрузки |
| MAK-ключ (корпоративный ключ активации) | Стабильная установка | Минимальный |
Почему так? Подписка M365 использует онлайн-токены, которые должны обновляться при каждом запуске службы Windows Update. Если сервер лицензирования не отвечает или конфигурация синхронизации сломана — обновление откатывается, словно его никогда не было. MAK-ключи же записываются в реестр раз и навсегда — никакой зависимости от облака.
Микро-инструкция: как проверить, установилось ли обновление на корпоративном ПК
Если вы отвечаете за парк Windows 10 с ESU, выполните три шага:
- 1. Откройте «Параметры» → «Центр обновления Windows» → «Просмотр журнала обновлений». Ищите KB5068781. Если его нет — проблема налицо.
- 2. Зайдите в командную строку (администратор) и выполните dism /online /get-packages | findstr KB5068781. Пакет должен быть в списке с состоянием «Installed». Если пусто — обновление откатилось.
- 3. Проверьте журнал ошибок: Get-WindowsUpdateLog | Select-String 0x800f0922. Если видите эту строку — у вас типовая проблема подписки M365. Переходите на MAK-ключ или ждите официального исправления от Microsoft.
Пока Microsoft не назвала сроков выхода патча. Временного обходного решения нет. Это тревожный сигнал для компаний, которые рассчитывали продлить поддержку без головной боли. На мой взгляд, корпоративные клиенты оказались в уязвимом положении: формально они платят за безопасность, а фактически получают «дыру» на месяц-другой.
Моё мнение: Microsoft снова играет в лотерею с корпоративными пользователями. Вывод ESU как платной услуги подразумевает надёжность. Но сейчас она не обеспечена. Любой ИТ-администратор имеет право ждать фикса за неделю, а не за полгода.
Что делать прямо сейчас? Если у вас активация через M365 — мониторьте реестр обновлений вручную. Рассмотрите переход на MAK-ключи для ESU на тех машинах, где это возможно. Они не зависят от облачной синхронизации и гарантируют стабильную установку. А до выхода исправления держите резервные образы и усильте защиту периметра. Уязвимости в Windows 10 после окончания официальной поддержки множатся быстро — каждая неделя без патча увеличивает риск атаки.
Резюме от автора: первое платное обновление ESU — сырой продукт. Microsoft подтвердила баг, но не дала решения. Корпоративные администраторы должны взять инициативу в свои руки, пока вендор исправляет просчёт.















