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

Миграция 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

Adprep расширяет схему AD под новую версию Windows. Запускается с установочного носителя новой версии 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 подписчика в целях рассылки информационных и рекламных материалов до момента отзыва согласия.