Для построение отказоустойчивой инфраструктуры Active Directory и распределения нагрузки необходимо иметь как минимум два контроллера домена. Также рекомендуется создавать дополнительные контроллеры домена на удаленных площадках. В этой статье мы рассмотрим, как развернуть дополнительный контроллер домена в существующем домене AD.
Подготовка Windows Server перед развертыванием DC
Разверните новый сервер (физический или виртуальный) с Windows Server. Рекомендуется использовать одинаковые версии Windows Server на всех DC. В нашем примере это Windows Server 2019.
Выполните первоначальную настройку нового Windows Server
Задайте имя контроллера домена, соответствующее вашей инфраструктуре через Server Manager или с помощью команды PowerShell. Например, spb-dc02:
Rename-Computer -NewName spb-dc02
Задайте статический IP адрес серверу, укажите настройки DNS. В качестве предпочитаемого DNS сервера укажите IP адрес
127.0.0.1
(для более быстрого выполнения DNS запросов), а в качестве альтернативного – IP адрес ближайшего контроллера домена в этом же сайте AD. Можно задать настройки IP и DNS с помощью PowerShell:
Get-NetAdapter
New-NetIPAddress -IPAddress 192.168.13.14 -DefaultGateway 192.168.13.1 -PrefixLength 24 -InterfaceIndex 6
Set-DNSClientServerAddress -InterfaceIndex 6 -ServerAddresses ("127.0.0.1","192.168.10.14")
Задайте часовой пояс, проверьте что на сервере задано корректное время.
Установите обновления Windows (можно установить обновления с локального WSUS сервера или через Windows Update). Для установки обновления Windows можно использовать PowerShell модуль PSWindowsUpdate.
Включите RDP доступ, добавьте ваш Windows Server в домен Active Directory и перезагрузите Windows:
Add-Computer -DomainName winitpro.loc
Restart-Computer -force
Если вы разворачиваете DC для новой удаленной площадки, откройте консоль Active Directory Sites & Services (
dssite.msc
), создайте новый сайт и привяжите к нему IP подсети клеиентов, которые будет обслуживать ваш DC.
Установка роли Active Directory Domain Services (ADDS)
После предварительной подготовки Windows Server, вы можете установить на нем роль ADDS. Откройте Server Manager, выберет Manage -> Add Roles and Features -> Server Roles -> отметьте Active Directory Domain Services.
Можно установить роль ADDS с помощью PowerShell:
Install-WindowsFeature AD-Domain-Services –IncludeManagementTools -Verbose
Проверьте, что что роль AD-Domain-Services установлена:
Get-WindowsFeature -Name *AD-Domain
Повышение сервера до контроллера домена Active Directory
После установки роли ADDS, вы можете повысить ваш Windows Server от рядового члена до контроллера домена.
В консоли Server Manager щелкните по ссылке Promote this server to a domain controller.
Укажите, что вы хотите добавить дополнительный контроллер домена в существующий домен: Add a domain controller to an existing domain.
Выберите что на этом сервере нужно установить DNS сервер и активировать роль Global Catalog.
Затем задайте пароль восстановления Directory Services Restore Mode (DRSM).
Если вы планируете развернуть контроллер домена для чтения, отметьте опцию RODC (read-only domain controller). В данном случае мы не используем этот режим, и разворачиваем обычный RW DC.
Выберите сайт AD, в который нужно поместить новый DC (в нашем примере мы выбрали сайт SPB, который создали ранее).
Пропустите шаг с делегацией DNS сервера.
Далее вы можете выбрать ближайший контроллер домена, с которого нужно выполнить репликацию на ваш новый DC. Если все DC находятся близко и не подключены через WAN каналы, выберите Any domain controller. Первоначальная репликация каталога и SYSVOL на новый DC может вызвать повышенную нагрузку на WAN каналы.
Затем укажите пути к каталогам базы данных ADDS (ntds.dit) и sysvol. В большинстве случаев можно оставить пути по умолчанию:
-
C:\Windows\NTDS -
C:\Windows\SYSVOL
Запустится проверка. Если все предварительные требования выполнены, появится надпись:
All prerequisite checks passed successfully.
Нажмите Install чтобы повысить сервер до DC.
Import-Module ADDSDeployment
Install-ADDSDomainController -NoGlobalCatalog:$false -CreateDnsDelegation:$false -CriticalReplicationOnly:$false -DatabasePath "C:\Windows\NTDS" -DomainName "winitpro.loc" -InstallDns:$true -LogPath "C:\Windows\NTDS" -NoRebootOnCompletion:$false -SiteName "SPB" -SysvolPath "C:\Windows\SYSVOL" -Force:$true
После завершения установки, сервер будет автоматически перезагружен.
Проверка состояние нового контроллера домена
После установки нового DC нужно проверить его состояние и корректность репликации в Active Directory.
В первую очередь проверьте, что новый контроллер домена появится в разделе Domain Controllers консоли ADUC.
Также можно получить информацию о вашем новом DC с помощью командлета из модуля AD PowerShell:
Get-ADDomainController -Identity "SPB-DC02"
Проверьте состояние репликации между контроллерами домена домене с помощью команд:
repadmin /showrepl *
repadmin /replsummary
Можно получить информацию о партнерах по репликации для конкретного DC:
repadmin /replsummary spb-dc02
В моем случае в значении largest delta было указано unknown. Обычно это связано с тем, что репликация еще не завершена. Вы можете подтолкнуть репликацию с помощью консоли Active Directory Sites and Services. Разверните ваш сайт, выберите ваш DC, разверните NTDS Settings, щелкните по связи и выберите Replicate All.
Либо вы можете инициировать полную репликацию командой:
repadmin /syncall
Проверьте что ошибок репликации нет.
Теперь ваш новый DC может обслуживать клиентов и использоваться в качестве logonserver для компьютеров из привязанных IP подсетей/сайта.
В завершении оставлю еще несколько ссылок на статье, которые должны быть полезны для администраторов AD:
- Перенос FSMO ролей
- Корректное удаление контроллера домена
- Управление групповыми политиками (GPO) в Active Directory
- Как переименовать домен AD?
- Сброс пароля администратора домена
Большое спасибо за статью.
Вопрос: на этапе повышения обычного сервера до DC, где supply the credentials to perform this operation.
Мы указываем учетную запись локального администратора повышаемого сервера или учетную запись администратора домена?
Там указываются учетные данные администратора домена, если вы подключились к сервере под непривелигированным аккаунтом.
Здравствуйте! Такой вопрос, есть КД на windows server 2012, даже не r2, поднял на виртуалке win server 2019, сделал его вторым КД как в этой статье описано, выключил старый КД и компы теперь к домену не подключаются. Появляется такое сообщение: DNS успешно запросила запись ресурса размещения службы (SRV), используемой для нахождения контроллера домена Active Directory для домена «***.local»:
Опрос проводился для SRV-записи для _ldap._tcp.dc._msdcs.***.local
Этим запросом были идентифицированы следующие контроллеры домена Active Directory:
a**.***.local
p***.***.local
К возможным причинам этой ошибки относятся:
— Записи узлов (A) или (AAAA) , которые сопоставляют имя контроллера домена Active Directory его IP-адресам, утеряны или содержат неправильные адреса.
— Контроллеры доменов Active Directory, зарегистрированные в DNS, не подключены к сети или не запущены.
Доброго дня,
какие есть подводные камни при смене ip-адреса у дополнительного контроллера домена? Или можно ни о чем не беспокоиться?
Нет, это вполне штатная процедура. Главное правильно все спланировать и найти все места, где используется старый IP. В помощь статья про удаление DC, там многие моменты описаны по поиску мест, где исопльзуется старый IP:
https://winitpro.ru/index.php/2022/01/13/udalenie-kontrollera-domena-active-directory/
Добрый день, у меня вопрос — есть штук 5-6 удаленных площадок, там рядом поднято по контроллеру домена. При этом в самой структуре AD не сделано разделение на сайты. Я хотел было это всё тоже привести в порядок, сделать подсети, привязать туда контроллеры домена, но неожиданно наткнулся на информацию, что репликации в межсайтовом пространстве проходит раз в 15 минут, что очень долго, как мне кажется. По вашему опыту — что лучше — оставить как есть (оно сейчас нормально работает), или же добить тему с сайтами?
На сайты разбивать нужно, в вашем случае клиенты могут аутентфицироваться на любом DC. Например, клиент из центрального офиса идти в филиала и наоборот. Лишний трафик и задержки на канале.
15 минут — это дефолтное значение, подходит для большинства случаев. Можете подсказать, к каким проблемам в вашем бизнесе может привести запоздание обновление инефоррмации в AD на 15 минут. Здесь же речь не о продуктивной базе данных. Поэтому это обычно не вызывает проблем. Можно увеличить частоту но нужно четко понимать зачем
Вопрос по настройкам DNS для старого и нового КД. Автор рекомендует ставить [primary] ip 127.0.0.1 [secondary] ip текущего КД. Я так понимаю настройки будут идентичны с разницей в айпишниках КД. В сети рассматриваются варианты с перекрестными DNS. Какой вариант всё же лучший исходя из best practice? Контроллеры будут на системах WS 2012R2 и новее.
Microsoft вроде рекомендует в качестве primary DNS в настройках адаптера указывать IP другого DC в этом же сайте, а в качестве alternate DNS — 127.0.0.1
Если в этом же сайте нет других DC, тогда primary — loopback и alternate — IP DC в другом сайте.
https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ff807362(v=ws.10)?redirectedfrom=MSDN
Добрый день.
Имеется сеть на 1000+ машин с двумя КД на 2019, все машины имеют статику и прописанные DNS эти два КД. К этим двум КД в резерв добавляю еще один КД на 2019 с DNS — как лучше средствами AD прописать всем пользователям домена новый DNS? Пробовал политикой домена запускать скрипт в автозагрузку, но похоже, что он не отрабатывает без прав администратора. Пробовал в политике в административных шаблонах в Сеть-DNS-клиент указывать новый сервер, но там во-первых комментарий, что только для Windows ХР, а во-вторых похоже, что не применяется у пользователей домена (хотя политика активна).
Как лучше решить эту проблему из Вашей практики?
Предполагаю что типо такого:
$adapter = ((Get-NetIPAddress | ? { ($_.InterfaceAlias -like 'Беспроводная сеть' -or $_.InterfaceAlias -like '*ethernet*') -and $_.PrefixOrigin -eq 'Dhcp' } | ? {$_.IPAddress -like '172.*'}) | Get-NetIPConfiguration) # указать подсеть
$newdns = ($adapter.DNSServer[1].ServerAddresses -join ",") + ",1.1.1.1" # указать ip
Set-DnsClientServerAddress -InterfaceIndex $adapter.InterfaceIndex -ServerAddresses $mydns
$_.PrefixOrigin -eq ‘Static’
наверное
Идея норм, спасибо за скрипт. Я его подсократил до одной команды:
Set-DnsClientServerAddress -InterfaceAlias Ethernet* -ServerAddresses 172.16.0.1,172.16.0.3,172.16.0.2
Проблема там же — скрипт надо запускать под административными правами.
А хотелось бы прописать тупо ДНС в групповой политике и по мере необходимости добавлять/удалять оттуда записи.
Добрый день! Если это доп контроллер домена и находится на филиале, на филиале отличная подсеть, связь через туннель. Нужно ли создавать для этого ДЦ отдельный сайт или нет? Или все подобные ДЦ должны быть в одном сайте, плюс добавить к этому сайте все подсети таких филиалов.
В теории можно все и в одном сайте оставить.
Но для оптимизации сетевого трафика и обработки сценариев отказа канала, лучше создать для площадки отдельный сайт, раз уж вы запланировали для него отдельный DC. В классичиской инфраструктуре сайты должны отображать ваши физические площадки.
В этом случае при обрыве связи или отключении энергии в центральном офисе или филиале, клиенты не будут пытаться искать DC в своем сайте , но на другой площадке.
Приветствую. Подскажите пожалуйста, вроде все сделал по Вашей инструкции. Есть 2 домен контролера (основной со всеми FSMO ролями) и дополнительный, все синхронизируется. Но есть проблема. Когда тушиш основно DC (остается только резервный) то при попытки подключится по RDP к какому либо компьютеру в домене выдает ошибку с требованием NLA аутентификации. Как только запускаю основной DC все ок, дает подключится. В чем может быть проблема? Спасибо большое.
1) DC в одной подсети и в одном сайте AD?
2) Если перезагрузить компьютер при отключенном 1DC, проблема с NLA входом остается? ПРоверьте, локальным входом текущий logoserver:
set | find /i "LOGONSERVER"nltest /sc_verify:vashdomain.com
Test-ComputerSecureChannel -verboseНа всех машинах в домене прописаны DNS основной (IP основного DC), альтернативный (IP резерного DC)
Добрый день, коллеги. Подскажите, возможно кто видел инфу в части требований к сети, если есть задача разнести AD ( по 2 КД) в каждом датацентре.
ДЦ расположены например Европа/Азия.
Спасибо.
Не понял вопроса про требования к сети. Речь о пропускной способности?Лет 15 назад все работато и на слабых каналах.
Фактически не важно как физически расположены DC, главное правильно настроить сайты согласно топологии сети и разнести между ними DC и клиентов.
Да, добрый день, в основном опасение в части пропускной способности каналов связи.
Вот тут пишут, что для подсетей в одном сайте до 10мс допустимая задержка
_https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/creating-a-site-design
А вообще, AD репликация проектировалась в эпоху медленных каналов. Если у вас есть хотя бы 10 Мб под AD трафик, этого будет достаточно для небольших и средних развертываний.