Windows Server 2019: Nano Server только для контейнеров, Core для всего остального - мигрируем с 2012 R2

Несколько клиентов всё ещё сидят на Windows Server 2012 R2. Поддержка этой версии заканчивается в октябре 2023-го, но ждать до последнего - плохая стратегия. В январе взяли один из таких парков и начали планомерно переводить на Windows Server 2019. Заодно выяснили, что разница между вариантами установки за семь лет стала принципиальной.

Три варианта - теперь два рабочих

В 2016-м Microsoft добавила Nano Server как облегчённый вариант для bare-metal и VM: без GUI, маленький footprint, быстрый старт. Идея звучала разумно. На практике оказалось, что поддержка ролей там настолько куцая, что реальных применений было мало.

В Server 2019 Microsoft сделала чёткое разграничение:

• Server Core - установка без GUI, но с полноценным набором ролей: AD DS, DNS, DHCP, File Server, IIS, Hyper-V и далее по списку. Это основной вариант для большинства серверных задач.
• Server with Desktop Experience - полный GUI, нужен там, где без него не обойтись: SQL Server Management Studio, специфичный корпоративный софт с Windows Forms-интерфейсом.
• Nano Server - более не устанавливается на bare-metal или VM как операционная система хоста. Только base image для Windows-контейнеров. Если кто-то читал документацию 2016 года и помнит Nano Server как «лёгкая альтернатива Core» - эта часть устарела.

Это не ошибка в документации, это изменение позиционирования продукта. Nano Server как standalone OS умер тихо.

Что это значит при миграции с 2012 R2

На 2012 R2 у клиентов были разные варианты установки, но разница там была менее принципиальной - GUI включался и выключался через Server Manager, роли были доступны в обоих вариантах. При переезде на 2019 нужно принять решение заранее.

Наша логика выбора для каждого сервера:

• Контроллеры домена, DNS, DHCP - Server Core. Никакого GUI не нужно в принципе, управление через RSAT с рабочей станции администратора, конфигурация через PowerShell. Здесь Core - правильный выбор и с точки зрения атакоемкости: меньше поверхность, меньше компонентов, которые надо патчить.
• Файловые серверы - Server Core, там же DFS Namespace и DFS Replication. Управление через консоль MMC с рабочей станции справляется.
• Terminal Services / RDS - Desktop Experience. Здесь не потому что нужен GUI для администрирования, а потому что часть ролей RDS требует наличия рабочего стола на самом сервере. Это один из тех случаев, где Microsoft оставила GUI как требование.
• Специализированный корпоративный софт - Desktop Experience без вариантов, там обычно написано «требуется .NET Framework плюс Windows 7 и выше» и ничего про headless.

Разница в поведении, которая нас удивила

Проблемы начались не там, где ожидали. PowerShell и стандартные роли поднялись без неожиданностей. Неожиданности пришли из специфики 2012 R2.

NTLM и CredSSP по умолчанию. На 2012 R2 часть клиентов жила с CredSSP включённым по дефолту на WinRM - потому что так исторически настроили. Server 2019 Core с дефолтными настройками это не разрешает, и скрипты автоматизации, которые передавали учётные данные через CredSSP, тихо перестали работать. Не с ошибкой «отказано в доступе», а с timeout-ом - что сбивало с толку. Пришлось разобраться и правильно настроить WinRM с Kerberos там, где это возможно, вместо того чтобы снова включать CredSSP.

Scheduled Tasks и их миграция. Задачи планировщика с 2012 R2 в формате XML экспортируются и импортируются на 2019, но несколько задач с триггерами на события (EventTrigger) отказались запускаться. Причина - изменения в ID событий или имена источников событий слегка поехали между версиями. Без журнала задачи (Task Scheduler -> History) это почти невозможно отловить - история по умолчанию отключена, включать надо руками.

WMI namespace и старый мониторинг. У одного клиента Zabbix-агент использовал WMI-запросы, которые работали на 2012 R2 и не вернули нужные данные на 2019 - namespace есть, класс есть, а нужное свойство переименовано. Это уже не проблема миграции как таковая, это напоминание, что мониторинг надо проверять отдельно после каждого переезда.

Про Nano Server в контейнерах конкретно

Раз уж разбирались - посмотрели, как Nano Server живёт в Windows-контейнерах. Microsoft публикует три base image для Windows-контейнеров: windows, windows/servercore и windows/nanoserver. Nano Server - самый маленький, без .NET Framework, без PowerShell (только PowerShell Core, отдельно), без большинства Win32 API.

Для чего это подходит: stateless-сервисы на .NET Core, Go, Node.js, которые не тянут Windows API старой школы. Для чего не подходит: почти любой корпоративный или legacy-компонент, который нужно завернуть в контейнер ради DevOps-счастья. Те, кто рассчитывал «поднять старое приложение в Nano Server-контейнере», обычно приходят к servercore - там есть полный .NET Framework и Win32.

Мы ведём несколько клиентов на managed-инфраструктуре, где Windows-контейнеры появляются в Docker Swarm или как промежуточный шаг к Kubernetes. В этом контексте Nano Server как base image имеет смысл именно для новых сервисов, написанных под .NET Core - а не для контейнеризации legacy.

Внутренняя памятка

По итогам первой волны переезда сделали короткий чеклист, которым руководствуемся дальше:

• Выбрать вариант установки до начала миграции, не после. Core vs Desktop Experience - разные образы, конвертации нет.
• Проверить WinRM и способ аутентификации до того, как перенести автоматизацию.
• Включить историю Task Scheduler сразу после установки. Дефолт - выключено, и это больно.
• После миграции прогнать все мониторинговые проверки руками и убедиться, что данные идут. Не «агент запущен», а именно данные.
• Nano Server - не вариант для сервера, только для контейнерного base image. Это надо объяснять клиентам отдельно, потому что они иногда читают старые статьи.

Миграция первых серверов прошла без катастроф, но и без иллюзий, что это быстро. Следующая волна - в феврале.