Active Directory · 17 мин чтения

Миграция Active Directory: переносим домен на новые контроллеры без простоя

Миграция Active Directory: переносим домен на новые контроллеры без простоя

Привет! Меня зовут Семёнов Евгений Сергеевич, и я руковожу компанией АйТи Фреш. За мои 15 лет в администрировании AD я лично провёл больше 30 миграций. Представляете, это были проекты самых разных масштабов: от небольших офисов на 25 пользователей до огромных многосайтовых холдингов, где учётных записей было до 1500! И знаете, что я вам скажу честно? Миграция домена — это такая задачка, где примерно половина всех проектов терпит неудачу. Причём дело не всегда в сложности, гораздо чаще админы просто упускают из виду или перепрыгивают через по-настоящему критичные шаги. Этот гайд как раз для того, чтобы показать вам правильный порядок действий. В нём я не только поделюсь инструкцией, но и покажу реальный кейс переноса с Server 2012 R2 на Server 2022 для холдинга, в котором работало 400 пользователей.

Зачем вообще мигрировать AD

Поводов сменить контроллеры домена обычно три, и они часто наслаиваются друг на друга:

Когда миграция выполнена правильно, это прямо-таки находка! Вы разом избавляетесь и от устаревшего железа, и от старой ОС, да ещё и всех тех «косяков», что накопились в схеме за долгие годы. Но вот если что-то пойдёт не так… Ох, это беда! Могут запросто пропасть GPO, куда-то исчезнуть DNS-зоны, сломаться репликация. И потом вы будете буквально две недели выслушивать от пользователей панические крики: «У меня файлы пропали!»

Архитектурные решения перед стартом

Прежде чем что-то делать, садимся и решаем четыре вопроса:

  1. Сколько новых DC нужно? Минимум два для отказоустойчивости. Для крупных распределённых сетей — один на сайт плюс RODC в филиалах.
  2. Каков целевой функциональный уровень домена и леса? Для Windows Server 2022 — рекомендуется уровень Windows Server 2016 (новых уровней Microsoft с 2016 года не выпускала). Поднимать имеет смысл только если все DC уже на 2016+.
  3. Где будут размещены новые DC и какие у них IP? Желательно те же IP, что у старых, но не обязательно. На IP опираются клиенты с жёстко прописанными DNS — их потом проще не переконфигурировать.
  4. Какая стратегия миграции SYSVOL? Если ваш домен раньше работал на FRS (репликация SYSVOL до Server 2008), нужно сначала перейти на DFSR через утилиту dfsrmig. Без этого новый Server 2022 откажется становиться DC.

Шаг 1. Аудит текущего состояния домена

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

# Версия и функциональный уровень
Get-ADForest | Select-Object Name, ForestMode, SchemaMaster, DomainNamingMaster
Get-ADDomain | Select-Object Name, DomainMode, PDCEmulator, RIDMaster, InfrastructureMaster

# Все DC в домене
Get-ADDomainController -Filter * | Select-Object Name, OperatingSystem, Site, IPv4Address

# Состояние репликации
repadmin /replsummary
repadmin /showrepl * /csv | Out-File "C:\Audit\repl-before.csv"

# Проверка SYSVOL — DFSR или FRS?
dfsrmig /getmigrationstate

# Проверка ошибок репликации
Get-ADReplicationFailure -Target * -Scope Server | Select-Object Server, Partner, FailureCount, FirstFailureTime, LastError

Если на этом этапе у вас уже есть ошибки репликации, lingering objects или незавершённая миграция SYSVOL — миграцию запускать НЕЛЬЗЯ. Сначала чиним. Иначе все проблемы переедут на новые DC и умножатся.

Шаг 2. Подготовка схемы — adprep

Сначала нам нужно расширить схему AD, чтобы она была готова к новой версии Windows. Для этого используем команду Adprep. Запускать её будем прямо с установочного носителя свежей версии Windows Server — того самого ISO-образа Server 2022. Важный момент: заходим локально под учётной записью Schema Admin (она же является членом группы Enterprise Admins) на наш текущий Schema Master:

# С монтированного ISO Server 2022, в каталоге support\adprep
.\adprep.exe /forestprep
# Через 5-15 минут
.\adprep.exe /domainprep
# Если планируете в будущем readonly DC
.\adprep.exe /domainprep /gpprep
.\adprep.exe /rodcprep

После adprep — ждём минимум час и проверяем репликацию схемы по всем сайтам:

repadmin /showrepl * /csv | Out-File "C:\Audit\repl-after-adprep.csv"
repadmin /replsummary

Если есть ошибки репликации схемы — стоп, разбираемся, без полной репликации новые DC не поднимутся.

Шаг 3. Установка первого нового контроллера домена

Теперь берём наш новенький сервер с Windows Server 2022 — неважно, физический он или виртуальный — и проводим минимальную, но важную подготовку. Задаём ему имя, прописываем статический IP, а затем вводим его в домен. И только после этого приступаем к установке роли AD DS:

# Установка роли
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools

# Промоушн в DC
Install-ADDSDomainController `
  -DomainName "corp.example.ru" `
  -SiteName "MainOffice" `
  -InstallDns:$true `
  -ReplicationSourceDC "DC01.corp.example.ru" `
  -DatabasePath "D:\NTDS" `
  -LogPath "D:\NTDS\Logs" `
  -SysvolPath "D:\SYSVOL" `
  -SafeModeAdministratorPassword (Read-Host -AsSecureString "DSRM password") `
  -Force:$true

Сервер перезагрузится. После этого — критическая часть: проверяем, что репликация со старыми DC прошла полностью:

repadmin /showrepl
repadmin /replsummary
dcdiag /v /c | Out-File "C:\Audit\dcdiag-newdc1.txt"

В выводе dcdiag не должно быть failures. Если есть — фиксим прежде, чем поднимать второй новый DC.

Шаг 4. Установка второго и последующих DC

После того как первый новый DC прошёл все проверки и реплицируется со старыми, поднимаем второй (и последующие) той же командой Install-ADDSDomainController. Источником репликации лучше указывать первый новый DC — так снизим нагрузку на старые серверы.

Через 24 часа после ввода всех новых DC — обязательный полный мониторинг репликации:

Get-ADReplicationFailure -Scope Forest |
  Select-Object Server, Partner, FailureCount, LastError |
  Format-Table -AutoSize

Get-ADReplicationPartnerMetadata -Target * -Scope Server |
  Select-Object Server, Partner, LastReplicationSuccess, LastReplicationResult

Если LastReplicationSuccess для каждой пары старше 1 часа — есть проблема, разбираемся.

Шаг 5. Перенос FSMO-ролей

FSMO (Flexible Single Master Operations) — это пять ролей, которые в каждый момент времени могут быть только на одном DC. Перед понижением старых DC переносим все пять на новые. Удобнее всего — через PowerShell, одной командой:

Move-ADDirectoryServerOperationMasterRole `
  -Identity "NEWDC01" `
  -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster `
  -Confirm:$false

Проверяем, что все роли уехали:

Get-ADForest | Select-Object SchemaMaster, DomainNamingMaster
Get-ADDomain | Select-Object PDCEmulator, RIDMaster, InfrastructureMaster
netdom query fsmo

Все пять ролей должны указывать на новый DC. Дальше — критично: ждём минимум 24 часа реальной работы с переносом нагрузки на новые DC. Если за сутки ничего не сломалось, идём дальше.

Шаг 6. Перенаправление DNS-клиентов

Имейте в виду: самый распространённый корень всех зол после миграции — это, конечно же, клиенты, у которых DNS-серверы прописаны вручную! Если ваш DHCP сейчас раздаёт IP-адреса старых DC в качестве DNS-серверов, то не забудьте поменять опции 6 (DNS Servers) на новые DC. А если у вас есть устройства со статически назначенными IP-адресами — например, серверы или какие-то специфичные клиенты — то их придётся править руками, никуда не денешься.

# Изменение DHCP scope option
Set-DhcpServerv4OptionValue -ComputerName "DHCP01" `
  -OptionId 6 -Value "10.0.0.10","10.0.0.11" -ScopeId 10.0.0.0

# Проверка форвардеров на DNS-серверах
Get-DnsServerForwarder
Get-DnsServerZone -Name "corp.example.ru"

Если хотите минимизировать риски — старые DC можно временно оставить как DNS-серверы (без роли DC), пока все клиенты не получат новые настройки.

Шаг 7. Корректное понижение старых DC

Как только убедились, что все роли успешно перенесены, репликация работает как часы, а DNS переключён куда надо — самое время приступить к понижению старых DC. Делаем это на каждом старом контроллере, строго по очереди:

Uninstall-ADDSDomainController `
  -DemoteOperationMasterRole `
  -RemoveDnsDelegation:$false `
  -LocalAdministratorPassword (Read-Host -AsSecureString "Local admin password") `
  -Force

Сервер перезагрузится в режим member server. На этом этапе можно его выключить или вывести из домена окончательно.

После понижения проверяем, что метаданные в AD очистились:

Get-ADDomainController -Filter * | Select Name, IPv4Address
nltest /dclist:corp.example.ru
repadmin /showrepl
dcdiag /v

Если старый DC присутствует в выводе или есть ошибки — выполняем metadata cleanup через ntdsutil или утилиту Remove-ADDomainController -Identity "OLDDC01" -ForceRemoval с другого DC.

Шаг 8. Финальные проверки и повышение функционального уровня

После того как все старые DC выведены, делаем последний контрольный обход:

# Все DC только новые?
Get-ADDomainController -Filter * | Select Name, OperatingSystem

# Репликация чистая?
Get-ADReplicationFailure -Scope Forest

# DCDIAG?
dcdiag /v /c | Select-String "failed"

# DNS чистый?
Get-DnsServerResourceRecord -ZoneName "corp.example.ru" -RRType A |
  Where-Object {$_.HostName -eq "@"}

Если всё чисто — можем поднимать функциональный уровень домена и леса:

Set-ADDomainMode -Identity "corp.example.ru" -DomainMode Windows2016Domain
Set-ADForestMode -Identity "corp.example.ru" -ForestMode Windows2016Forest

Помните: повышение функционального уровня необратимо, понизить нельзя. Делать это имеет смысл только когда вы уверены, что все DC новые.

Реальный кейс: холдинг 400 пользователей с Server 2012 R2 на Server 2022

Расскажу вам про один наш кейс. В январе 2026 года к нам, в АйТи Фреш, обратился крупный промышленный холдинг — они занимаются производством стройматериалов. У них был центральный офис в Москве и ещё два региональных — в Московской и Тверской областях. Инфраструктура такая: домен крутился на Server 2012 R2, было 4 контроллера, порядка 400 пользователей, 60 GPO и 230 групп безопасности. Их главная задача звучала так: нужно было переехать на Server 2022, и самое главное — чтобы пользователи вообще не почувствовали никакого простоя.

Работы мы спланировали на 5 рабочих дней:

И что вы думаете? За все пять дней — ни одного обращения в саппорт от пользователей! Это ли не успех? Был, правда, один совсем небольшой инцидент: на 3 серверах, где IP старых DC были прописаны статически, застряли кеши DNS. Но это легко решилось: мы сделали ipconfig /flushdns, перезагрузили, и всё тут же заработало.

Стоимость работ — 280 000 руб. за полный цикл. Заодно мы выгрузили в архив 67 неактивных учёток, которые HR подтвердил как уволенных, и удалили 14 устаревших GPO. А бонусом провели аудит безопасности и составили план дальнейшей закалки домена (FGPP, AD Recycle Bin, аудит входов).

Типичные ошибки при миграции и как их избежать

Что я регулярно вижу в чужих миграциях, которые приходится «спасать»:

Сделаем миграцию AD без боли и простоев

Я лично провёл больше 30 миграций доменов — от 25 до 1500 пользователей. Полный цикл: аудит, план, развёртывание новых DC, перенос FSMO, корректное понижение старых, финальные проверки и обучение вашего штатного админа. Бесплатное обследование инфраструктуры за 2 часа на месте, фиксированный бюджет проекта без неожиданностей.

Телефон: +7 903 729-62-41
Telegram: @ITfresh_Boss
Семёнов Евгений Сергеевич, директор АйТи Фреш

FAQ — частые вопросы по миграции AD

Можно ли мигрировать AD без простоя для пользователей?
Да. Современная миграция выполняется в горячем режиме: новые DC поднимаются параллельно со старыми, после полной репликации FSMO-роли и DNS переводятся на новые, старые корректно понижаются. Пользователи не замечают переключения.
Сколько времени занимает миграция домена 400 пользователей?
Полный цикл — 2–4 рабочих дня: подготовка схемы (adprep), развёртывание двух новых DC, проверка репликации 24–48 часов, перевод FSMO, понижение старых DC. На крупных доменах с несколькими сайтами — до недели.
Зачем нужен adprep и что он делает?
Adprep расширяет схему AD под новую версию Windows Server, добавляя необходимые атрибуты и классы. Запускается один раз с носителя новой версии Windows на текущем Schema Master перед вводом первого нового DC. Без adprep новый DC не сможет подняться в существующем домене.
Какие FSMO-роли надо переносить и как?
Пять ролей: Schema Master, Domain Naming Master, RID Master, PDC Emulator, Infrastructure Master. Перенос — командой Move-ADDirectoryServerOperationMasterRole или ntdsutil. Сначала переносим, проверяем работу 24 часа, только потом понижаем источник.
Что будет, если просто выключить старый DC без понижения?
Останутся метаданные в AD, репликация будет пытаться достучаться до несуществующего сервера, в логах посыпятся ошибки KCC. В DNS останутся SRV-записи. Очистка через ntdsutil metadata cleanup — обязательная процедура.

Похожие статьи

Подпишитесь на рассылку ITfresh

Раз в неделю — практические гайды для руководителя IT и сисадмина: безопасность, 1С, миграции, резервные копии, лайфхаки из реальных проектов.

Реквизиты оператора персональных данных

ООО «АЙТИ-ФРЕШ», ИНН 7719418495, КПП 771901001. Юридический адрес: 105523, г. Москва, Щёлковское шоссе, д. 92, корп. 7. Контакт: info@itfresh.ru, +7 903 729-62-41. Оператор обрабатывает e-mail подписчика в целях рассылки информационных и рекламных материалов до момента отзыва согласия.