Обеспечение корректной репликации в лесу Active Directory – это одна из главных задач администратора AD. В этой статье попытаемся понять базовые принципы репликации базы Active Directory и методики диагностики неисправности. Стоит отметить, что репликации — один из основополагающих принципов построения современной корпоративной сети на базе AD, так, например, мы уже говорили о репликации групповых политик в домене AD и репликации зон DNS.
Для мониторинга репликации Active Directory в корпоративной среде Microsoft рекомендует использовать продукт SCOM (либо другие продукты мониторинга с похожим функционалом). Кроме того, для мониторинга репликации AD можно использовать утилиту repadmin (repadmin /showrepl * /csv) совместно с самописными скриптами анализа вывода этой утилиты. Типичные проблемы, связанные с ошибками репликации Active Directory, — ситуации, когда объекты не появляются в одном или нескольких сайтах (например, только что созданный пользователь, группа или другой объект AD не доступны на контроллерах домена в других сайтах).
Хорошая отправная точка для поиска неисправности в механизме репликации Active Directory – анализ журнала «Directory Services» на контроллерах домена. Конкретные действия будут зависеть от того, какие ошибки будут обнаружены в журнале, однако для разрешения проблем нужно достаточно четко понимать процессы репликации Active Directory. 
Одним из базовых элементов управлением трафиком репликации между контроллерами домена являются сайты Active Directory. Сайты связаны между собой особыми связями, называемыми «site link», которые определяют стоимость маршрутизации данных AD (элементы леса, домена, папка SYSVOL и т.д.) между различными сайтами. Расчет алгоритма управления и маршрутизации трафика репликации в лесу ведется службой KCC.
KCC определяет партнеров по репликации для всех контроллеров домена в лесу. Для межсайтовой репликации KCC автоматически выбирает специальные сервера-плацдармы (bridgehead server), помимо этого, администратор домена может вручную указать контролеры домена, которые будут выполнять роль сервера-плацдарма для того или иного сайта, именно эти сервера и управляют межсайтовой репликацией. Сайты и сервера bridgehead нужны для того, чтобы удобно управлять трафиком репликации Active Directory, и чтобы уменьшить объем передаваемого трафика по сети.
Межсайтовую топологию в лесу можно проанализировать при помощи команды:
repadmin /showism
данная команда отобразит список сайтов в лесу Active Directory. Для каждого из сайтов указаны 3 значения: стоимость репликации между двумя сайтами, интервал репликации в минутах, а также дополнительные настроенные параметры межсайтовой связи. Вывод этой команды может выглядеть так:
C:\>repadmin /showism ==== TRANSPORT CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configu ration,DC=winitpro,DC=ru CONNECTIVITY INFORMATION FOR 3 SITES: ==== 0, 1, 2
Site(0) CN=LAB-Site1,CN=Sites,CN=Configuration,DC=winitpro,DC=ru 0:0:0, 10:15:0, 10:30:0 All DSAs in site CN=ADP-ADSN,CN=Sites,CN=Configuration,DC=lab, DC=net (with trans& hosting NC) are bridgehead candidates. Site(1) CN=LAB-Site2,CN=Sites,CN=Configuration,DC=winitpro,DC=ru 10:15:0, 0:0:0, 20:30:0 All DSAs in site CN=ADP-Intranet,CN=Sites,CN=Configuration,DC=la b,DC=net (with trans & hosting NC) are bridgehead candidates Site(2) CN=LAB-Site3,CN=Sites,CN=Configuration,DC=winitpro,DC=ru 10:30:0, 20:30:0, 0:0:0 1 server(s) are defined as bridgeheads for transport CN=IP,CN=Int er-Site Transports,CN=Sites,CN=Configuration,DC=winitpro,DC=ru & site CN=LAB-Site3,CN=Sites,CN=Configuration,DC=winitpro,DC=ru: Server(0) CN=testlabdc2,CN=Servers,CN=LAB-Site3,CN=Sites,CN=Co nfiguration,DC=winitpro,DC=ru C:\>В вышеприведённом логе видно, что в домене winitpro.ru существует 3 сайта, которые называется соответственно Site(0), Site(1) иSite(2). Каждый из сайтов имеет 3 набора репликационной информации, по одной для каждого сайта в лесу. Например, настроена связь между Sites(2) (LAB-Site3) и Site(0) (LAB-Site1), параметры этой связи — 10:30:0, что означает: 10 – стоимость репликации, и интервал репликации 30 минут. Также обратите внимание, что для сайта Site(2) задан сервер-плацдарм (bridgehead) – это контроллер домена с именем testlabdc2.
Контроллеры домена, партнеры по репликации – могут быть идентифицированы при помощи графического Gui или при помощи утилит командной строки. Откройте консоль MMC «Active Directory Sites and Services», разверните узел Sites, в нем найдите интересующий ваш сайт. В этом узле будут содержатся контроллеры домена, относящиеся к этому сайту. Развернув контроллер домена и выбрав пункт NTDS Settings, вы увидите всех партнеров по репликации данного контроллера домена.
В командной строке при помощи команды nslookup можно получить список контроллеров домена, относящихся к нашему сайту (естественно для этого необходимо, чтобы все DC имели корректные записи SRV). Формат команды такой:
nslookup -type=srv _ldap._tcp.._sites.dc._
на выходе получаем примерно следующее:
C:\>
_ldap._tcp.LAB-Site1._sites.dc._msdcs.winitpro.ru SRV service location
priority = 0
weight = 100
port = 389
svr hostname = testlabdc1.winitpro.ru
_ldap._tcp.LAB-Site1._sites.dc._msdcs.winitpro.ru SRV service location
priority = 0
weight = 100
port = 389
svr hostname = testlabdc2.winitpro.ru
testlabdc1.winitpro.ru internet address = 172.21.23.13
testlabdc2.winitpro.ru internet address = 172.21.23.16
Чтобы для определенного контролера домена отобразить всех партнеров по репликации, с датой и временем последней репликации, воспользуйтесь командой:
repadmin /showrepl
Стоит отметить, что служба DNS – это важный компонент службы репликации Active Directory. Контроллеры домена регистрируют свои SRV записи в DNS. Каждый контроллер домена в лесу регистрирует записи CNAME вида dsaGuid._msdcs.forestName, где dsaGuid –GUID видимый у объекта в пункте NTDS Settings в консоли «AD Sites and Services». Если в журнале Directory Services есть ошибки, связанные со службой DNS, для проверки корректных записей типа CNAME и A для контроллера домена.
dcdiag /test:connectivity
Если будут ошибки, перезапустите службу Netlogon, в результате чего произойдет перерегистрация отсутствующих dns записей. Если dcdiag все также будет выдавать ошибки, проверьте конфигурацию службы DNS и корректность DNS настроек на DC. Для более детального знакомства с темой тестирования служб dns, рекомендую обратиться к статье Диагностика проблем с поиском контроллера домена.
Команда repadmin имеет специальный параметр /replsummary, который позволяет быстро проверить состояние репликации на конкретном контроллере домена (указывается его имя) или на всех контроллерах (опция wildcard).
repadmin /replsummary [targetDC|wildcard]
В том случае, если ошибки репликации отсутствуют, в выводе этой команды будет видно, что ошибок – 0.:
C:\>repadmin /replsummary testlabdc2
Replication Summary Start Time: 2010-01-24 15:56:03
Beginning data collection for replication summary, this may take a
while:
....
Source DSA largest delta fails/total %% error
testlabdc1 06m:27s 0 / 3 0
testlabdc3 06m:27s 0 / 6 0
testlabdc4 06m:27s 0 / 5 0
Destination DSA largest delta fails/total %% error
testlabdc3 06m:27s 0 / 14 0
C:\>
В том случае, если ошибки все-таки будут, при помощи утилиты Repadmin можно получить более полную информацию. Каждый контроллер домена имеет собственный уникальный USN (Update Sequence Number), который инкрементируется каждый раз при успешном изменении обновлении объекта Active Directory. При инициализации репликации, партнеру передается USN, который сравнивается с USN, полученным в результате последней успешной репликации с данным партнером, тем самым определяя сколько изменений произошло в базе AD со времени последней репликации.
При помощи ключа /showutdvec, можно получить список текущих значений USN, хранящихся на указанном DC.
repadmin /showutdvec
например
C:\>repadmin /showutdvec testlabdc4 DC=winitpro,DC=ru
Caching GUIDs.
....
LAB-Site1\testlabdc1 @ USN 16608532 @ Time 2010-01-24 16:27:11
LAB-Site1\testlabdc2 @ USN 307126 @ Time 2010-01-24 16:27:27
LAB-Site2\testlabdc3 @ USN 297948217 @ Time 2010-01-24 16:19:34
LAB-Site3\testlabdc4 @ USN 245646728 @ Time 2010-01-24 16:19:36
C:\>
Запустив эту команду на контроллере домена, на котором наблюдаются проблемы с репликацией, можно понять насколько различаются базы AD, просто сравнив значения USN.
Тестирование репликации Active Directory при помощи утилиты repadmin можно осуществить несколькими способами:
- replmon /replicate <targetDC> <sourceDC> <dirPartition> (позволяет запустить репликацию определенного раздела на указанный контроллер домена)
- replmon /replsingleobj <targetDC> <sourceDC> <objPath> (репликация конкретного объекта между двумя DC)
- replmon /syncall <targetDC> (синхронизация указанного контроллера домена со всем партнерами по репликации)
C:\>repadmin /replicate testlabdc1 testlabdc3 DC=winitpro,DC=ru
Sync from testlabdc3 to testlabdc1 completed successfully.
C:\>repadmin /replsingleobj testlabdc1 testlabdc3 cn=stuart,ou=dsu
sers,DC=winitpro,DC=ru
Successfully replicated object cn=stuart,ou=dsusers,DC=winitpro,DC=ru
to testlabdc1 from .
C:\>repadmin /replsingleobj testlabdc1 testlabdc3 ou=dsusers,dc=la
b,dc=net
Successfully replicated object ou=dsusers,DC=winitpro,DC=ru to testlab
dc1 from .
C:\>repadmin /replsingleobj testlabdc1 testlabdc3 DC=winitpro,DC=ru
Successfully replicated object DC=winitpro,DC=ru to testlabdc1 from
.
C:\>repadmin /syncall testlabdc3
CALLBACK MESSAGE: The following replication is in progress:
From: 25fdc051-6ff6-4922-bc02-0b77a4652bfc._msdcs.winitpro.ru
To : 99305007-2290-489b-9551-20827ba0664d._msdcs.winitpro.ru
CALLBACK MESSAGE: The following replication completed successfully
From: 25fdc051-6ff6-4922-bc02-0b77a4652bfc._msdcs.winitpro.ru
To : 99305007-2290-489b-9551-20827ba0664d._msdcs.winitpro.ru
CALLBACK MESSAGE: The following replication is in progress:
From: b0870af5-ab82-4372-9e39-0a9772a5e47c._msdcs.winitpro.ru
To : 99305007-2290-489b-9551-20827ba0664d._msdcs.winitpro.ru
CALLBACK MESSAGE: The following replication completed successfully
From: b0870af5-ab82-4372-9e39-0a9772a5e47c._msdcs.winitpro.ru
To : 99305007-2290-489b-9551-20827ba0664d._msdcs.winitpro.ru
CALLBACK MESSAGE: SyncAll Finished.
SyncAll terminated with no errors.
C:\>
При наличии проблем с механизмом репликации Active Directory, нужно знать и уметь пользоваться утилитами repadmin, nslookup, dcdiag, крайне полезен при анализе журнал событий Directory Services. В особо сложный и нестандартных ситуациях может помочь база знаний Microsoft KB, в которой описаны типовые проблемы и методики их решения. Поиск по базе KB обычно осуществляется по идентификаторам ошибок (Event ID), полученным из указанного журнала..
Прошу вас, помогите решить такую проблему. Моя контора купила лицензию Windows Server 2012 Standard, я имел неосторожность скачать дистрибутив сервера, который, если при установке не вводить ключ, будет активирован на 180 пробных дней. Поднял серв до контроллера домена, (DNS, AD и т.д.) настроил политики, профили, права, а когда стал активировать лиц. ключом, столкнулся с проблемой, что ключ не применится, якобы потому что система находится на каком-то ином канале распространения, отличном от канала продаж.
Нужно сменить канал распространения, запустив некий *.vbs скрипт, но прокатит это только в том случае, если сервер будет рядовым, а не контролером домена.
Вот у меня мысль, настроить реплику, чтобы работало два контролера домена, после чего в тихую ночную смену понизить первый сервер до рядового, активировать и среплицировать все обратно с реплики.
Прокатит ли это? или мне можно готовиться к повторной настройке леса с заведением пользователей?
Вы все правильно запланировали, переподнимать домен не потребуется:
1) Заводите второй DC, переносите на него все FSMO роли (https://winitpro.ru/index.php/2012/03/06/peredacha-rolej-fsmo/). Только удостоверьтесь что в журналах Directory Service /replication отсуствуют ошибки
2) Понижаете первый сервер до рядового, меняете канал распространнеия, активируете
3) Повышаете первый до контроллера домена, переносите все роли обратно (если нужно)
4) Крайне рекомендуется оставить второй DC
Забыл поблагодарить вас за данный совет, сделал все именно так и все прошло отлично! Спасибо!
У меня сейчас стоит вопрос о репликации между филиалами организации. Там в общем все понятно, с помощью сайтов разнести DC по филиалам и настроить реплику, это снизит трафик и все такое… Непонятно следующее: представим ситуацию, когда реплика настроена, сайты созданы, настроены серверы-плацдармы, пользователь работал в здании А, в его св-вах его профиля забит адрес домика в формате «\\contoso.local\dfs\profiles». На следующий день он логинится в здании Б (забегая вперед, шара profiles реплицируется через dfs в здание Б), благодаря сайтам его ПК определит ближайший DC и авторизует его, а что будет с профилем? Пользуется ли DFS сайтами? Отдаст ли она домик пользователю с ближайшей ноды DFS, чтобы не тянуть его через инет из здания А?
Простите меня, много букв пишу, но вот эта и след. ситуация… Раньше мне не доводилось с этим работать. Опыт, как и половое бессилие, приходит с годами))
Вторая ситуация связана с тем, что я ни разу не делал новый домен в существующем лесу. Точнее меня интересует репликация. Известно, что между DC разных доменов одного леса установлены доверительные отношения и пользователь из одного домена сможет авторизоваться на ПК в другом домене. Но реплицируются ли GPO и как будет применен профиль пользователя?
1) Вообще MS не рекомендует использовать DFS для хранения профилей (http://support.microsoft.com/kb/2533009), но решение в большинстве случаев работает без проблем. При
При обращению к пространству имен DFS, пользователя перенаправит на ближайший сервер DFS (определяется по принадлежности к сайту AD). Так что настраивайте сайт, репликацию DFS и вперед.
2) Насчет репликации GPO в дочерний домен — не уверен, ( ну не сторонник я плодить лишние субдомены), но насколько я понимаю политики уровня домена и OU не должны наследуются между доменами. Есть вариант привязки политик к сайтам (пример привязки политики к сайту есть здесь https://winitpro.ru/index.php/2013/12/17/privyazka-serverov-wsus-k-razlichnym-sajtam-active-directory/)
Спасибо! Именно это и хотел услышать!
Добрый день!
Прошу, можете ли помочь в такой ситуации?
Было два контроллера домена DC1 и DC2 от предыдущего админа, как что работает не знал, по причине слишком малого срока работы на новом месте. (Прежде ещё с репликацией не доводилось сталкиваться)
Но, как назло полетел DC1. Восстанавливал копию диска, которая была. Но в итоге слетела репликация и, как я выяснил позже, причиной тому USN Rollback. В общем не получается ничего сделать, читал, что надо понижать роль одного из доменов и вычищать его данные. Потом заново поднимать.
Ситуация ещё осложняется тем, что на DC1 висят файловые шары сотрудников, а самое главное — перемещаемые профили, которые не дай Бог повредить или потерять, или чтобы они были недоступны некоторое время, потому что сотрудники бывают работают круглосуточно.
На DC2 есть только FTP.
Вопрос. Какой домен выводить? DC1 или DC2. Актуальность AD не имеет значения, так как не изменялась долго. DC2 висит на виртуалке и ввиду этого его проще если что восстановить.
Но опять же будет прок от такого восстановления, если я буду его вычищать из записей.
Можете мне посоветовать что делать. Читал статью:
support.microsoft.com/kb/216498/ru
Но не рискую что-то её на рабочих серверах применять.
Заранее спасибо!
Буду признателен за любую помощь.
Насколько я понял второй DC2 работает нормально? помимо репликации других проблем нет?
Если да — ваша задача — проверить и случае необходимости передать роли FSMO на DC2, понизить DC1 до рядового сервера, удалить из AD всю информацию о нем и опять его повысить до контроллера домена . Через какое-то время проверьте прохождение репликации:
Repadmin /showrepl
Это надежный но «силовой» сценарий.
Есть еще вариант мягкого восстановления репликации в домене — но если особого опыта нет, самостоятельно за него браться не советую — есть вариант только навредить.
На DC1 стоят роли DHCP, DNS, Файловые службы с DFS.
Да, DC2 работал нормально, но сейчас начинают появляться косяки, такие как проблема с GPO или для рабочей станции перестают быть видны домены. Я так предполагаю, что это последствия того, что они работают сейчас независимо фактически и могут друг другу мешать. Не ошибаюсь ли я?
Поэтому быстрее хочу это всё устранить.
Спасибо.
Спасибо!
Да, DC2 работает нормально. Есть коллизии, которые возникают я так думаю их одновременного независимого функционирования, иногда клиенты не могут попасть на шары поскольку не опознаётся доменные учётки, потом всё снова работает. В общем мелкие косяки вылазят всё же.
А если скажем восстановить образ DC1 когда всё работало, и отключить Dc2 на время, по идее, должно работать, кроме разве что репликации, ведь никто ему мешать не будет.
Все эти проблемы — классический вариант проблемы с разными USN и непрямохождением репликации между DC — в результате разные клиенты вносят изменения на разные DC, которые информацию друг другу не передают. Например, пользователь или компьютер может сменить пароль на одном DC, а после перезагрузки при попытке авторизоваться на другом DC (который про новый пароль ничего не знает) получит сообщение «неверный пароль».
Теоретически да — если вы восстановите DC1 из бэкапа и совсем отключите DC2 (с его полным ручным выковыриванием из AD) и будете готовы в случае необходимости сбросить пароли всех пользователей домена и перезагнать в домен все остальные пк и сервера — то домен на DC1 заведется, потом нужно будет добавить в домен еще один DC, например 3 (DC2 с поднятой ролью AD не в коем случае не включать).
Но я бы лично предпочел выполнить вариант с понижением DC1 который описал выше.
Добрый день!
Имеются несколько контроллеров домена с репликацией. Есть сервера DC1, DC2 и DC3.
Возникла необходимость сменить имя DC3 на DC2, а DC2 вывести из эксплуатации.
Владелец ролей FSMO DC1.
Нашёл в Интернет, что можно сделать это при помощи команды NETDOM computername
Но в последующем шаге сказано, что так же необходимо выполнить команду:
NETDOM computername Server.domain /makeprimary:Superserver.domain
Хотел бы поинтересоваться не возникнет ли проблем если FSMO обладает DC1, а остальные два просто реплики и применить эту команду к вновь названному DC2? Или это вообще к этому не относится.
Буду признателен за ответ.
Я бы не стал переименовывать контроллер домена в такой же DC2, даже если вычистить все методанные старого DC2 из домен среды. Обязательно где-ниб всплывёт потом.
— с передачей ролей проблем быть не должно.
Gluposti, nichego ne vsplivet, esli vse chetko sdelat’. 🙂
Замените replmon на repadmin.
В «Тестирование репликации ….»
Подскажите, пожалуйста, как быть? Ситуация такая есть несколько DC (например 4),к ним добавляется ещё 1 (DC 5), но у него нет доступа к одному из 4 DC (например к 1). Как настроить репликацию между новым DС (5) и DC (1)? Это как-то через сайты? Заранее благодарю!
Для начала нужно чуть больше информации о вашей инфраструктуре. Все имеющиеся DC сейчас в одном сайте или в разных? Если в разных, нужно знать топологию, что где расположено и как связано между собой?
Добрый день, где правильнее размещать службы DFS имен, на файловых серверах, которые файлы раздают, или на DC? Встала насущная задача заменить файловые серверы win serv 2008 на свежие версии, так как есть небезосновательные предположения, что существующие проблемы DFS репликации связаны в том числе и сверсией ОС файловых серверов. Сейчас DFS имена расположены на файловых серверах. Заранее благодарю за пояснения и подсказки.
Я не видел таких рекомендаций. Можно как на FS, так и на DC.
Server Hosting Stand-Alone Namespaces: Can be a member server or domain controller.
Server Hosting Domain-Based Namespaces: Must be a member server or domain controller in the domain in which the namespace is configured. (This requirement applies to every namespace server that hosts a given domain-based namespace.)
_https://learn.microsoft.com/en-us/windows-server/storage/dfs-namespaces/dfs-overview