Microsoft устранила сбой BitLocker в Windows Server 2025, из-за которого часть серверов после апрельского набора патчей 2026 года загружалась не в ОС, а в режим ввода ключа восстановления. Для корпоративной инфраструктуры это не мелкий косметический дефект: если машина внезапно просит recovery key после штатного обновления, у админа сразу два вопроса — как быстро вернуть сервис и сколько еще узлов поведут себя так же.
О проблеме, как пишет BleepingComputer, Microsoft официально сообщила вскоре после апрельского Patch Tuesday, а исправление выпустила только в июньских накопительных обновлениях. Для Windows Server 2025 это пакет KB5094125, для Windows 11 23H2 — KB5093998. Речь идет не о массовом падении всех систем подряд, а о довольно узком сочетании настроек BitLocker, TPM и Secure Boot. Но как раз такие «узкие сочетания» обычно и живут годами в больших корпоративных контурах, где политики однажды включили и больше не трогали.
Механика сбоя выглядит неприятно знакомо для любого, кто администрировал BitLocker в доменной среде. На затронутых устройствах был включен BitLocker на системном диске, настроена групповая политика Configure TPM platform validation profile for native UEFI firmware configurations, а в профиль проверки входил PCR7. При этом в msinfo32.exe состояние Secure Boot State PCR7 Binding отображалось как Not Possible. Дополнительно в базе подписей Secure Boot уже присутствовал сертификат Windows UEFI CA 2023, то есть устройство было готово перейти на Windows Boot Manager, подписанный в 2023 году, но фактически еще работало не на нем. После установки обновления и первой перезагрузки эта комбинация и приводила к тому, что сервер вместо привычного старта просил ключ BitLocker.
Хорошая новость в том, что сценарий был разовым: Microsoft изначально уточняла, что ввод ключа требовался только при первом рестарте после установки проблемного обновления, а последующие загрузки шли нормально, если администратор не менял политику. Плохая — для продакшн-среды даже один внеплановый экран BitLocker recovery может стоить вполне реального ночного созвона, эскалации и ручного поиска ключей в AD, Entra ID или внутреннем сейфе секретов. Особенно если сервер не в тестовом стенде, а в филиале, у подрядчика или на удаленной площадке без человека с консольным доступом.
В июньском исправлении Microsoft пошла не самым изящным, зато практичным путем: система просто не будет устанавливать Windows Boot Manager с подписью 2023 года на устройствах с несовместимой конфигурацией групповой политики. То есть компания не «лечит» плохую политику автоматически, а ставит ограничитель, чтобы обновление загрузочных файлов не провоцировало сбой BitLocker. Если устройство уже подпадало под проблему, администратор увидит в системном журнале событие с Event ID 1032 во время установки обновлений. Для ИТ-команд это важная деталь: можно не гадать, почему машина внезапно попросила recovery key, а хотя бы иметь точку для поиска и ретроспективной проверки затронутых узлов.
Тем, кто по каким-то причинам еще не может раскатить июньские cumulative updates, Microsoft предлагает временные меры. Первый вариант — убрать проблемную групповую политику до установки KB5082063 и более поздних обновлений и убедиться, что привязки BitLocker используют профиль PCR7 корректно. Второй — применить Known Issue Rollback, чтобы заблокировать автоматическое переключение на новый Boot Manager, которое и запускает цепочку с BitLocker recovery. Само по себе наличие KIR уже давно стало для Windows-администрирования отдельным жанром: патч вышел, побочный эффект нашелся, откатили не весь пакет, а конкретное проблемное изменение. Рабочая схема, но вряд ли это тот DevOps-романтизм, который кто-то заказывал.
Контекст у истории тоже показательный. Это не первый случай, когда обновления Microsoft сталкиваются с чувствительной связкой BitLocker, TPM и загрузочной цепочки. В августе 2024 года компания уже исправляла известную проблему, из-за которой июльские security updates вызывали запросы ключа BitLocker на всех поддерживаемых версиях Windows. Позже, в мае 2025 года, Microsoft выпускала внеплановые обновления для Windows 10 из-за похожего поведения после майских патчей безопасности. Иными словами, дело не в одном неудачном релизе под Windows Server 2025, а в устойчиво сложной зоне, где пересекаются криптография диска, Secure Boot, прошивка, TPM-измерения и обновление загрузчика. Любая ошибка здесь быстро превращает «просто патчинг» в квест с экраном восстановления.
Для русскоязычных инфраструктурных команд вывод вполне прикладной. Во-первых, политики BitLocker, особенно старые и унаследованные, стоит проверять не только на предмет соответствия базовым требованиям безопасности, но и на совместимость с текущей логикой Secure Boot и PCR7. Во-вторых, сам факт, что проблема затронула в первую очередь корпоративные конфигурации, а не домашние ПК, еще раз показывает разрыв между тем, как Windows ведет себя в лабораторной чистоте, и тем, как она живет в реальном enterprise. В-третьих, patch management для серверов уже давно нельзя сводить к формуле «накатили cumulative update и пошли дальше». Если в контуре используется BitLocker, TPM validation и UEFI Secure Boot, проверка загрузочной цепочки должна входить в стандартный сценарий тестирования обновлений, а ключи восстановления — не лежать в том месте, куда никто не может быстро дотянуться ночью.
История со сбоем BitLocker в Windows Server 2025 вряд ли станет последней в этом классе инцидентов. Чем плотнее Microsoft обновляет доверенную загрузку, сертификаты Secure Boot и поведение Boot Manager, тем дороже становится любая нестыковка между «рекомендуемой» конфигурацией и тем, что годами живет в корпоративной политике. Для администраторов здесь урок простой: самые неприятные инциденты рождаются не из экзотических zero-day, а из скучных старых настроек, которые внезапно встречаются с новым патчем.