Windows Server 2022 RC: Secured-Core ломает старые RAID-драйверы - что чинить до GA

Microsoft выкатила Windows Server 2022 RC - Build 20348.169, статус Release Candidate. Это уже не превью с предупреждением «не ставьте в прод»: функционал зафиксирован, до GA остаётся цикл стабилизации. Мы ждали этого момента, чтобы прогнать RC на реальном стенде - не в виртуалке, а на физическом железе. Итог оказался интереснее, чем ожидали.

Что изменилось от Preview до RC

В январе мы смотрели на Preview - там Secured-Core работал, но с оговорками: HVCI включался, зелёные галочки в Device Security светились, но несколько функций вели себя нестабильно. RC здесь заметно плотнее. Secured-Core теперь не просто активируется - он применяет политики жёстче.

Конкретно: HVCI (Hypervisor-Protected Code Integrity) в RC по умолчанию требует, чтобы все драйверы режима ядра были подписаны через Microsoft Hardware Dev Center с WHQL-сертификацией, и блокирует загрузку firmware-обновлений без верифицированной подписи. В Preview часть этих проверок была помягче или вообще не включалась без явной настройки. В RC - включена из коробки на совместимом железе.

TLS 1.3 в RC ведёт себя ровно так, как описывали: включён по умолчанию, TLS 1.0/1.1 отключены. Здесь сюрпризов не было - всё то, что мы видели в Preview, осталось без изменений. Schannel правильно согласовывает TLS 1.3 с современными клиентами, падений не было.

Где Secured-Core сломал стенд

Вот где стало интересно. У нас в стенде несколько конфигураций - разное железо разных поколений, потому что нам нужно понимать, что произойдёт на реальных клиентских серверах, а не только на свежекупленных.

На одном из серверов стоит RAID-контроллер поколения, которому около пяти лет. Производитель его не забросил - драйверы под Windows Server 2019 есть и работают. Но firmware подписан по старой схеме, которая не проходит проверку HVCI в RC.

Симптом - система при включённом Secured-Core просто не загружает драйвер контроллера. RAID-массив система видит, но управление им через штатную утилиту производителя перестаёт работать. Если говорить точнее: сам массив доступен через inbox-драйвер Windows, данные читаются, но vendor management utility (тот агент, который следит за состоянием дисков, SMART и отказами) грузится с ошибкой.

Второй случай похожий, но с другим контроллером - там драйвер вообще не загружается в режиме ядра, и массив пропадает целиком. Это уже другой разговор.

Что конкретно надо обновить до GA

Прошлись по ситуации системно. Проблема в двух слоях:

• Firmware контроллера. Если производитель выпустил обновление firmware с правильной подписью - обновлять обязательно и делать это до перехода на 2022. Firmware обновляется из среды текущей ОС, апгрейднуть firmware после того как HVCI заблокировал загрузку firmware-инструмента - задача нетривиальная.

• Драйвер в режиме ядра. Должен иметь WHQL-подпись, полученную через современный процесс подписи Microsoft. Драйверы, подписанные через старый cross-certificate процесс до 2015 года, в HVCI-режиме могут не загружаться. Производитель должен перевыпустить драйвер через Hardware Dev Center.

• Vendor management utility. Часто это отдельный агент, который ставится в систему и тоже грузит что-то в ядро. Его тоже нужно проверить на совместимость - иногда проблема именно здесь, а не в основном драйвере RAID.

Производители первого уровня (HPE, Dell, Lenovo) в большинстве случаев уже выпустили или выпускают обновления с прицелом на 2022. У HPE есть SPP (Service Pack for ProLiant) с обновлёнными firmware-пакетами. У Dell - DUP-пакеты для серверов PowerEdge. Проблема обычно возникает с контроллерами от менее крупных производителей или с OEM-железом, где цепочка поддержки мутнее.

Как проверить заранее

Microsoft в RC добавила возможность запустить совместимость с Secured-Core без его включения - через режим аудита в Device Security. Это полезно: можно посмотреть, что именно будет заблокировано, до того как заблокируется.

Практически - мы проверяем через список в Device Manager: если рядом с устройством видим предупреждение о проблеме с подписью при включённом режиме проверки целостности кода, это кандидат на обновление перед GA. Инструмент sigcheck из Sysinternals тоже помогает проверить подпись конкретного sys-файла драйвера.

Ещё один момент: некоторые старые драйверы загружаются нормально, пока не начинается firmware update через vendor tool. То есть на стенде с базовой конфигурацией всё выглядит хорошо, а в реальной эксплуатации, когда приходит плановое обновление firmware, вылезает проблема. Это делает тестирование на стенде неполным, если не прогнать полный цикл обслуживания.

TLS 1.3: без сюрпризов, но проверить список агентов стоит

По TLS ситуация спокойнее. Единственное, что мы поймали - один из мониторинговых агентов (не будем называть вендора) при соединении с management server использует собственную TLS-реализацию, и она с TLS 1.3 договаривалась нестабильно. Не падала совсем, но иногда давала таймауты. Решилось обновлением агента до последней версии.

В общем: агенты мониторинга, резервного копирования и другие сторонние службы, которые делают TLS-соединения, стоит проверить на совместимость до GA. Это быстрее, чем разбираться с причиной пропавших метрик после апгрейда.

Что дальше

До GA работы хватает. На стенде нам осталось прогнать несколько конфигураций с разными RAID-контроллерами и уточнить список «требует firmware-обновления». По клиентам на managed-сопровождении уже начинаем инвентаризацию железа - смотрим, какие серверы планируются к переводу на 2022, и есть ли там контроллеры из групп риска. Лучше выяснить сейчас, пока GA не вышел, чем торопиться потом.