Укажите дополнительные параметры репликации
Управление репликацией 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, и чтобы уменьшить объем передаваемого трафика по сети.
Межсайтовую топологию в лесу можно проанализировать при помощи команды:
данная команда отобразит список сайтов в лесу Active Directory. Для каждого из сайтов указаны 3 значения: стоимость репликации между двумя сайтами, интервал репликации в минутах, а также дополнительные настроенные параметры межсайтовой связи. Вывод этой команды может выглядеть так:
В вышеприведённом логе видно, что в домене 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). Формат команды такой:
на выходе получаем примерно следующее:
Чтобы для определенного контролера домена отобразить всех партнеров по репликации, с датой и временем последней репликации, воспользуйтесь командой:
Стоит отметить, что служба DNS – это важный компонент службы репликации Active Directory. Контроллеры домена регистрируют свои SRV записи в DNS. Каждый контроллер домена в лесу регистрирует записи CNAME вида dsaGuid._msdcs.forestName, где dsaGuid –GUID видимый у объекта в пункте NTDS Settings в консоли «AD Sites and Services». Если в журнале Directory Services есть ошибки, связанные со службой DNS, для проверки корректных записей типа CNAME и A для контроллера домена.
Если будут ошибки, перезапустите службу Netlogon, в результате чего произойдет перерегистрация отсутствующих dns записей. Если dcdiag все также будет выдавать ошибки, проверьте конфигурацию службы DNS и корректность DNS настроек на DC. Для более детального знакомства с темой тестирования служб dns, рекомендую обратиться к статье Диагностика проблем с поиском контроллера домена.
Команда repadmin имеет специальный параметр /replsummary, который позволяет быстро проверить состояние репликации на конкретном контроллере домена (указывается его имя) или на всех контроллерах (опция wildcard).
В том случае, если ошибки репликации отсутствуют, в выводе этой команды будет видно, что ошибок – 0.:
В том случае, если ошибки все-таки будут, при помощи утилиты Repadmin можно получить более полную информацию. Каждый контроллер домена имеет собственный уникальный USN (Update Sequence Number), который инкрементируется каждый раз при успешном изменении обновлении объекта Active Directory. При инициализации репликации, партнеру передается USN, который сравнивается с USN, полученным в результате последней успешной репликации с данным партнером, тем самым определяя сколько изменений произошло в базе AD со времени последней репликации.
При помощи ключа /showutdvec, можно получить список текущих значений USN, хранящихся на указанном DC.
Запустив эту команду на контроллере домена, на котором наблюдаются проблемы с репликацией, можно понять насколько различаются базы AD, просто сравнив значения USN.
Тестирование репликации Active Directory при помощи утилиты repadmin можно осуществить несколькими способами:
При наличии проблем с механизмом репликации Active Directory, нужно знать и уметь пользоваться утилитами repadmin, nslookup, dcdiag, крайне полезен при анализе журнал событий Directory Services. В особо сложный и нестандартных ситуациях может помочь база знаний Microsoft KB, в которой описаны типовые проблемы и методики их решения. Поиск по базе KB обычно осуществляется по идентификаторам ошибок (Event ID), полученным из указанного журнала..
Принудительная репликация между двумя контроллерами домена в Active Directory
Представьте, что в вашем доме всего одна дверь. Нет окон, нет двери патио, только одна дверь. Что произойдет, если вы не сможете открыть эту дверь? Дом и все в нем бесполезно для вас.
Контроллер домена, в некотором смысле, похож на дверь. Один с вышибалой на это. Это ворота, чтобы попасть внутрь к вещам, которые вы хотите. Active Directory (AD) – это вышибала у двери. Он проверяет ваши учетные данные, определяет, разрешено ли вам проходить через дверь, и к каким ресурсам вы можете получить доступ один раз внутри.
Если вы используете какую-либо сеть и имеете только один контроллер домена, вы живете в доме с одной дверью. Если что-то случится с этим контроллером домена, вся ваша система серверов развалится. Всегда иметь более одного контроллера домена (DC).
Но как убедиться, что оба контроллера домена имеют одинаковую информацию? Допустим, вы внесли изменения, связанные с безопасностью, на одном DC. Вы хотите, чтобы изменения немедленно реплицировались на другие контроллеры домена. Зачем ждать 15 минут или больше, чтобы это произошло по расписанию? Вам нужно форсировать репликацию контроллеров домена в Active Directory,
Есть 3 способа приблизиться к этому; через графический интерфейс пользователя (GUI), через интерфейс командной строки (CLI) или через PowerShell.
Принудительная репликация контроллера домена через графический интерфейс
Windows-серверы часто используют GUI, что хорошо для начинающих системных администраторов. Его легче учить, а иногда помогает визуализировать, что на самом деле происходит.
Принудительная репликация контроллеров домена с помощью командной строки
Если вы знакомы со старым добрым Windows CMD, то команда repadmin для вас. Это самый быстрый одноразовый способ принудительного дублирования DC. Если вы не знакомы, то сейчас самое время узнать о Windows CMD.
repadmin / syncall / AdeP
Принудительная репликация контроллера домена с помощью PowerShell
Если вы не используете PowerShell в своей повседневной жизни, вы пропустите. Вы действительно обязаны изучать PowerShell. Это облегчит вашу жизнь, а если вы являетесь младшим системным администратором, это поможет вам сделать карьеру следующим шагом.
Эти шаги можно выполнить в обычном интерфейсе командной строки PowerShell, но мы сделали это в PowerShell ISE, чтобы лучше показать команды и их результаты. Мы собираемся создать сценарий, который вы можете сохранить или даже превратить в командлет, который можно вызывать из командной строки PowerShell.
Видите как он возвращает имена ДК? Теперь вы можете передать этот результат в следующий командлет. Канал – это символ вертикальной линии (|), который обычно находится на клавиатуре чуть выше клавиши Enter.
Команда должна выглядеть так, как показано на рисунке ниже. Запустить его. Он должен вернуть сообщение, подобное тому, которое было в разделе «Принудительная репликация контроллера домена через графический интерфейс выше». Если это заканчивается на «SyncAll завершен без ошибок». тогда это сработало.
Вы видели, как он также использует команду repadmin?
Результат должен напоминать изображение ниже. Внизу вы увидите точную дату и время последней репликации.
Keep’em Replicated
Теперь вы знаете 3 способа форсирования репликации контроллеров домена в AD. Вы также собрали повторно используемый сценарий PowerShell, который можно вызывать из командной строки PowerShell в любое время. Нет никаких оправданий для ваших последних изменений DC, чтобы сидеть и ждать следующей запланированной репликации, когда бы это ни было.
О некоторых нюансах настройки межсайтовой репликации 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.
Если у уважаемых коллег есть замечания к проведенному тесту или их результаты отличаются от моих, то прошу указать в комментариях кто редиска ошибся ли я и если да, то в каком месте.
Надеюсь что сообща мы докопаемся до истины.
Установка и настройка DFS и репликации файлов в Windows Server 2012
Распределенная файловая система DFS ( Distributed File System) – это технология, обеспечивающая возможности упрощения доступа к общим файловым ресурсам и глобальной репликации данных. Благодаря DFS распределённые по различным серверам общие ресурсы (каталоги и файлы) можно объединить в единую логическую UNC структуру, которая для пользователя выглядит, как единый сетевой ресурс. Даже при изменении физического местоположения целевой папки, это не влияет на доступ пользователя к ней.
Установка служб DFS в Windows Server 2012
Установить службы DFS можно с помощью консоли Server Manager или же при помощи Windows PowerShell.
Как мы уже говорили, службы DFS являются элементами роли Files and Storage Services:
Но проще и быстрее установить все DFS службы и консоль управления DFS с помощью PowerShell:
, где FS-DFS-Namespace – служба DFS Namespaces
FS-DFS-Replication – служба репликации DFS Replication
RSAT-DFS-Mgmt-Con– mmc консоль управления службами DFS — DFS Management Tools (также входит в состав Remote Server Administration Tools для Windows 10)
Настройка пространства имен DFS в Windows Server 2012
Перейдем к описанию процедуры настройки пространство имен DFS, для чего необходимо открыть панель управления DFS Management tool.
Создадим новое пространство имен (New Namespace).
Необходимо указать имя сервера, который будет содержать пространство имен (это может быть как контроллер домена, так и рядовой сервер).
Затем следует указать имя создаваемого пространства имен DFS и перейти в расширенные настройки (Edit Settings).
Здесь следует указать имя пространства имен DFS и права доступа к данному каталогу. Обычно рекомендуется указать, что доступ к сетевой папке разрешен Всем (Everyone), в этом случае права доступа проверяются на уровне файловой системы NTFS.
Далее мастер предложит указать тип создаваемого пространства имен. Это может быть Domain-based namespace (доменное пространство имен) или Stand-alone namespace (отдельное пространство имен). Domain-based namespace обладает ряд преимуществ, но для его работы нужен, собственно домен Active Directory и права администратора домена (либо наличие делегированных прав на создание доменных пространств имен DFS).
После окончания работы мастера в ветке Namespaces консоли управления DFS появится созданное нами новое пространство имен DFS. Чтобы пользователи при доступе к DFS каталогам видели только те каталоги, к которым у них имеется доступ, включим для данного пространства DFS Access-Based Enumeration (подробнее о данной технологии в статье Access-Based Enumeration в Windows). Для этого откройте окно свойств созданного пространства имен.
И на вкладке Advanced включите опцию Enable access-based enumeration for this namespace.
Чтобы посмотреть содержимое нового пространства DFS, просто наберите в окне проводника UNC путь: \\имя_домена_или_сервера\DFS
Добавление дополнительного DFS сервера
В доменное пространство имен DFS можно добавить дополнительный сервер (пункт меню Add Namespace Server), который его будет поддерживать. Делается это для увеличения доступности пространства имен DFS и позволяет разместить сервер пространства имен в том же сайте, в котором находится пользователи.
Добавление нового каталога в существующее пространство имен DFS
Теперь нужно добавить новый сетевой каталог в иерархию созданного нами пространства имен DFS. Нажмите кнопку Add Folder Target.
Укажите наименование каталога в DFS пространстве и его реальное местоположение на существующем файловом сервере (Folder targets).
Настройка DFS-репликации на Windows Server 2012
Технология репликации DFS-R предназначена для организации отказоустойчивости пространства имен DFS и балансировки нагрузки между серверами. DFS-R автоматически балансирует трафик между репликами в зависимости от их загрузки и в случае недоступности одного из серверов перенаправляет клиентов на другой сервер-реплику. Но прежде, чем говорить о DFS репликации и ее настройке в Windows Server 2012перечислим основные системные требования и ограничения:
В консоли DFS Managment выберите нужный вам DFS Namespace и щелкните ПКМ по каталогу, для которого необходимо создать реплику и выберите пункт Add Folder Target.
И укажите полный (UNC) путь к сетевому каталогу другого сервера, в котором и будет храниться реплика.
На вопрос хотите ли вы создать группу репликации отвечаем Yes.
Запускается мастер настройки репликации. Проверяем имя группы репликации и каталог.
Указываем первичный (Primary) сервер. Именно этот сервер будет источником данных при инициальной (первичной) репликации.
Затем выбираем тип топологии (соединения) между членами группы репликации. В нашем примере выбираем Full Mesh (все со всеми).
И, наконец, указываем расписание репликации и параметры bandwidth throttling – ограничение доступной для репликации полосы пропускания. 
После окончания работы мастера, запуститься первоначальная синхронизация.
В случае необходимости, настройки расширенных параметры расписания репликации и максимальную полосу пропускания под данный трафик, можно задать в ветке Replication.