Как перенести контроллер домена и сохранить работу AD

Переносите контроллер домена через добавление нового сервера в существующий домен, проверку репликации и штатный вывод старого DC. Я начинаю с диагностики AD и DNS, а не с копирования файлов: это позволяет поймать проблемы до переключения и сохранить рабочий контроллер на время проверки.

Сначала проверьте здоровье домена

Я не начинаю перенос с установки Windows. Сначала фиксирую, какие контроллеры сейчас обслуживают домен, где работают DNS и глобальный каталог, какие роли FSMO у каждого DC и как клиенты находят службы домена. Затем смотрю репликацию и системные журналы. Если старый контроллер уже теряет связь с партнёрами или не регистрирует нужные DNS-записи, новый сервер не «вылечит» каталог. Он получит ту же исходную проблему, а отладка станет сложнее, потому что в схеме появится ещё один участник. Для такого этапа полезен аудит Active Directory: сначала понять состояние, затем менять инфраструктуру.

Встроенная диагностика dcdiag проверяет разные области состояния контроллеров; для DNS у неё есть отдельный тест. repadmin /replsummary помогает увидеть сводку ошибок репликации, а repadmin /showrepl показывает сведения о входящей репликации. Это диагностические команды, не ремонтные заклинания: зелёная команда не заменяет проверку журналов, DNS и фактической работы пользователей. Если найдено расхождение, сначала выясняю его причину и только после исправления повторяю проверку. Слепо запускать принудительную синхронизацию ради красивого вывода — плохой план.

В кейсе студии «Юпитер» я заметил устаревшие DNS-записи до начала переключения и разобрался с ними заранее. Это хороший пример того, почему короткая предварительная проверка иногда экономит больше времени, чем попытка «поскорее начать». Смотрю не только на зону домена, но и на записи обнаружения контроллеров, в том числе в _msdcs, а также на разрешение имён с рабочих станций. Контроллеры регистрируют несколько типов записей; вручную менять A-запись «старый адрес на новый» вместо штатного обновления регистрации — значит рисковать сломать записи, которые привязаны к конкретному DC.

• Сохранить текущие результаты диагностики и список DC.
• Проверить репликацию и DNS до изменений.
• Зафиксировать владельцев ролей FSMO и назначение каждого сервера.

Подготовьте новый сервер и сеть

Новый сервер должен соответствовать поддерживаемой конфигурации домена и требованиям выбранной версии Windows Server. Я заранее проверяю совместимость леса и домена, состояние SYSVOL, сетевую связность, DNS и доступность необходимых служб между серверами. Универсальной пары «откройте LDAP и LDAPS» недостаточно: Active Directory использует несколько сетевых протоколов, а точный набор зависит от сценария и сетевой схемы. Поэтому сверяю правила межсетевого экрана с документацией Microsoft для конкретной среды, не публикую порты наугад и не отключаю firewall целиком для «проверки на минутку».

До повышения нового сервера до контроллера задаю постоянную сетевую конфигурацию и направляю его DNS-клиент на внутренний DNS, который разрешает записи домена. Внешний резолвер в настройках сетевого адаптера контроллера не нужен: внешние имена должен разрешать внутренний DNS через настроенные пересылки. Для DNS-клиентов самих контроллеров у Microsoft есть рекомендации, которые зависят от числа DC и роли локального DNS; правило «старый обязательно первый, внешний обязательно второй» универсальным не является. На новом сервере я также сверяю источник времени и доменную иерархию синхронизации. Kerberos чувствителен к расхождению времени, поэтому проблема часов может выглядеть как поломка входа или репликации.

Роль DNS на новом контроллере нужна, если этот сервер будет обслуживать DNS-зоны Active Directory. Но установить DNS и правильно включить его в репликацию зон — разные задачи. Перед продвижением выясняю, где размещены зоны, какой у них тип, какова область репликации и кто выдаёт адреса клиентам по DHCP. Тогда можно запланировать обновление клиентской конфигурации без массовой ручной правки компьютеров. Для правил групповой политики и структуры домена отдельно проверьте практики Active Directory GPO: перенос DC сам по себе не требует перестраивать все политики.

• Проверить совместимость версии и состояние SYSVOL.
• Настроить постоянный IP и внутренний DNS.
• Проверить связь между DC по нужным протоколам.
• Определить, кто будет обслуживать DNS и DHCP после перехода.

Добавьте контроллер и дождитесь репликации

Новый компьютер сначала присоединяю к домену как обычный сервер, затем добавляю роль AD DS и повышаю его до дополнительного контроллера существующего домена. В PowerShell для этого предназначен Install-ADDSDomainController; перед запуском сверяю параметры по версии Windows Server и сценарию. В мастере или командлете выбираю домен, площадку и, когда это необходимо, источник репликации. Указывать конкретный источник полезно, если в среде несколько DC и нужно контролировать маршрут начального копирования. Но один параметр источника не заставит репликацию завершиться успешно, если DNS, сеть или каталог уже неисправны.

При продвижении задаётся пароль режима восстановления служб каталогов (DSRM), затем сервер перезагружается и начинает работать как DC. Я не измеряю успех минутами и не обещаю «всё скопируется за четверть часа»: длительность зависит от объёма каталога, связности, расписания и состояния репликации. Проверяю, что новый контроллер появился в Active Directory Sites and Services, что SYSVOL и NETLOGON доступны, что нужные DNS-записи зарегистрированы, а тесты диагностики не показывают новых ошибок. Наличие OU и пользователей в оснастке — ещё не доказательство исправности: важно проверить репликацию изменений в обе стороны и вход с тестовой рабочей станции.

Для обмена SYSVOL проверьте, какой механизм уже используется в домене, и убедитесь, что он исправен до миграции. Старые среды могут требовать отдельного плана для переноса с FRS на DFSR; добавление нового DC не является поводом пропустить эту проверку. Не удаляйте старые записи «на всякий случай» и не копируйте базу каталога вручную. Если новый сервер нельзя корректно повысить или SYSVOL не готов, останавливаюсь и разбираю конкретную ошибку в журналах. На этом этапе пригодится статья о лесе доменов Active Directory, если структура окружения сложнее одного домена.

• Повысить сервер штатным мастером или командлетом AD DS.
• Проверить SYSVOL, NETLOGON и DNS-регистрацию.
• Сверить репликацию и вход пользователей до переключения.

Перенесите роли FSMO и переключите DNS

После проверки нового DC переношу роли FSMO штатной передачей. Их пять: две роли уровня леса и три уровня домена. Для планового перехода используется передача роли; захват роли нужен для аварийного случая, когда прежний владелец недоступен, и это не одно и то же действие. В PowerShell роли можно передать командлетом Move-ADDirectoryServerOperationMasterRole, указав целевой сервер и роли. Сначала фиксирую текущих владельцев, затем после передачи повторно проверяю, где находится каждая роль. Команду не стоит вставлять в рабочую консоль без подстановки проверенных имён и понимания последствий.

Затем переключаю DNS-потребителей: DHCP-область, статически настроенные серверы, сетевое оборудование и приложения, если они используют адрес старого DNS. Групповая политика может помочь с управляемыми клиентами, но не является универсальным переключателем DNS для всех устройств. DNS-зоны Active Directory должны корректно реплицироваться, а записи локатора DC должны указывать на действующие контроллеры. Не подменяйте GUID-запись CNAME в _msdcs обычной A-записью и не удаляйте записи старого сервера до его штатного вывода и проверки автоматической регистрации.

После переключения проверяю вход, применение политик, разрешение доменных имён и доступность приложений, которые обращаются к LDAP или используют доменную аутентификацию. Проверку провожу с нескольких типичных рабочих станций и сервисных узлов, а не только с администраторского ноутбука. На DNS-клиенте важно проверить не только адрес сервера в настройках, но и ответ на запросы домена и служб. Если используется несколько площадок, проверяю также выбор DC по сайту: клиенты не должны продолжать ходить к серверу, который уже выводится. Клонирование старого Windows Server не заменяет эту процедуру: у клона должны быть корректные уникальные имя и идентичность, см. Разбор разных имён Windows Server.

• Передать и перепроверить все роли FSMO.
• Обновить источники DNS у DHCP и устройств.
• Проверить аутентификацию, GPO и приложения после переключения.

Штатно выведите старый DC и закройте перенос

Старый контроллер не отключаю от сети до понижения роли. Сначала проверяю, что на нём не осталось единственного DNS, глобального каталога или роли FSMO, что репликация здорова и что клиенты больше не зависят от него. Затем выполняю штатную демоцию через Server Manager или Uninstall-ADDSDomainController и проверяю результат на оставшихся контроллерах. Принудительное удаление — аварийный вариант для сервера, который невозможно штатно связать с доменом. Microsoft предупреждает: принудительная демоция оставляет метаданные и может потерять изменения, которые не успели реплицироваться. Это плохой план «на всякий случай».

После штатного вывода проверяю DNS, Sites and Services, репликацию, список контроллеров, журналы и клиентские настройки. Если сервер действительно демонтирован корректно, удаление его роли и метаданных — часть штатного сценария; вручную вычищать все записи подряд без проверки опасно. Не оставляю отключённый старый DC «резервной копией»: доменный контроллер не является резервной копией каталога, а включение старого состояния позже может создать новые проблемы. Для восстановления нужны проверенные резервные копии и подходящая процедура восстановления AD, а срок хранения старого оборудования выбирают по плану отката и внутренним требованиям, а не по выдуманному правилу «обязательно 14 или 30 дней».

В завершение сохраняю список изменений, результаты проверок и схему DNS после переключения. В течение согласованного периода наблюдаю за журналами и обращениями пользователей; конкретную длительность определяю по критичности сервисов и возможностям отката. Если что-то ломается, сначала устанавливаю, какой именно компонент зависит от старого DC, и возвращаю его корректную настройку, а не включаю прежний сервер в надежде, что он «сам всё починит». Хорошая миграция заканчивается не отключением старого железа, а подтверждением, что домен, DNS, аутентификация и прикладные системы работают на новой схеме.

• Штатно понизить старый DC после проверок.
• Проверить метаданные, DNS и репликацию после демоции.
• Зафиксировать итог и план восстановления.

Частые вопросы