В связи со сменой сервис провайдера и переездом из одного датацентра в другой возникла необходимость миграции контроллеров домена леса и трех его доменов. Решено было поднять свежие машины в новом датацентре, мигрировать на них текщие AD DS роли, после чего утилизировать старые серверы домена.
Наш лес состоит из трех доменов: одного корневого (в котором ничего нет, кроме домен котроллеров) и двух дочерних доменов (там находится весь функционал). Основой разделения доменов служило разделение обязанностей между ИТ командой компании и ИТ специалистами сервис провайдера. В каждом домене существует по два домен контроллера: первый на реальном железе, второй в виде виртуальной машины. Функциональный уровень леса – Windows 2008 R2. Операционная система установлена на всех серверах та же. На каждом сервере имеется DNS сервер с интегрированными в AD зонами.
Ниже я в общих чертах опишу весь процесс.
Шаг 1: Инсталляция новых контроллеров домена.
После развертывания операционной системы патчим ее и только потом запускаем dcpromo и добавляем AD DS роли. Все сервера добавляем в существующий лес и соответствующий существующий домен. В качестве дополнительных компонентов всем добавляем DNS сервер и глобальный каталог. NTDS с логами и SYSVOL идут на отдельный от системного диск.
После установки и перезагрузки в настройкахTCP/IP меняем адреса DNS серверов таким образом, чтобы первичный DNS указывал на самого себя (именно полный IP, а не 127.0.0.1 для предотвращения проблем с KDC) вторичным я указывал контроллер старого датацентра (в дальнейшем это нужно будет поменять). В настройках DNS сервера так же не забываем настроить форвардинг.
Шаг 2: Передача FSMO ролей.
Для того, что перенести надлежащим образом Operation Master роли (FSMO является устаревшим термином) необходимо сначала проверить текущее положение вещей. На этом шаге нашим помощником является PowerShell с модулем ActiveDirectory.
Сначала проверяем положение ролей уровня леса:
Get-ADForest | select SchemaMaster,DomainNamingMaster
Вывод будет содержать хосты держащие каждую роль.
Доменные роли проверяем для каждого из дочерних доменов:
Get-ADDomain | select PDCEmulator,RIDMaster,InfrastructureMaster
На основании полученной информации делаем табличку, куда помещаем старые контроллеры с их текущими ролями и новые запланированными для переноса ролями. В моем случае, в соответствии с рекомендациями компании Майкрософт, было решено поместить Schema Master и Domain Naming Master на первый контроллер корневого домена, остальные три роли PDC Emulator, RID Master и Infrastructure Master на второй виртуальный котроллер корневого домена. Контроллеры дочерних доменов могу держать только три роли: PDC Emulator, RID Master и Infrastructure Master, которые были перенесены на каждый первый физический контроллер домена, второй виртуальный оставался только держателем глобального каталога.
Ремарка: существует утверждение, что нельзя держать роль Infrastructure Master на сервере, являющимся держателем глобального каталога. Случай, когда все контроллеры домена держатели глобального каталога является исключением.
Перенос ролей осуществляется при помощи PowerShell с любого члена домена, но т.к. нам необходимо использовать командлеты модуля ActiveDirectory, то делать это лучше с любого домен контроллера т.к. модуль устанавливается вместе с AD DS ролью. В качестве Identity указываем имена новых серверов, принимающих роли.
Переносим Schema Master и Domain Naming Master:
Move-ADDirectoryServerOperationMasterRole -Identity "DCROOT001" -OperationMasterRole 3,4
Переносим PDC Emulator, RID Master и Infrastructure Master в корневом домене:
Move-ADDirectoryServerOperationMasterRole -Identity "DCROOT002" -OperationMasterRole 0,1,2
Переносим PDC Emulator, RID Master и Infrastructure Master в дочерних доменах:
Move-ADDirectoryServerOperationMasterRole -Identity "DCSUB101" -OperationMasterRole 0,1,2
Move-ADDirectoryServerOperationMasterRole -Identity "DCSUB201" -OperationMasterRole 0,1,2
После переноса ролей проверяем все ли на месте прогоняя знакомые нам команды:
Get-ADForest | select SchemaMaster,DomainNamingMaster
Get-ADDomain | select PDCEmulator,RIDMaster,InfrastructureMaster
Дальше ряд стандартных тестов:
dcdiag
repadmin /showrepl
repadmin /replsummary
…
Шаг 3: Смена IP адресов.
В случае, если в домене существуют серверы или приложения использующие IP адреса старых домен котроллеров (точнее их DNS серверов) перенастройка всего этого хозяйства может стать большой проблемой. В качестве довольно простого фикса можно назначить старым контроллерам новые временные адреса, а их широко известные IP назначить новым контроллерам.
Данная операция может пройти довольно просто, но может и требовать дополнительных действий в случае, если новые сервера находятся в другой подсети, другом vlan и т.п. Так как вместе со сменой IP адреса сервера нужно еще сменить IP шлюза, данные действия придется координировать с сетевиками, поддержкой виртуальной среды и т.п., в зависимости от структуры вашей компании.
В процессе изменения настроек TCP/IP у вас обязательно должен быть доступ к консоли каждого сервера: iLO, DRAC, vSphere…
Шаг 4: Служба времени.
По умолчанию в домене все клиенты синхронизируют время с контроллером домена являющимся PDC Emulator. Во избежание рассинхронизации времени, которая может привести к катастрофичным последствиям, этот момент нужно проконтролировать сразу после переноса ролей. Основываясь на своем опыте могу сказать, что после переноса ролей служба времени не перенастраиваится автоматом на новые PDC. Соответственно тут нужно поработать ручками, привлекая w32tm.
Делаем старые контроллеры домена не авторитарными для синхронизации времени:
w32tm /config /syncfromflags:domhier /reliable:no /update
На корневом PDC настраиваем внешний источник синхронизации времени:
w32tm /config /syncfromflags:manual /manualpeerlist:«0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org» /reliable:yes /update
Остальные контроллеры просто делаем авторитарными для синхронизации:
w32tm /config /syncfromflags:domhier /reliable:yes /update
Также для всех контроллеров полезно сделать следующее:
w32tm /resync /rediscover /nowait
Обязательно делаем рестарт службы времени. Если серверов много, то запускаем скрипт, направляя его в нужное OU с серверами:
$Servers = Get-ADComputer -SearchBase "OU=Servers,DC=domain,DC=com" –filter * | select Name -ExpandProperty Name
$Log = "$homeW32time_restart_log.txt"
$Date = Get-date
#Starting
Write-Host "Start of processing: $Date"
Write-Output "Start of processing: $Date" | Out-File -FilePath $Log -Append
foreach ($Server in $Servers)
{
Write-Host "Checking if $Server is online..."
$Online = Test-Connection -Count 2 -ComputerName $Server -Quiet
if ($Online -eq "True"){
Write-Host "$Server is online."
Write-Host "starting Time service on $server"
$TimeService = Get-WmiObject -ComputerName $server Win32_Service -Filter "Name='W32time'"
$TimeService.StopService() > $null
$TimeService.StartService() > $null
Write-Host "Time service has been started on $server"
Write-Output "Time service has been started on $server" | Out-File -FilePath $Log -Append
}
else
{
Write-Host -ForegroundColor Red "$Server is offline. Going to next server."
Write-Output "$Server is offline." | Out-File -FilePath $Log -Append
}
}
Write-Host "Done! $Date"
Write-Output "End of processing: $Date"| Out-File -FilePath $Log -Append
Шаг 5: утилизация старых контроллеров домена.
Прежде, чем удалять AD DS роль со старых домен контроллеров, рекомендуется сначала выключить их на некоторое время, недели обычно достаточно. Если ничего катастрофичного не произошло за это время, то включаем их снова. Даем постоять немного дня для проведения репликации набежавших за время их отсутствия изменений. Запускаем dcpromo, удаляем АД роль, перезагружаем, выводим из домена, только потом выключаем. Блокируем аккаунты хостов.
Через некоторое время, по прошествии полноценной репликации с момента декомиссии старых контроллеров, заходим в AD Sites and Services и удаляем все старые репликационные связи. Старые хосты так же не должны там нигде фигурировать.
Вдохновения:
technet.microsoft.com/en-us/library/ee617195.aspx
Автор: alex_at
