Windows Server 2022 GA: первый production deployment guide - Secured-Core, SMB compression и когда мигрировать

Microsoft выпустила Windows Server 2022 General Availability. Не RC, не Preview - финальный релиз, можно ставить в production. Мы весь июль тестировали RC на стенде, ловили проблемы с [Secured-Core](/blog/terms/secured-core-server/) и старыми [RAID-контроллерами](/blog/terms/raid/) - теперь можно говорить о развёртывании на реальных клиентских серверах.

Ниже - что реально изменилось от RC до GA, что нужно проверить до апгрейда и когда этот апгрейд вообще имеет смысл.

Что добавилось от RC до GA

Функциональных сюрпризов нет - Microsoft держала слово: функционал был зафиксирован в RC, GA это стабилизированная версия того же кода. Из замеченного: несколько мест в Device Security UI стали чище, документация по Secured-Core появилась в финальном виде на docs.microsoft.com, и выкатились обновлённые драйверы от HP и Dell с явным указанием поддержки WS2022. Это хорошо - значит проблемы с firmware, которые мы ловили в RC на старых RAID-контроллерах, у части железа уже решены производителями.

Ключевые три темы GA: Secured-Core Server, SMB over QUIC и SMB compression. TLS 1.3 по умолчанию - это тоже важно, но с ним мы разобрались ещё в RC, там ничего нового.

Secured-Core: что конкретно требует железо

Secured-Core - это не просто набор настроек, это режим, который требует поддержки со стороны hardware. Без совместимого железа большая часть функций просто не включается, и Windows молча работает в обычном режиме. Что нужно:

• UEFI Secure Boot - давно не редкость, но должен быть включён. Серверы с legacy BIOS не подойдут.
• TPM 2.0 - обязателен. Не TPM 1.2, именно 2.0. На серверах, купленных в последние несколько лет, он есть почти всегда, но бывает выключен в BIOS по умолчанию.
• HVCI (Hypervisor-Protected Code Integrity) - требует поддержки виртуализации в процессоре (Intel VT-x / AMD-V с SLAT). На серверном железе это норма, но на некоторых виртуальных машинах вложенная виртуализация нужна явно.
• Kernel DMA Protection - защита от атак через DMA-устройства. Требует поддержки IOMMU (Intel VT-d / AMD-Vi) в чипсете и правильных настроек в UEFI.
• DRTM (Dynamic Root of Trust for Measurement) - Intel TXT или AMD SKINIT. Это уже серьёзное требование: не любой серверный процессор поддерживает, и не любая материнская плата, даже с нужным CPU, активирует эту функцию.

Практический вывод из нашего тестирования: на серверах HPE Gen10 Plus и Dell PowerEdge 15th Generation все пять пунктов закрываются. На поколениях постарше - уже нужно смотреть конкретно. Kernel DMA Protection и DRTM чаще всего оказываются узким местом на железе 2016-2018 годов.

Проверить совместимость можно через Get-ComputerInfo в PowerShell - интересуют поля DeviceGuardSecurityServicesConfigured и DeviceGuardSecurityServicesRunning. Разница между «Configured» и «Running» говорит сама за себя: что-то включено в настройках, но не запустилось - значит hardware не поддерживает.

SMB compression: полезно, но не для всего

SMB compression в Windows Server 2022 - это сжатие данных при передаче по SMB 3.1.1. Алгоритмы LZ4 и XPRESS, включается через Set-SmbServerConfiguration или на уровне конкретного share.

Работает хорошо на текстовых данных, логах, документах. На уже сжатых форматах (резервные копии в zip/7z, медиафайлы, базы данных которые сами сжимают данные внутри) - накладные расходы на попытку сжать несжимаемое. Не катастрофа, но и выигрыша нет.

Практически интересно для файловых серверов с хранилищами документов и логов через медленные WAN-каналы. Если есть ветки или удалённые офисы с доступом к файловому серверу через канал до 100 Мбит - стоит тестировать. Если всё в локальной сети с быстрым каналом - сжатие добавит нагрузку на CPU без видимого выигрыша.

SMB over QUIC - это отдельная история, и там требования жёстче: только Azure Edition и только с соответствующей лицензией. На стандартных серверах Standard/Datacenter этой функции нет.

Когда реально пора мигрировать с WS2019

Честный ответ: не сейчас, если нет конкретной причины.

Windows Server 2019 на mainstream support до января 2024 года, extended support до января 2029. Никакой технической необходимости мигрировать в ближайшие кварталы нет.

Конкретные причины начать смотреть на 2022 уже сейчас:

• Новые серверы. Если закупаем новое железо - ставить сразу WS2022. Незачем с нуля поднимать WS2019 на новом сервере, если всё равно планируем на 2022.
• Secured-Core нужен. Если есть требование по Secured-Core Server - например, отдельные требования безопасности или клиент сам попросил - тогда 2022 обоснован.
• TLS 1.0/1.1 надо убрать. WS2019 требует ручного отключения TLS 1.0/1.1 через реестр или групповые политики. В WS2022 они отключены из коробки. Если задача стоит - в WS2022 это само решается.

Миграция с работающего WS2019 ради самой миграции - это работа без выхлопа. In-place upgrade с WS2019 на WS2022 технически поддерживается, но мы предпочитаем новое развёртывание с переносом ролей: меньше неожиданностей.

Что делаем сейчас

По клиентам на managed-сопровождении ситуация такая: инвентаризацию железа по Secured-Core совместимости мы начали ещё в июле, когда готовились к GA. Список серверов под новые задачи - там WS2022 пойдёт с нуля. Действующие серверы на WS2019 - работают, трогать не будем без причины.

Firmware-обновления для проблемных RAID-контроллеров, которые мы выявили на стенде, уже запланированы в ближайший сервисный цикл - это делается в любом случае независимо от версии ОС, просто повод проверили заранее.

Основное наблюдение по GA: релиз вышел в предсказуемом состоянии. RC-тестирование было не зря.