Управление репликацией Active Directory | Windows для системных администраторов

Управление репликацией 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

Одним из базовых элементов управлением трафиком репликации между контроллерами домена являются сайты 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, вы увидите всех партнеров по репликации данного контроллера домена.

контроллер домена 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), полученным из указанного журнала..

Еще записи по теме: Active Directory
Понравилась статья? Скажи спасибо и расскажи друзьям!
Назад:
Вперед:

Комментариев: 12

Оставить комментарий
  1. Серегй | 26.10.2013

    Прошу вас, помогите решить такую проблему. Моя контора купила лицензию Windows Server 2012 Standard, я имел неосторожность скачать дистрибутив сервера, который, если при установке не вводить ключ, будет активирован на 180 пробных дней. Поднял серв до контроллера домена, (DNS, AD и т.д.) настроил политики, профили, права, а когда стал активировать лиц. ключом, столкнулся с проблемой, что ключ не применится, якобы потому что система находится на каком-то ином канале распространения, отличном от канала продаж.
    Нужно сменить канал распространения, запустив некий *.vbs скрипт, но прокатит это только в том случае, если сервер будет рядовым, а не контролером домена.
    Вот у меня мысль, настроить реплику, чтобы работало два контролера домена, после чего в тихую ночную смену понизить первый сервер до рядового, активировать и среплицировать все обратно с реплики.
    Прокатит ли это? или мне можно готовиться к повторной настройке леса с заведением пользователей?

    Ответить
    • itpro | 28.10.2013

      Вы все правильно запланировали, переподнимать домен не потребуется:
      1) Заводите второй DC, переносите на него все FSMO роли (http://winitpro.ru/index.php/2012/03/06/peredacha-rolej-fsmo/). Только удостоверьтесь что в журналах Directory Service /replication отсуствуют ошибки
      2) Понижаете первый сервер до рядового, меняете канал распространнеия, активируете
      3) Повышаете первый до контроллера домена, переносите все роли обратно (если нужно)
      4) Крайне рекомендуется оставить второй DC

      Ответить
      • Сергей | 01.03.2015

        Забыл поблагодарить вас за данный совет, сделал все именно так и все прошло отлично! Спасибо!

        У меня сейчас стоит вопрос о репликации между филиалами организации. Там в общем все понятно, с помощью сайтов разнести DC по филиалам и настроить реплику, это снизит трафик и все такое… Непонятно следующее: представим ситуацию, когда реплика настроена, сайты созданы, настроены серверы-плацдармы, пользователь работал в здании А, в его св-вах его профиля забит адрес домика в формате «\\contoso.local\dfs\profiles». На следующий день он логинится в здании Б (забегая вперед, шара profiles реплицируется через dfs в здание Б), благодаря сайтам его ПК определит ближайший DC и авторизует его, а что будет с профилем? Пользуется ли DFS сайтами? Отдаст ли она домик пользователю с ближайшей ноды DFS, чтобы не тянуть его через инет из здания А?

        Простите меня, много букв пишу, но вот эта и след. ситуация… Раньше мне не доводилось с этим работать. Опыт, как и половое бессилие, приходит с годами))

        Вторая ситуация связана с тем, что я ни разу не делал новый домен в существующем лесу. Точнее меня интересует репликация. Известно, что между DC разных доменов одного леса установлены доверительные отношения и пользователь из одного домена сможет авторизоваться на ПК в другом домене. Но реплицируются ли GPO и как будет применен профиль пользователя?

        Ответить
        • itpro | 03.03.2015

          1) Вообще MS не рекомендует использовать DFS для хранения профилей (http://support.microsoft.com/kb/2533009), но решение в большинстве случаев работает без проблем. При
          При обращению к пространству имен DFS, пользователя перенаправит на ближайший сервер DFS (определяется по принадлежности к сайту AD). Так что настраивайте сайт, репликацию DFS и вперед.

          2) Насчет репликации GPO в дочерний домен — не уверен, ( ну не сторонник я плодить лишние субдомены), но насколько я понимаю политики уровня домена и OU не должны наследуются между доменами. Есть вариант привязки политик к сайтам (пример привязки политики к сайту есть здесь http://winitpro.ru/index.php/2013/12/17/privyazka-serverov-wsus-k-razlichnym-sajtam-active-directory/)

          Ответить
          • Сергей | 03.03.2015

            Спасибо! Именно это и хотел услышать!

            Ответить
  2. Тимофей | 12.02.2014

    Добрый день!
    Прошу, можете ли помочь в такой ситуации?
    Было два контроллера домена DC1 и DC2 от предыдущего админа, как что работает не знал, по причине слишком малого срока работы на новом месте. (Прежде ещё с репликацией не доводилось сталкиваться)
    Но, как назло полетел DC1. Восстанавливал копию диска, которая была. Но в итоге слетела репликация и, как я выяснил позже, причиной тому USN Rollback. В общем не получается ничего сделать, читал, что надо понижать роль одного из доменов и вычищать его данные.  Потом заново поднимать.
    Ситуация ещё осложняется тем, что на DC1 висят файловые шары сотрудников, а самое главное — перемещаемые профили, которые не дай Бог повредить или потерять, или чтобы они были недоступны некоторое время, потому что сотрудники бывают работают круглосуточно.
    На DC2 есть только FTP.
    Вопрос. Какой домен выводить? DC1 или DC2. Актуальность AD не имеет значения, так как не изменялась долго. DC2 висит на виртуалке и ввиду этого его проще если что восстановить.
    Но опять же будет прок от такого восстановления, если я буду его вычищать из записей.
     
    Можете мне посоветовать что делать. Читал статью:
    support.microsoft.com/kb/216498/ru
    Но не рискую что-то её на рабочих серверах применять.
     
    Заранее спасибо!
    Буду признателен за любую помощь.

    Ответить
    • itpro | 12.02.2014

      Насколько я понял второй DC2 работает нормально? помимо репликации других проблем нет?
      Если да — ваша задача — проверить и  случае необходимости передать роли FSMO на DC2, понизить DC1 до рядового сервера, удалить из  AD всю информацию о нем и опять его повысить до контроллера домена . Через какое-то время проверьте прохождение репликации:
      Repadmin /showrepl
      Это надежный но «силовой» сценарий.
       
      Есть еще вариант мягкого восстановления репликации в домене — но если особого опыта нет, самостоятельно за него браться не советую — есть вариант только навредить.
       
       

      Ответить
      • Тимофейё | 12.02.2014

        На DC1 стоят роли DHCP, DNS, Файловые службы с DFS.
        Да, DC2 работал нормально, но сейчас начинают появляться косяки, такие как проблема с GPO или для рабочей станции перестают быть видны домены. Я так предполагаю, что это последствия того, что они работают сейчас независимо фактически и могут друг другу мешать. Не ошибаюсь ли я?
        Поэтому быстрее хочу это всё устранить.
         
        Спасибо.
         

        Ответить
  3. Тимофей | 12.02.2014

    Спасибо!
    Да, DC2 работает нормально. Есть коллизии, которые возникают я так думаю их одновременного независимого функционирования, иногда клиенты не могут попасть на шары поскольку не опознаётся доменные учётки, потом всё снова работает. В общем мелкие косяки вылазят всё же.
     
    А если скажем восстановить образ DC1 когда всё работало, и отключить Dc2 на время, по идее, должно работать, кроме разве что репликации, ведь никто ему мешать не будет.

    Ответить
    • itpro | 13.02.2014

      Все эти проблемы — классический вариант проблемы с разными USN и непрямохождением репликации между DC — в результате разные клиенты вносят изменения на разные DC, которые информацию друг другу не передают. Например, пользователь или компьютер может сменить пароль на одном DC, а после перезагрузки при попытке авторизоваться на другом DC (который про новый пароль ничего не знает) получит сообщение  «неверный пароль».
      Теоретически да — если вы восстановите DC1 из бэкапа и совсем отключите DC2 (с его полным ручным выковыриванием из AD) и будете готовы в случае необходимости сбросить пароли всех пользователей домена и перезагнать в домен все остальные пк и сервера — то домен на DC1 заведется, потом нужно будет добавить в домен еще один DC, например 3 (DC2 с поднятой ролью AD не в коем случае не включать).
      Но я бы лично предпочел выполнить вариант с понижением DC1 который описал выше.

      Ответить
  4. Тимофей | 04.08.2015

    Добрый день!

    Имеются несколько контроллеров домена с репликацией. Есть сервера DC1, DC2 и DC3.

    Возникла необходимость сменить имя DC3 на DC2, а DC2 вывести из эксплуатации.
    Владелец ролей FSMO DC1.

    Нашёл в Интернет, что можно сделать это при помощи команды NETDOM computername

    Но в последующем шаге сказано, что так же необходимо выполнить команду:
    NETDOM computername Server.domain /makeprimary:Superserver.domain

    Хотел бы поинтересоваться не возникнет ли проблем если FSMO обладает DC1, а остальные два просто реплики и применить эту команду к вновь названному DC2? Или это вообще к этому не относится.

    Буду признателен за ответ.

    Ответить
    • Oleg | 05.08.2015

      Я бы не стал переименовывать контроллер домена в такой же DC2, даже если вычистить все методанные старого DC2 из домен среды. Обязательно где-ниб всплывёт потом.
      — с передачей ролей проблем быть не должно.

      Ответить
Полные правила комментирования на сайте winitpro.ru. Вопросы, не связанные с содержимым статьи или ее обсуждением удаляются.

Сказать Спасибо! можно на этой странице или (еще лучше) поделиться с друзями ссылкой на понравившуюся статью в любимой социальной сети(специально для этого на сайте присуствуют кнопки популярных соц. сетей).

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Я не робот( Обязательно отметьте)



MAXCACHE: 0.28MB/0.00120 sec