Как настроить репликацию контроллеров домена
О некоторых нюансах настройки межсайтовой репликации AD или «Не все статьи от Microsoft одинаково полезны»
Одним прекрасным весенним утром, когда свежая почта уже была прочитана, а чашка с чаем еще не закончилась, я наткнулся на статью в блоге «Ask the Directory Services Team» под названием Configuring Change Notification on a MANUALLY created Replication partner. В ней сотрудник Microsoft Джонатан Стивенс описывает способ научить ваши контроллеры домена побыстрее реплицировать изменения в AD между сайтами (в определенных условиях).
«Клево! — подумал я тогда — надо попробовать.»
В сертификационных курсах по AD и в многочисленных статьях нам сообщают, что существует два вида репликации: внутрисайтовая (intrasite) и межсайтовая (intersite).
N.B. Надеюсь все понимают что мы говорим о репликации каталога AD, которая не имеет никакого отношения к репликации папки Sysvol. И еще, если вы никогда не слышали об USN, KCC, Up-to-dateness Vector и прочих гадостях терминах, то дальше можете не читать, будет непонятно.
Внутрисайтовая репликация происходит «почти мгновенно» (на самом деле 5 секунд), межсайтовая — «по расписанию», которое обычно задается в свойствах SiteLink. Недостаток расписания в том, что минимальный период межсайтовой репликации составляет 15 минут (четыре раза в час) и не может быть уменьшен стандартными средствами.
«А нестандартными может?» — сразу спросите вы. «Может» — отвечает нам Microsoft в статье Advanced Replication Management, опубликованной на technet.microsoft.com. Оказывается, что изменение определенного бита в атрибуте Options соответствующего SiteLink позволяет включить режим уведомления о появившихся изменениях (Notification) при межсайтовой репликации AD. А режим уведомления и определяет разницу между двумя видами репликации. Замечательно, у нас будет «мгновенная» репликация для всех контроллеров!
А вот и нифига! К сожалению, в описанном на Technet способе есть одно существенное ограничение: уведомления об изменениях начинают работать только если AD DS connection был создан автоматически, посредством KCC. Такие AD DS connections имеют имя <automatically generated>, это если вы вдруг не знали :). Если же в вашей организации KCC по какой-то причине не доверяют и создают соединения вручную, то увы и ах, в той статье нам предлагали довольствоваться 15-минутным интервалом репликации.
Теперь вернемся к статье Джонатана Стивенса. В ней он описывает причину такого ограничения и способ его обойти. Дублировать информацию здесь не буду, если интересно, то ссылку на статью я привел в самом начале.
Итак, у нас есть инструкция, шаловливые ручки энтузиазм и немного свободного времени. Давайте пробовать!
Собираем полигон из двух виртуальных контроллеров домена под управлением Windows Server 2012 Datacenter Edition.
Уровень леса и домена Windows Server 2012. Оба контроллера являются серверами DNS и серверами глобального каталога, находятся в одном сетевом сегменте.
Разносим контроллеры по разным сайтам:
После этого вручную создаем дублирующие AD DS Connections, подталкиваем репликацию и затем удаляем автоматически сгенерированные соединения.
Note! Настоятельно рекомендую заменять соединения в указанном порядке, чтобы в любой момент времени между контроллерами существовала как минимум одна пара AD DS Connections, иначе может порушиться репликация, во всяком случае на некоторое время. Для надежности после каждого изменения вручную подталкивайте репликацию.
На контроллере ReplTest-DC2 в окне PowerShell запускаем скрипт:
Он позволит нам в реальном времени (раз в секунду) отслеживать изменение Up-To-Dateness vector контроллера ReplTest-DC2, выделяя из него строку, относящуюся к партнеру репликации с именем ReplTest-DC1.
Обратите внимание, в выделенной строке USN изменился с 12575 на 12605. Это произошло после того, как на ReplTest-DC1 был создан тестовый юзер и репликация была инициирована вручную.
Итак, мы убедились что репликация работает. Переходим непосредственно к проверке статьи Джонатана.
Устанавливаем четвертый бит атрибута Options в единицу для вручную созданного AD DS Connection (для верности я сделал это для обоих соединений: от ReplTest-DC1 и от ReplTest-DC2).
Не забываем подтолкнуть репликацию.
После этого редактируем произвольный атрибут произвольного объекта на ReplTest-DC1. Я, например, поменял поле Description у недавно созданного юзера.
Смотрим на состояние репликации на ReplTest-DC2:
Ноль реакции! USN не меняется!
Ждем пять секунд… ничего не меняется, ждем пять минут… опять не меняется!
Пытаемся проделать зеркальную операцию: вносим изменения в AD на ReplTest-DC2 и отлеживаем изменения на ReplTest-DC1. Тот же результат.
Несколько часов разнообразных тестов не изменили картины.
Признаюсь, я ожидал этого, потому что еще тогда, прекрасным весенним утром, я уже проделал те же самые действия для 2008 контроллеров.
Это печалит, но в данным момент я вынужден констатировать:
«Приведенный в статье Джонатана Стивенса метод включения уведомлений для созданных вручную AD DS Connections не работает»
Возможно, в статье опущен какой-то шаг или существуют дополнительные требования, но результат обескураживает. Я привык верить статьям команды AD DS.
Если у уважаемых коллег есть замечания к проведенному тесту или их результаты отличаются от моих, то прошу указать в комментариях кто редиска ошибся ли я и если да, то в каком месте.
Надеюсь что сообща мы докопаемся до истины.
Как настроить репликацию контроллеров домена
Добрый день! Уважаемые читатели и гости одного из лучших IT блогов Pyatilistnik.org. Не так давно я вам подробно рассказывал из каких компонентов и служб состоит Active Directory. Сегодня я хочу дополнить данную публикацию и подробно рассказать про утилиту командной строки Repadmin, благодаря ей я вас научу диагностировать репликацию между контроллерами домена, покажу как находить и решать проблемы в вашей доменной инфраструктуре. Каждый системный администратор, просто обязан ее знать и уметь ей пользоваться, если вы еще не из их числа, то давайте это исправлять.
Что такое Repadmin?
Если вы работаете с несколькими доменами Active Directory или сайтами AD, то вы обязательно столкнетесь с проблемами в какой-то момент, особенно в процессе репликации. Репликация, это самый важный жизненный цикл в доменных службах. Эта репликация важна, так как ее отсутствие может вызвать проблемы с аутентификацией. В свою очередь, это может создать проблемы с доступом к ресурсам в сети. Компания Microsoft это понимает, как никто другой и создала для этих задач отдельную утилиту Repadmin.
Как установить Repadmin?
Repadmin.exe встроен в Windows Server 2008 и выше, вы легко найдете его и на Windows Server 2019. Он доступен, если у вас установлена роль AD DS или сервера AD LDS. Он также доступен в клиентских ОС, таких как Windows 10, если вы устанавливаете инструменты доменных служб Active Directory, которые являются частью средств удаленного администрирования сервера (RSAT).
Требования для использования Repadmin
использование Repadmin требует учетных данных администратора на каждом контроллере домена, на который нацелена команда. Члены группы «Администраторы домена» имеют достаточные разрешения для запуска repadmin на контроллерах домена в этом домене. Члены группы «Администраторы предприятия» по умолчанию имеют права в каждом домене леса. Если вы запустите утилиту без необходимых прав, то вы получите сообщение:
Вы также можете делегировать конкретные разрешения, необходимые для просмотра и управления состоянием репликации.
Основные ключи Repadmin
Запустите командную строку от имени администратора или откройте PowerShell в режиме администратора и выполните команду:
В результате вы получите справку по утилите.
Теперь опишу вам за что отвечает каждый ключ:
Дополнительные параметры
Просмотр общего состояния репликации
Эта команда быстро покажет вам общее состояние репликации.
Обратите внимание, что одни и те же серверы перечислены в обоих разделах. Причина этого заключается в том, что Active Directory использует модель с несколькими основными доменами. Другими словами, обновления Active Directory могут быть записаны на любой контроллер домена (с заметными исключениями контроллеры домена только для чтения). Эти обновления затем реплицируются на другие контроллеры домена в домене. По этой причине вы видите одинаковые контроллеры домена в списке как DSA-источника, так и получателя. Если бы мой домен содержал какие-либо контроллеры домена только для чтения, они были бы перечислены только в разделе DSA назначения.
Сводный отчет о репликации не просто перечисляет контроллеры домена, в нем также перечислены самые большие дельты репликации. Вы также можете просмотреть общее количество попыток репликации, которые были недавно предприняты, а также количество неудачных попыток и увидеть процент попыток, которые привели к ошибке.
Пример применения дополнительных ключей
Вот пример ошибки «1722: The RPC server is unavailable», которую может показать repadmin с ключом replsummary.
Просмотр топологии репликации и ошибки
Команда repadmin /showrepl помогает понять топологию и ошибки репликации. Он сообщает, о состоянии каждого исходного контроллера домена, с которого у получателя есть объект входящего соединения. Отчет о состоянии делится на разделы каталога.
Административная рабочая станция, на которой вы запускаете Repadmin, должна иметь сетевое подключение удаленного вызова процедур (RPC) ко всем контроллерам домена, на которые нацелен параметр DSA_LIST. Ошибки репликации могут быть вызваны исходным контроллером домена, контроллером домена назначения или любым компонентом процесса репликации, включая базовую сеть.
Команда отображает GUID каждого объекта, который был первоначально реплицирован, а также результат репликации. Это полезно, чтобы обнаружить возможные проблемы. Как видите в моем примере, все репликации успешно пройдены. Если хотите получить максимально подробную информацию, о топологии репликации, то добавьте ключ «*».
В моем примере вы можете увидеть ошибку:
В приведенном выше примере решение проблемы заключается в остановке службы «Центр распространения ключей Kerberos (Kerberos key distribution center)«. Запустите ее. В редких случаях может потребоваться перезапустить службу «Доменные службы Active Directory«. Затем перезапустите процесс репликации через сайты и службы Active Directory. Проверьте свои журналы, и репликация должна быть успешной. Так же вы можете использовать и дополнительные ключи:
Просмотр очереди репликации
Бывают ситуации при которых у вас может возникать очередь на входящие запросы репликации. Основными причинами могут выступать:
Чтобы посмотреть очередь репликации на контроллере домена, вам нужно воспользоваться ключом /Queue:
Чаще всего у вас количество объектов в очереди будет нулевым, но если сайтов много, то могут быть небольшие очереди. Если вы заметили элементы, стоящие в очереди, и они никак не очищаются, у вас есть проблема. Вот пример сообщения, где очередь репликации не равна нулю.
Принудительная проверка топологии репликации
Repadmin умеет принудительно проверять топологию репликации на каждом целевом контроллере домена, чтобы немедленно пересчитать топологию входящей репликации.
По умолчанию каждый контроллер домена выполняет этот пересчет каждые 15 минут и если есть проблемы вы можете видеть в логах Windows событие с кодом 1311.
Выполните эту команду для устранения ошибок KCC или для повторной оценки необходимости создания новых объектов подключения от имени целевых контроллеров домена.
так же можно запустить для определенного сайта для этого используется параметр site:
Repadmin: выполнение команды /kcc контроллере домена dc03.child.root.pyatilistnik.org с полным доступом
Default-First-Site-Name
Текущий Параметры сайта: (none)
Проверка согласованности на dc03.child.root.pyatilistnik.org выполнена успешно.
Repadmin: выполнение команды /kcc контроллере домена dc02.root.pyatilistnik.org с полным доступом
Root
Текущий Параметры сайта: (none)
Проверка согласованности на dc02.root.pyatilistnik.org выполнена успешно.
Repadmin: выполнение команды /kcc контроллере домена dc04.child.root.pyatilistnik.org с полным доступом
Default-First-Site-Name
Текущий Параметры сайта: (none)
Проверка согласованности на dc04.child.root.pyatilistnik.org выполнена успешно.
Как принудительно запустить репликацию Active Directory
Бывают ситуации, когда вам необходимо произвести форсированное обновление на контроллере домена. Для этого есть специальный ключ /syncall. Для того, чтобы выполнить синхронизацию нужного контроллера домена со всеми его партнерами по репликации, вам необходимо на нем выполнить команду:
На выходе вы получите статус репликации и количество ошибок, выглядит это вот так:
Если имеются какие-то проблемы, то вы можете увидеть подобного рода ошибки:
так же repadmin /syncall имеет ряд флагов:
Экспорт результатов в текстовый файл
Иногда Repadmin отображает много информации. Вы можете экспортировать любой из приведенных выше примеров в текстовый файл, это немного упрощает последующее рассмотрение или сохранение для документации. Для этого используется инструкция «> путь до файла». Вот пример команд:
chcp 855 используется, чтобы у вас не было кракозябр вместо русского текста.
Как посмотреть количество изменений атрибутов
Хотя команда repadmin /showobjmeta отображает количество изменений атрибутов объекта и контроллер домена, которые вносили эти изменения, команда repadmin /showattr отображает фактические значения для объекта. Команда repadmin /showattr также может отображать значения для объектов, которые возвращаются запросом LDAP-протокола.
На объект может ссылаться его distinguished name или глобальный уникальный идентификатор объекта (GUID).
По умолчанию repadmin /showattr использует порт 389 LDAP для запроса доступных для записи разделов каталога. Однако repadmin /showattr может дополнительно использовать порт 3268 LDAP для запроса разделов, доступных только для чтения, на сервере глобального каталога. (Советую освежить в памяти какие порты использует Active Directory).
Основные параметры команды:
В следующем примере выполняется запрос к конкретному контроллеру домена.
В следующем примере запрашиваются все контроллеры домена, имена компьютеров которых начинаются с dc, и показывает значение для определенного атрибута msDS-Behavior-Version, который обозначает функциональный уровень домена.
В следующем примере запрашивается один контроллер домена с именем dc01 и возвращается версия операционной системы и версия пакета обновления для всех компьютеров с целевым идентификатором основной группы = 516.
Как посмотреть время последней резервной копирования Active Directory
Как посмотреть RPC-вызовы, на которые еще не ответили
Как посмотреть топологию репликации
Как сгенерировать топологию сайтов Active Directory
На этом у меня все, мы с вами разобрали очень полезную утилиту, которая позволит вам быть в курсе статуса репликации вашей Active Directory. С вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.
Популярные Похожие записи:
One Response to Repadmin и проверка репликации Active Directory
На одном из КД в лесу, в атрибутах объекта NTDS settings не верные параметры этого КД (сервера), а именно: GUID объекта, CNAME формируется от GUID, SPN имя соответственно. Можно ли редактировать эти параметры и как? Можно ли удалять объект NTDS settings, ведь он формируется DCPROMO?
Разворачиваем дополнительный контроллер домена на базе Windows Server 2012 R2. Репликация, настройка работы DHCP с основным контроллером домена.
В этой статьe мы разобрали как развернуть контроллер домена на базе Windows Server 2012 R2. Теперь наша задача развернуть дополнительный контроллер домена, который будет подстраховкой в случае если основной выйдет из строя.
Итак мы имеем в работе:
Проделываться все действия будут на виртуальной машине.
Установка Windows Server 2012 R2 и подготовительная настройка системы
Устанавливаем Windows Server 2012 R2 Standart with GUI. После установки системы обязательно:
На этом подготовка системы завершена, можно приступать к развертыванию необходимых ролей.
Поднимаем роли AD DS + DNS + DHCP на дополнительном контроллере домена
Все действия по развертыванию и настройке ролей на дополнительном контроллере домена, мы будем производить с основного контроллера домена. Поэтому заходим в моем случае на основной контроллер домена DC1 (192.168.0.2) и добавим наш дополнительный сервер в основной, Manage — Add Servers.
Переходим во вкладку DNS, в поле Search вбиваем IP-адрес нашего дополнительного сервера (в моем случае 192.168.0.3), сервер должен появится в списке найденных, выделяем его и нажимаем кнопку переместить (>). Нажимаем ОК.
После добавления сервера, если перейти в All Servers, то мы увидим что у нас там теперь два сервера. Теперь можно из основного сервера добавлять, настраивать роли на другом сервере.
Добавляем новую роль на дополнительном сервере DC2. Переходим Server Manager — Manage — Add Roles and Features.
Выбираем первый пункт Role-based or feature-based installation (Базовая установка ролей и компонентов).Нажимаем Next.
Выбираем Select a server from the server pool и выбираем сервер из списка, т.к. мы настраиваем дополнительный сервер, то выделяем dc2.jakonda.local и нажимаем Next.
Далее все как и в статье по развертыванию контроллера домена:
По завершении установки роли AD DS в Server Manager нажимаем на значок Флажка с восклицательным знаком и выбираем Promote this server to a domain controller (Повысить этот сервер до контроллера домена). Запустится мастер конфигурирования AD DS для сервера DC2.
Т.к. мы разворачиваем дополнительный контроллер домена, то нужно добавить его в уже существующий домен. Выбираем Add a domain controller to an existing domain. Автоматические подставится название текущего домена (jakonda.local) и какую доменную учетную запись использовать при выполнении данной операции. Нажимаем Next.
Проверяем установлены ли галочки (Domain Name System (DNS) Server, Global Catalog (GC)), в пункте Site name оставляем значение Default-First-Site-Name и задаем пароль для восстановления служб каталогов. Нажимаем Next.
Предупреждение о том что не может быть создано делегирование разворачиваемого DNS сервера, игнорируем. Нажимаем Next.
В дополнительных опциях в пункте Replicate from (Репликация из) выбираем основной контроллер домена DC1.jakonda.local. Это мы указываем дополнительному контроллеру домена откуда производить репликацию даннных AD, DNS. Нажимаем Next.
Пути к каталогам оставляем по-умолчанию, далее просматриваем сводную информацию по конфигурации AD DS. Нажимаем Next.
Если проверка выполнена успешно, то нажимаем Install.
После того пройдет установка, если зайти на DC2, то увидим что роли AD, DNS подняты, произведена репликация из DC1.
Если необходимо посмотреть, изменить параметры репликации, то заходим Server Manager — Tools — Active Directory Sites and Services.
Так же можно с помощью командной строки принудительно запустить процесс репликации, с помощью утилиты repadmin:
Так же с помощью данной утилиты можно посмотреть результат последних репликаций:
Теперь перейдем к развертыванию DHCP на дополнительном сервере DC2 и его настройке в совместном режиме работы с DHCP на основном сервере DC1.
Поднимаем на дополнительном сервере службу DHCP и настраиваем ее режим работы
Устанавливаем роль DHCP Server аналогично как описано в этой статье только в качестве установки роли выбираем дополнительный сервер.
После установки Роли, в Server Manager нажимаем на значок Флажка с восклицательным знаком и выбираем Complete DHCP configuration (Завершить конфигурацию DHCP). Запустится мастер после установочной конфигурации DHCP. В мастере выполняем следующие действия:
На основном контроллере домена DC1, настроен DHCP-сервер, нужно решить как будет работать DHCP-сервер на дополнительном контроллере домена DC2. Пути решения могут быть такие:
Настройка Split Scope (использование разделенных областей). Открываем оснастку DHCP на основном сервере DC1: Server Manager — Tools — DHCP. Нажимаем правой кнопкой мыши по имени области и выбираем Advanced… — Split Scope.
Описание режима Split-Scope. Нажимаем Next.
Указание дополнительного DHCP сервера, в моем случае DC2. Нажимаем Add Server.
Отмечаем пункт This authorized DHCP server и выбираем дополнительный сервер (dc2.jakonda.local). Нажимаем ОК и следом Next.
Задаем процентное соотношение распределения адресного пула между двумя серверами DC1 и DC2. Ниже видно с какого по какой адрес будет выдаваться основным и дополнительным сервером. Нажимаем Next.
Указываем задержку ответа серверов в мс. Укажем для дополнительного сервера DC2 задержку в 10 мс, выдавать все адреса будет основной сервер DC1, а дополнительный только при недоступности основного или заполнении его пула адресов.
Вывод сводной информации по настройке. Нажимаем Finish.
Если все заданные нами параметры успешно установлены, то напротив каждого пункта будет Successful. Нажимаем Close.
Открываем оснастку DHCP на дополнительном сервере DC2: Server Manager — Tools — DHCP. Нажимаем правой кнопкой мыши по имени области и выбираем Activate.
Теперь при отказе или заполнении выделенного на основной сервер DC1 пула адресов, его подстрахует дополнительный сервер DC2.
Настройка Failover (Отказоустойчивый). Открываем оснастку DHCP на основном сервере DC1: Server Manager — Tools — DHCP. Нажимаем правой кнопкой мыши по имени области и выбираем Configure Failover…
Выбираем пул к которому хотим применить Failover. Нажимаем Next.
В поле Partner Server выберем второй сервер (dc2.jakonda.local). Пункт Reuse existing failover relationships configured with this server (if any exist) (Использовать существующие отношения отработки отказа с этим сервером (если доступно)) будет активно, если ранее уже создавалось отказоустойчивый профиль, то мастер предложит воспользоваться существующим профилем. Нажимаем Next.
Задание отказоустойчивых параметров:
Задаем нужные нам параметры. Нажимаем Next.
Вывод сводной информации по указанной конфигурации. Нажимаем Finish.
Если все заданные нами параметры успешно установлены, то напротив каждого пункта будет Successful. Нажимаем Close.
В рамках текущей задачи, мы настроили работу дополнительного контроллера домена DC2, который в случае отказа основного контроллера домена DC1 подстрахует его.