Миграция DC с Windows Server 2003 на 2012 R2: FSMO, функциональный уровень, без простоя

В январе мы инвентаризировали хосты у клиентов и пообещали отдельный пост про контроллеры домена. Вот он. Контроллеры - это первый приоритет, потому что уязвимость в DC после 14 июля означает потенциальный захват всей сети, а не просто одного сервера.

Несколько клиентов на сопровождении имели DC на Windows Server 2003 R2. В одном случае - основной контроллер, без резервного. Мы прошли через всё это, и вот что реально происходит при таком переезде.

Задача и ограничения

Домен - Windows Server 2003 functional level. Нужно добавить новый DC на Windows Server 2012 R2, перенести на него все FSMO-роли, поднять функциональный уровень и вывести старый DC без простоя для пользователей. Рабочий день никто не останавливает, Outlook должен продолжать работать.

In-place upgrade с 2003 на 2012 R2 невозможен в принципе - только параллельная инсталляция. Это отдельная машина (или виртуалка), которая вводится в существующий домен.

Порядок действий

Первое - поднять новый DC. Ставим Windows Server 2012 R2, вводим в домен, запускаем dcpromo (или через Install-ADDSDomainController в PowerShell - на 2012 R2 dcpromo просто вызывает мастер поверх PowerShell-командлета). Ждём завершения репликации. Важно: не трогаем FSMO до тех пор, пока репликация не выровняется. Проверяем через repadmin /replsummary - там видно, есть ли отставание и в каком направлении.

Второе - проверка репликации. repadmin /showrepl покажет подробную картину по каждому разделу (Schema, Configuration, Domain). Ошибок быть не должно. Если есть - разбираемся до того, как идём дальше. Передавать FSMO на DC с кривой репликацией - это гарантированно сломать аутентификацию в самый неудобный момент.

Третье - передача FSMO. Пять ролей: PDC Emulator, RID Master, Infrastructure Master, Schema Master, Domain Naming Master. Первые три - уровень домена, последние два - уровень леса. Передаём через ntdsutil или через GUI в «Active Directory Users and Computers» / «Active Directory Domains and Trusts» / «Active Directory Schema» (Schema требует зарегистрировать оснастку через regsvr32 schmmgmt.dll).

Порядок передачи имеет значение. PDC Emulator передаём первым - именно он отвечает за синхронизацию времени и аутентификацию NTLM, и при проблемах клиенты в первую очередь замечают именно его отсутствие. RID Master можно вторым - без него нельзя создавать новые объекты, но существующие аутентифицируются нормально. Infrastructure Master и Schema Master - в последнюю очередь, их отсутствие проявляется редко и не сразу.

Проверяем передачу: netdom query fsmo - должны быть все пять ролей на новом DC.

Четвёртое - функциональный уровень. Это необратимый шаг, поэтому делаем его только убедившись, что старый DC выведен или готов к выводу. Поднимаем функциональный уровень домена сначала, потом леса:

Set-ADDomainMode -Identity corp.example.local -DomainMode Windows2012R2Domain
Set-ADForestMode -Identity corp.example.local -ForestMode Windows2012R2Forest

После поднятия уровня ряд функций становится доступен - в том числе Managed Service Accounts и Protected Users security group. Но главное - старый DC на 2003 больше не сможет быть контроллером домена в этом лесу. Обратного пути нет.

Про групповые политики

Вот где появляются неожиданности. Когда на новом DC открываешь GPMC и смотришь на политики, которые годами применялись со старого сервера - часть из них показывает предупреждения. Причина: политики создавались в административных шаблонах от 2003-го, а 2012 R2 использует новый формат ADMX.

Проблема не критическая, но требует внимания. ADMX-шаблоны для 2012 R2 хранятся в PolicyDefinitions на SYSVOL. Если старых шаблонов там нет - часть параметров отображается как «Extra Registry Settings» или «Unknown». Политики при этом применяются корректно (значения в реестре есть), но видно их только в разделе «Extra» без понятных названий. Для аудита и последующего управления это неудобно.

Решение - скопировать актуальные ADMX-файлы из C:\Windows\PolicyDefinitions нового сервера в \\corp.example.local\SYSVOL\corp.example.local\Policies\PolicyDefinitions. После этого политики отображаются нормально.

Отдельно проверяем Security Filtering на ключевых политиках - иногда там стоят группы или учётки, которые уже не существуют, и это годами никто не видел. Хорошая возможность подчистить.

Что оказалось неожиданным

Самая нетривиальная ситуация возникла в домене, где PDC Emulator одновременно был DNS-сервером для всей сети. При передаче роли DNS-зоны реплицировались на новый DC нормально, но несколько клиентских машин имели в настройках только IP старого DC. Пока оба сервера работали - всё нормально. Как только старый отключили - у этих машин пропало разрешение имён.

Урок простой и банальный: перед выводом старого DC пройтись по DHCP-серверу и убедиться, что в DNS-настройках выдаётся IP нового контроллера. Звучит очевидно. Но когда всё работало пять лет с одними настройками - проверять это не приходит в голову.

Состояние на сейчас

Несколько доменов переведены. Старые DC на 2003-м выключены, функциональный уровень поднят. Пользователи не заметили ничего, кроме одного случая с DNS, который разрулился быстро.

До июля осталось четыре месяца - вполне достаточно для тех, кто ещё не начал. Главное не оставлять это на конец июня.