Мигрируем домен на Windows Server 2003: три вещи проверить до повышения уровня

Очередной клиент дозрел до обновления серверов - и вопрос «на что ставить» решился в пользу Windows Server 2003 без особых колебаний. Платформа вышла весной прошлого года, к этому моменту уже достаточно обкатана, и первые SP1-слухи уже ходят, но выпущенный билд работает нормально. Задача конкретная: ввести новый контроллер домена под 2003, перенести роли FSMO, поднять функциональный уровень домена - и заодно навести порядок с политиками, которые копились с момента первого переезда на Active Directory.

Что поменялось в сравнении с 2000-м

Windows Server 2003 в плане Active Directory - это не просто новая версия, там реально добавили нужные вещи. Переименование домена - появилось. Перетаскивание контроллеров домена между сайтами без лишних танцев - стало проще. Инструмент gpresult наконец дорос до нормального вида, а Resultant Set of Policy в оснастке позволяет симулировать применение политик без того, чтобы идти к пользователю и смотреть, что у него там происходит. Это отдельная радость для тех, кто три часа искал причину в неправильном OU.

Теневые копии тоже появились прямо в коробке - Volume Shadow Copy Service, VSS. Раньше делали резервные копии на лентах и молились, чтобы пользователь не перезаписал файл два часа назад. Теперь теневые копии тома можно включить на файловом сервере, поставить клиент на рабочие станции - и пользователь сам достаёт предыдущие версии файлов через контекстное меню. Не замена полноценным бекапам, но для «я нечаянно всё удалил» спасает.

Три вещи до повышения уровня домена

Это самое важное, о чём стоит сказать отдельно. Повышение функционального уровня домена - операция необратимая. Подняли до Windows Server 2003 - назад, на уровень 2000, уже не опустить. Поэтому перед тем, как нажать кнопку, мы проверяем три вещи.

Первое - все контроллеры домена должны быть под управляемой версией. Если хотите поднять до уровня Windows Server 2003 Native, в домене не должно остаться ни одного контроллера под Windows 2000 или NT 4. Ни живого, ни выключенного, ни «мы его два года назад забыли вывести». Проверяется через Active Directory Users and Computers - Domain Controllers OU, смотрим каждый объект. У клиента обнаружился один контроллер, который официально был «отключён», но учётка в AD жила. Вывели нормально, только потом продолжили.

Второе - репликация между всеми контроллерами должна работать без ошибок. Запускаем repadmin /showreps на каждом DC и смотрим на ошибки. Если репликация сломана и мы поднимаем уровень - после этого починить ситуацию будет гораздо сложнее. У того же клиента один из вспомогательных DC показывал застарелую ошибку репликации по одному разделу - разобрались, принудительно синхронизировали, убедились что чисто, и только тогда двинулись дальше.

Третье - роли FSMO должны быть на актуальном сервере. Если PDC Emulator или RID Master всё ещё висят на старом контроллере, который собираетесь выводить из эксплуатации - сначала переносим роли, потом понижаем старый DC через dcpromo, потом поднимаем уровень домена. Порядок важен. Netdom query fsmo покажет, где что живёт.

Как шла миграция

Схема стандартная: поставили новый сервер с Windows Server 2003, подняли как дополнительный DC в существующем домене (всё ещё на уровне Windows 2000 Mixed). Дождались репликации, убедились что всё ровно. Перенесли роли FSMO на новый сервер. Вывели старый контроллер через dcpromo /forceremoval - у него были проблемы с обычным понижением из-за битого соединения с одним из сайтов, пришлось использовать принудительный вариант с последующей ручной очисткой метаданных в AD.

После этого прошли по чеклисту выше, убедились что в домене остались только DC под 2003, репликация чистая, роли на месте. Подняли уровень домена до Windows Server 2003 через Active Directory Domains and Trusts. Операция занимает секунды, но готовились к ней несколько часов.

Политики: ревизия заодно

Раз уж трогали инфраструктуру - взяли и почистили накопившиеся GPO. За три года в домене успело появиться несколько политик с именами типа «Тест 2» и «GPO копия декабрь», которые были привязаны к OU и непонятно что делали. Включили Resultant Set of Policy в режиме Planning, прогнали по нескольким OU - увидели, что две политики дублируют друг друга, одна конфликтует с другой по параметрам экрана блокировки.

Удалили мусор, переименовали оставшиеся по внятной схеме. Теперь видно что есть и зачем. Мелочь, но когда придётся что-то менять - не придётся разгребать слой за слоем.

Теневые копии включили на файловом сервере сразу - две точки в сутки, хранение на том же томе с ограничением в 10% от объёма. Клиент поставил Shadow Copy Client на рабочие станции. Первый же пользователь, который нечаянно затёр файл на следующий день, достал его сам - без звонка в поддержку.

Сопровождение инфраструктуры в таких случаях и есть про это: не просто поставить новый сервер, а пройти по всем точкам отказа до того, как они выстрелят.