Устранение неполадок репликации доменных служб Active Directory
- Причина. Регулярно отслеживайте репликацию, чтобы определить и устранить неполадки, прежде чем они станут слишком серьезными.
Repadmin — это средство командной строки, предназначенное для оповещения о сбоях при репликации между двумя партнерами. В следующем примере использования repadmin отображаются два партнера репликации и сбои репликации для компьютера Server1 в домене adatum.com.
repadmin /showrepl server1.adatum.com
Чтобы отобразить полный список параметров repadmin, используйте параметр ?:
Dcdiag — это средство командной строки, с помощью которого можно поверить DNS-регистрацию контроллера домена; проверить, что идентификаторы безопасности в заголовках контекста именования имеют соответствующие разрешения для репликации; выполнить анализ состояния контроллеров домена в лесу или предприятии; а также выполнить другие действия. В следующем примере использования dcdiag выполняется проверка на любые ошибки репликации между контроллерами домена.
Чтобы отобразить полный список параметров dcdiag, используйте параметр ?:
В журнале службы каталогов (в средстве просмотра событий, в разделе Журналы приложений) отображаются ошибки репликации, которые произошли после того, как был установлена связь репликации.
Репликация между сайтами происходит слишком медленно.
- Причина. Время, требуемое для репликации данных каталога между контроллерами домена, называется задержкой репликации. Задержка репликации может сильно различаться в зависимости от количества контроллеров домена, количества сайтов, доступной пропускной способности между сайтами, частоты репликации и других факторов.
-
Регулярное отслеживание репликации — это хороший способ для определения стандартной задержки репликации в определенной сети. Обладая такими сведениями, можно с легкостью определить, имеются ли какие-либо неполадки.
Управление репликацией Active Directory
Обеспечение корректной репликации в лесу 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 значения: стоимость репликации между двумя сайтами, интервал репликации в минутах, а также дополнительные настроенные параметры межсайтовой связи. Вывод этой команды может выглядеть так:
==== TRANSPORT CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configu
ration,DC=winitpro,DC=ru CONNECTIVITY INFORMATION FOR 3 SITES: ====
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.
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
10:30:0, 20:30:0, 0:0:0
1 server(s) are defined as bridgeheads for transport CN=IP,CN=Int
C:\>
В вышеприведённом логе видно, что в домене test.com существует 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._
на выходе получаем примерно следующее:
_ldap._tcp.LAB-Site1._sites.dc._msdcs.test.com SRV service location
svr hostname = testlabdc1.test.com
_ldap._tcp.LAB-Site1._sites.dc._msdcs.test.com SRV service location
svr hostname = testlabdc2.test.com
testlabdc1.test.com internet address = 172.21.23.13
testlabdc2.test.com 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
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=test,DC=ru
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=test,DC=ru
Sync from testlabdc3 to testlabdc1 completed successfully.
C:\>repadmin /replsingleobj testlabdc1 testlabdc3 cn=stuart,ou=dsu
Successfully replicated object cn=stuart,ou=dsusers,DC=test,DC=ru
to testlabdc1 from .
C:\>repadmin /replsingleobj testlabdc1 testlabdc3 ou=dsusers,dc=la
Successfully replicated object ou=dsusers,DC=test,DC=ru to testlab
C:\>repadmin /replsingleobj testlabdc1 testlabdc3 DC=winitpro,DC=ru
Successfully replicated object DC=test,DC=ru to testlabdc1 from
C:\>repadmin /syncall testlabdc3
CALLBACK MESSAGE: The following replication is in progress:
CALLBACK MESSAGE: The following replication completed successfully
CALLBACK MESSAGE: The following replication is in progress:
CALLBACK MESSAGE: The following replication completed successfully
CALLBACK MESSAGE: SyncAll Finished.
SyncAll terminated with no errors.
C:\>
При наличии проблем с механизмом репликации Active Directory, нужно знать и уметь пользоваться утилитами repadmin, nslookup, dcdiag, крайне полезен при анализе журнал событий Directory Services. В особо сложный и нестандартных ситуациях может помочь база знаний Microsoft KB, в которой описаны типовые проблемы и методики их решения. Поиск по базе KB обычно осуществляется по идентификаторам ошибок (Event ID), полученным из указанного журнала..
Как проверить репликацию между контроллерами домена
Авторизуясь в LiveJournal с помощью стороннего сервиса вы принимаете условия Пользовательского соглашения LiveJournal
- November 2016
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 |
Имеется два офиса. В каждом офисе по контроллеру домена на основе Windows Server, и разные подсети, соединённые при помощи VPN. Чтобы пользователи определённого офиса при авторизации обращались только к своему контроллеру домена (а это увеличит скорость работы, ведь интернет между офисами отнюдь не быстр), необходимо создать подсети и сайты, сопоставив их один с другим. Делается это через оснастку «Active Directory — Сайты и службы». В целом, понятно интуитивно как это сделать, если заходить в свойства каждого из объектов. Главное лишь проверить, что в итоге имеется два сайта, в каждом сайте находится домен, в папке Subnets находятся подсети (192.168.30.0/24, 192.168.100.0/24), в свойствах у которых указано к какому сайту они относятся. Теперь надо проверить, реплицируются ли между собой контроллеры домена. Когда они находились в одном сайте, можно было вручную запустить механизм репликации, после чего выскакивало сообщение, мол всё ОК. А сейчас, при нажатии на правиле репликации в NDTS-settings и выборе пункта «Реплицировать сейчас», в логи ничего не заносится, сообщение об успешной репликации не выводится, только вылазит сообщение, с предложением почитать раздел справки, чтобы узнать как проверять, выполняется ли репликация. Я почитал. Проще всего, чтобы не использовать дополнительно оплачиваемые инструменты диагности от мелкософт, проверять через программы dcdiag или repadmin. Чтобы не искать в запутанной справке каждый раз, выкладываю сюда команды, которыми можно проверить, происходит ли репликация между контроллерами домена:
repadmin /showreps server.domain, где server.domain — это имя вашего сервера (допустим, serv.firma.local), с которым мы проверяем репликацию.
При успешной репликации, под каждым из пяти параметров, будет написано «was successful».
dcdiag /test:replications — это команда просто показывает, нормально ли происходит репликация. Рекомендую. Ищите глазами строчку . passed test Replications. Это значит, что есть счастье в нашей суровой админской жизни:)
Если эти тесты не показали хорошие результаты, поковыряйтесь в настройках, проверьте соединение между серверами, попляшите с бубном. Тогда всё заработает!
Сетевые сервисы Windows 2012 — репликация Active Directory
Наконец-то собрался переписать свои заметки по теме из черновика в тетрадке в электронный формат. Изложить постарался максимально кратко и ёмко.
- Основные сведения
- Механизмы репликации
- 2.1 Внутрисайтовая репликация
- 2.2 Межсайтовая репликация
- Диагностика репликации
1. Основные сведения
Все данные Active Directory хранятся в специализированной базе данных на движке ESENT. Физически она представляет собой файл NTDS.DIT. Все изменения в AD производятся на конкретном контроллере домена и вносятся в его NTDS.DIT и лишь потом эти изменения передаются на остальные контроллеры домена.
Логически база данных состоит из четырёх разделов:
Schema — содержит описания объектов и их атрибутов, которые могут быть созданы в AD. Меняется редко — при процедуре расширения схемы, которая производится, например, при установке MS Exchange или при апгрейде ОС контроллеров домена. Расширение схемы необратимо, его нельзя откатить никак, кроме способа восстановления всех DC, успевших реплицировать данные, из бэкапа. Репликацию данного раздела может инициировать только контроллер домена, имеющий роль Schema master. Реплицируется на все контроллеры леса.
Configuration — содержит сведения о конфигурации AD (сколько доменов, сайтов, сайтлинков и т.д.). Инициатором репликации может выступать любой DC. Реплицируется на все контроллеры леса.
Domain — содержит учётные записи (пользователей, группы, компьютеры, принтеры…). Инициатором выступает любой DC. Реплицируется на все контроллеры домена.
Application — раздел для хранения данных какими-то приложениями, не относящимися к AD непосредственно. В частности, если вы выбрали в настройках DNS-зоны «интегрированная в AD», то она хранится здесь. Репликация зависит от настройки.
Репликация между контроллерами происходит не абы как и не по принципу «каждый с каждым», а на основе репликационных связей. За их создание отвечает сервис KCC (Knowledge Consistency Checker). Он стартует на каждом контроллере домена раз в 15 минут и добавляет или удаляет необходимые связи. Так что нет ничего страшного, если сразу после установки нового DC в сети, он ещё не числится ничьим партнёром репликации. Посмотреть и настроить связи можно в оснастке Active Directory Sites and Services.
Связи создаются сервисом KCC на основании правила «трёх прыжков» — то есть, чтобы от одного контроллера домена до любого другого было не более трёх переходов или двух посредников.
Следует иметь ввиду, что связи, созданные вручную, сервисом KCC не управляются, то есть восстанавливать им замену, в случае недоступности одного из партнёров по репликации, сервис не будет.
Можно не ждать 15 минут, и инициировать создание связей силами KCC принудительно:
repadmin /kcc <имя сервера> — принудительное создание связи для <имя сервера>
repadmin /kccsite <имя сайта> — принудительное создание связей для всех DC в сайте <имя сайта>
repadmin /kcc * — запустить процесс на всех контроллерах доменов в лесу.
2. Механизмы репликации
На каждом контроллере домена ведётся учёт количества изменений с помощью счётчика highestCommittedUSN. Создание/изменение объекта включает в себя создание/изменение нескольких атрибутов, каждое из которых увеличивает highestCommittedUSN на 1. Каждый атрибут, помимо прочих, имеет параметры:
Org.USN — значение счётчика highestCommittedUSN автора изменений (контроллера домена, на котором они производились) на момент изменения.
Loc.USN — значение счётчика highestCommittedUSN текущего контроллера домена (принимающего изменённые данные в ходе репликации).
Посмотреть атрибуты и значения их параметров объекта можно командой repadmin /showmeta. Например:
repadmin /showmeta «CN=User1,OU=TestOU,DC=contoso,DC=com»
В ходе репликации, контроллер домена кэширует значения highestCommittedUSN своих партнёров. При следующем сеансе он сравнивает закэшированное значение с текущим. Если новое значение больше предыдущего, целевой контроллер принимает решение стянуть изменения. Для этого исходный контроллер делает выборку объектов и атрибутов, у которыех Loc.USN больше, чем последний highestCommittedUSN.
В случае конфликтов:
- сравнивается параметр Ver конфликтного атрибута. Чей выше, тот и прав.
- если Ver равны, сравнивается время изменения. Чьё позже, тот и прав.
- если и время равно, то прав будет контроллер домена с большим GUID.
- В случае, если на двух контроллерах одновременно создали учётную запись с одинаковым именем, более ранняя будет переименована (старое имя+GUID контроллера)
- В случае, если на одном контроллере в какой-то OU создаётся объекта, а на другом в это же время удаляется OU, объект, в ходе репликации, будет перенесён в служебный контейнер «Lost and Found«
Репликация всегда происходит в режиме Pull (вытягивание), поскольку каждый контроллер единолично отвечает за целостность своей базы данных.
Принудительный запуск репликации:
repadmin /replicate <serverTo> <serverFrom> <раздел AD в формате RDN>
repadmin /syncall <server> — синхронизация указанного сервера со всеми партнёрами по репликации.
2.1 Внутрисайтовая репликация
Через 15 секунд после внесения изменений, контроллер домена оповещает своих партнёров о необходимости репликации. Если партнёров несколько, то каждому следующему оповещение отправляется с 3-секундной задержкой.
repadmin /notifyopt — настройка таймингов оповещений.
Изменение пароля пользователя и блокировка учётной записи инициируют репликацию без 15-секундной задержки.
Кроме того, репликация происходит по расписанию каждый час. На случай, если во время инициирования репликации по изменению, целевой контроллер был недоступен или был занят дефрагментацией базы.
2.2 Межсайтовая репликация
Для репликации между сайтами создаются связи сайтов (Site Link), в которых задаётся расписание («окно» в течение которого возможна репликация и периодичность), используемый протокол (SMTP или IP) и стоимость (Cost). По умолчанию создана DEFAULTIPSITELINK с использованием IP и репликацией раз в 180 минут. Посмотреть связи или создать новые можно в оснастке Active Directory Sites and Services.
Стоимости связей учитываются при выборе пути репликации — если от одного сайта до другого можно добраться разными путями, выбран будет тот, стоимость которого будет меньше. Если стоимости равны, выбирается путь с меньшим количеством прыжков. Если и они равны, выбирается просто по имени сайта (сравнение строк).
За репликацию между сайтами отвечают не все подряд контроллеры доменов, а в каждом сайте выбирается специально обученный — Bridgehead (сервер плацдармов). То есть именно он занимается репликацией изменений данного сайта с аналогичным bridgehead’ом другого сайта. Как и в случае с репликационными связями между контроллерами доменов, за выбор сервера-плацдарма отвечает служба KCC. Точно также эта служба не работает с назначенными вручную Bridgehead’ами и если таковой выйдет из строя, репликация скорее всего будет невозможна (если не был также вручную назначен ещё один-несколько).
repadmin /bridgeheads — посмотреть текущие серверы плацдармов.
Стоит также упомянуть тут такое явление, как Site Link Bridging — связь между Site1 и Site3 через сеть Site2, но минуя контроллеры домена, расположенные в Site2. То есть используя только маршрутизируемую сеть. Это при условии, что между Site1 и Site3 прямой связи нет, а контроллеры домена в Site2 по какой-то причине оказались недоступны.
Такой бриджинг настраивается также автоматически пресловутой службой KCC. Можно отключить (галочка в свойствах протокола-транспорта в оснастке Active Directory Sites and Services). К сожалению, автоматизация включается/отключается только полностью для всех сайтов. Однако, можно создать вручную только для нужных, предварительно отключив автоматику.
Если контроллеры домена в промежуточном сайте вновь вернулись в работу, то и автоматические и созданные вручную мосты перестают использоваться и репликация идёт своим естественным путём.
На картинке вначале статьи можно увидеть два таких моста — от DC3 к DC2 и от DC8 к DC1.
3. Диагностика репликации
Подробно расписывать процедуры диагностики я не буду — понимая механизмы работы DNS и репликации, зная нужные инструменты, базовые действия проделать труда не составит.
В качестве отправной точки для диагностики, неплохой идеей будет использовать анализ логов Directory Services на проблемном контроллере домена.
Также поможет dcdiag /test:connectivity, а ещё nslookup, как средство проверки правильной работы DNS.
Ну и конечно repadmin. Часть его ключей описана выше, ещё часть можно увидеть в справке (repadmin /?), а кое-что — в расширенной справке (repadmin /? /experthelp).