Репликация контроллеров домена вручную

Управление репликацией 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 можно осуществить несколькими способами:

• replmon /replicate (позволяет запустить репликацию определенного раздела на указанный контроллер домена)
• replmon /replsingleobj (репликация конкретного объекта между двумя DC)
• replmon /syncall (синхронизация указанного контроллера домена со всем партнерами по репликации)

При наличии проблем с механизмом репликации Active Directory, нужно знать и уметь пользоваться утилитами repadmin, nslookup, dcdiag, крайне полезен при анализе журнал событий Directory Services. В особо сложный и нестандартных ситуациях может помочь база знаний Microsoft KB, в которой описаны типовые проблемы и методики их решения. Поиск по базе KB обычно осуществляется по идентификаторам ошибок (Event ID), полученным из указанного журнала..

Репликация контроллеров домена вручную

Тнперь выдаёт следующие ошибки:

Тип события: Предупреждение
Источник события: NtFrs
Категория события: Отсутствует
Код события: 13514
Дата: 13.01.2002
Время: 16:18:21
Пользователь: Нет данных
Компьютер: NEW
Описание:
Служба репликации файлов может препятствовать изменению роли компьютера NEW на роль контроллера домена, пока выполняется инициализация системного тома с помощью данных с другого контроллера домена и он становится общим ресурсом под именем SYSVOL.
Введите команду «net share» чтобы проверить наличие ресурса SYSVOL. Служба репликации файлов перестанет препятствовать переводу на роль контроллера домена после появления общего ресурса SYSVOL.
Для инициализации системного тома требуется некоторое время. Оно зависит от объема данных на системном томе, от наличия других контроллеров домена, и от частоты репликаций между контроллерами доменов.

Нет шары SYSVOL. Если создать вручную то после перезапуска netlogon опять пропадает.

Тип события: Предупреждение
Источник события: NtFrs
Категория события: Отсутствует
Код события: 13562
Дата: 13.01.2002
Время: 16:19:12
Пользователь: Нет данных
Компьютер: NEW
Описание:
Ниже следует сводка предупреждений и ошибок, которые произошли при опросе службой репликации файлов (FRS) сведений конфигурации набора репликации FRS у контроллера домена «NEW».

nTDSConnection объект cn=OLD,cn=ntds settings,cn=NEW,cn=servers,cn=default-first-site-name,cn=sites,cn=configuration,dc=flh конфликтует с cn=75279efc-3c84-4a98-853a-26fc1e389b9e,cn=ntds settings,cn=NEW,cn=servers,cn=default-first-site-name,cn=sites,cn=configuration,dc=DOMAIN. Используется cn=OLD,cn=ntds settings,cn=NEW,cn=servers,cn=default-first-site-name,cn=sites,cn=configuration,dc=DOMAIN

ещё однаТип события: Предупреждение
Источник события: NtFrs
Категория события: Отсутствует
Код события: 13508
Дата: 13.01.2002
Время: 16:20:52
Пользователь: Нет данных
Компьютер: NEW
Описание:
Служба репликации файлов столкнулась с проблемами при включении репликации с «OLD» на «NEW» для «c:winntsysvoldomain», использующего DNS-имя «OLD.DOMAIN» Служба репликации файлов (FRS) продолжит повторные попытки.
Ниже указаны причины, по которым может выдаваться это предупреждение.

[1] FRS не может разрешить DNS-имя «OLD.DOMAIN» с этого компьютера.
[2] FRS не запущена на «OLD.DOMAIN».
[3] Сведения в Active Directory о топологии для этой реплики реплицированы еще не на все контроллеры домена.
Это сообщение об ошибке записывается в журнал для каждого подключения один раз. После исправления ошибки в журнал будет записано другое сообщение, означающее, что соединение установлено.

1. По имени пинг проходит.
2. Служба репликации файлов на OLD запущена
3. А это как проверить?

Тип события: Предупреждение
Источник события: NTDS Replication
Категория события: Репликация
Код события: 1586
Дата: 13.01.2002
Время: 16:33:05
Пользователь: Все
Компьютер: NEW
Описание:
Создание контрольной точки с PDC выполнено неудачно. Процесс создания контрольной точки будет повторен через четыре часа. Может потребоваться полная синхронизация базы данных безопасности с пред-Windows 2000 контроллерами домена, если этот компьютер будет выдвинут на роль PDC перед тем, как будет успешно создана контрольная точка. Возвращена следующая ошибка: Контекст именования находится в процессе удаления или не был реплицирован с указанного сервера.

Нет, вот последнее:

Тип события: Ошибка
Источник события: NETLOGON
Категория события: Отсутствует
Код события: 3210
Дата: 13.01.2002
Время: 16:18:10
Пользователь: Нет данных
Компьютер: NEW
Описание:
Сбой при проверке имени на \OLD.DOMAIN, контроллере домена Windows NT или Windows 2000 для домена DOMAIN.
Данные:
0000: 22 00 00 c0 «..À

Я не уверен в том что это я всё неправильно делаю, OLD работает с большими глюками.
Последний вопрос : Если я поменяю хозяина операций принудительно, смогу ли потом выйти из автономного режима?

З.Ы.
Убить AD ни NEW не могу, «Операция DSA не могла быть выполнена, т.к. произошла ошибка в DNS»
В DNS есть записи А (как папка верхнего уровня) и А NEW c IPшником NEW
Адресация статическая

то ли после установки толи в евент вьювере еслть описание как сделать этот sysvol
если в краце то:
HKLMSystemCurentControlSetSevicesNetlogonParametrs
должно быть 2 ключа:
SysVol:REG_SZ:c:winntSYSVOLsysvol(ну или твой путь)
SysvolReady:REG_WORD:0x1 (по умолчанию он 0х0 и поэтому не расшаривается)

по поводу следуших ошибок : попробуй наладить сначала репликацию. все это похоже на следствие.

ты уверен, что у тебя ДНС нормально работает?

у тебя ДНС один? где он стоит? на ОЛД ? на НЬЮ? или отдельно?

nslookup резолвит имена Олд-а Нью.

Добавление от 15-01-2002 13:55:

выложи файлик domainname.dns из c:winntsystem32dns

Добавление от 15-01-2002 13:58:

хм. «. давай позвоним?»

> flowersh
Server: UnKnown
Address: 192.168.0.1

Name: flowersh.FLH
Address: 192.168.0.1

> flowersh1
Server: UnKnown
Address: 192.168.0.1

Name: flowersh1.FLH
Address: 192.168.0.2

> exit
Flowersh — это OLD
Flowersh1 — это NEW

А нету такого файла. Ну мой_домен.dns который.
Только в папке backup
вот он :

;
; Database file FLH.dns for flh zone.
; Zone version: 1
;

@ IN SOA flowersh. admin. (
1 ; serial number
900 ; refresh
600 ; retry
86400 ; expire
3600 ) ; minimum TTL

Добавление от 15-01-2002 15:47:

Gogga
хм. «. давай позвоним?»
В этой машине ещё и модем есть.

@ IN SOA delta.domain.ru. root.domain.ru. (
2002011159 ; serial number
900 ; refresh
600 ; retry
86400 ; expire
3600 ) ; minimum TTL

;
; WINS lookup record
;

@ WINS L2 C900 (
192.168.1.2 )

@ 600 A 192.168.1.10
@ 600 A 192.168.1.2
013 900 A 192.168.1.116
028 900 A 192.168.1.79
. итд(автоматически добавляется при включении станции)
074 900 A 192.168.1.61
.

alpha 1200 A 192.168.1.10
delta A 192.168.1.2
.

alpha и delta -доменконтролерры
delta -dns-server

и фаил 1.186.192.in-addr.arpa.dns
;
; Database file 1.168.192.in-addr.arpa.dns for 1.168.192.in-addr.arpa zone.
; Zone version: 2002010404
;

@ IN SOA delta.domain.ru. administrator.domain.ru. (
2002010404 ; serial number
900 ; refresh
600 ; retry
86400 ; expire
3600 ) ; minimum TTL

10 PTR alpha.
2 PTR delta.
6 PTR server.domain.ru.

и еще cahe.dns из samples добавь

ЗЫ если где ошибся, поправте.

там еще кучка строк есть, я честно говоря с этим не разбирался но для переноса АД они могут быть важны. строчки вида:
_kerberos._tcp.domainmoscow._sites.dc._msdcs 600 SRV 0 100 88 delta.domain.ru.
600 SRV 0 100 88 alpha.domain.ru.
_ldap._tcp.domainmoscow._sites.dc._msdcs 600 SRV 0 100 389 delta.domain.ru.
600 SRV 0 100 389 alpha.domain.ru.
_kerberos._tcp.dc._msdcs 600 SRV 0 100 88 delta.domain.ru.
600 SRV 0 100 88 alpha.domain.ru.
_ldap._tcp.dc._msdcs 600 SRV 0 100 389 delta.domain.ru.
600 SRV 0 100 389 alpha.domain.ru.
_ldap._tcp.1ee659df-7a3f-453a-9476-af4dfa674b29.domains._msdcs 600 SRV 0 100 389 delta.domain.ru.
600 SRV 0 100 389 alpha.domain.ru.
fc36b86a-7520-4efa-bf44-665656cbb8a1._msdcs 600 CNAME delta.domain.ru.
ffa51544-df4f-4e7d-b5e0-4dcac80139ba._msdcs 600 CNAME alpha.domain.ru.
gc._msdcs 600 A 192.168.1.2
_ldap._tcp.domainmoscow._sites.gc._msdcs 600 SRV 0 100 3268 delta.domain.ru.
_ldap._tcp.gc._msdcs 600 SRV 0 100 3268 delta.domain.ru.
_ldap._tcp.pdc._msdcs 600 SRV 0 100 389 delta.domain.ru.
_gc._tcp.domainmoscow._sites 600 SRV 0 100 3268 delta.domain.ru.
_kerberos._tcp.domainmoscow._sites 600 SRV 0 100 88 delta.domain.ru.
600 SRV 0 100 88 alpha.domain.ru.
_ldap._tcp.domainmoscow._sites 600 SRV 0 100 389 delta.domain.ru.
600 SRV 0 100 389 alpha.domain.ru.
_gc._tcp 600 SRV 0 100 3268 delta.domain.ru.
.
итд

Добавление от 15-01-2002 19:19:

Кстати ещё: снос и установка DNC на OLD ничего не изменила.

ставь dhcp )

а ты как АД убиваешь.

«Мож кто знает сервер где-нить снаружи на кого можно синхронизаию настроить? «

завтра посмотрю . а вообще яндекс, найдется все))

Добавление от 16-01-2002 08:46:

А по поводу DHCP я подумаю

Добавление от 16-01-2002 14:26:

Эта сволочь (OLD) не может после реликации остановить службу репликации файлов для понижения статуса сервера, сервис просто виснет.
Всё, format.com, задолбало!

Information Security Squad

stay tune stay secure

Инструмент Repadminl: проверка состояния репликации Active Directory

Чтобы поддерживать домен Active Directory в исправном состоянии, следует периодически проверять репликацию между контроллерами домена с помощью инструментов repadmin и dcdiag (мы рассмотрели использование утилиты dcdiag в предыдущем руководстве.

Репликация Active Directory полностью автоматизирована и правильно планирует конфигурацию архитектуры AD, сайтов и расписания репликации практически не требует ручного управления системным администратором.

Действительно, в небольших доменах AD с несколькими контроллерами домена (2-5) проблем с репликацией обычно почти нет, но в больших инфраструктурах из десятков и сотен контроллеров домена администратору домена часто приходится вмешиваться в процесс репликации и исправлять ошибки.

Средство командной строки repadmin можно использовать для мониторинга репликации, отслеживания сбоев репликации между контроллерами домена и принудительной репликации данных.

Утилита repadmin в Windows Server 2003 была включена в пакет средств поддержки, который необходимо было загрузить и установить вручную.

В Windows Server 2008 R2 и более поздних версиях средство repadmin автоматически устанавливается на контроллере домена при установке роли ADDS (доменные службы Active Directory).

Вы можете установить repadmin на настольные версии Windows (Wndows 10 / 8.1 / 7).

Для этого установите RSAT и включите опцию AD DS и AD LDS Tools.

Чтобы использовать repadmin, откройте командную строку от имени администратора.

Вы можете перечислить полный синтаксис команды, набрав:

Как видите, команда имеет довольно много опций.

Давайте попробуем изучить некоторые полезные примеры использования repadmin.

Чтобы быстро проверить работоспособность репликации между контроллерами домена, обычно используется следующая команда:

Как видите, в домене AD есть только 2 контроллера домена, между которыми в настоящее время нет ошибок репликации.

Каждый сервер действует как исходный DSA и целевой DSA.

Чтобы проверить оставшееся количество объектов каталога AD в очереди репликации, выполните:

Используя команду Repadmin / Showrepl, вы можете отобразить состояние репликации для текущего DC.

Она отображает время последней попытки репликации разделов Active Directory.

Если вы считаете, что какой-то контроллер домена не получает обновления репликации, выполните для него эту команду.

Совет. Для отображения подробной информации в любой команде используйте параметр /verbose.

Базовую доступность каталога LDAP на конкретном контроллере домена можно проверить с помощью команды:

Вы можете принудительно выполнить репликацию указанного контроллера домена со всеми партнерами по репликации DC, используя команду:

Не рекомендуется выполнять эту команду в больших доменах Active Directory, так как это может вызвать большую нагрузку на сеть.

Чтобы начать репликацию всех разделов Active Directory по всему лесу, выполните команду:

При использовании этой команды также возможна высокая нагрузка на каналы связи.

Команда Repadmin / kcc указывает KCC (Knowledge Consistency Checker) на указанном контроллере домена немедленно пересчитать топологию входящей репликации (она запускается автоматически каждые 15 минут).

Команда Repadmin / replicate позволяет вам реплицировать определенный раздел каталога с исходного DC на целевой. Например:

Диагностика репликации домена

Утилита Repadmin

REPADMIN /SHOWREPL
показывает состояние репликации для контроллера домена

REPADMIN /REPLSUMMARY
сводка репликации для всех DC леса

REPADMIN /SYNCALL
Запускает репликацию между DC и партнерами по репликации

Для более глубокого анализа можно задействовать команду:
REPADMIN *
(звездочка вместо использования имени DC).

Утилита FRSDiag

Диагностика с помощью утилиты FRSdiag.exe: в центре загрузки Microsoft есть утилиты «Windows 2003 support tools». Среди этих утилит (а возможно и отдельно от них) есть утилита «File Replication Service Diagnostics Tool» — FRSdiag.exe. Скачайте утилиту и запустите ее. Никаких настроек менять не надо, достаточно нажать «GO». Утилита произведет диагностику и выдаст массу информации.

Восстановление репликации между контроллерами домена

Если по каким-то причинам один из контроллеров домена не работал более 60 дней, то прекращается синхронизация между контроллерами домена. Появляются разные сообщения об ошибках в логах. Чтобы восстановить синхронизацию, необходимо произвести несколько действий:

1. провести диагностику с помощью утилиты FRSdiag.exe;
2. удалить объекты, которые различаются на контроллерах домена. Обычно это устаревшие и уже давно удаленные объекты;
3. разрешить репликацию с серверами, которых давно не было в сети;
4. произвести репликацию, убедиться, что она успешная, и снова запретить репликацию с серверами, которых давно не было в сети.

1. Диагностика с помощью утилиты FRSdiag.exe

Скачайте утилиту и запустите ее. Никаких настроек менять не надо, достаточно нажать «GO». Утилита произведет диагностику и выдаст массу информации. Если там будут следующие строки, переходите к следующим пунктам:

• «Error 2042 It has been too long since this machine last replicated with the named source machine. The time between replications with this source has exceeded the tombstone lifetime.»
• «Use the «repadmin /removelingeringobjects» tool to remove inconsistent deleted objects and then resume replication.»

2. Удаление объектов, которые различаются на контроллерах домена

для этого служит команда:
Repadmin /removelingeringobjects
Не торопитесь ее выполнять! Там масса других параметров.
Описание здесь:
http://support.microsoft.com/kb/870695/en-us
НО! там тоже описано далеко не все! Вот более точная инструкция:
http://blogs.technet.com/b/glennl/archive/2007/07/26/clean-that-active-directory-forest-of-lingering-objects.aspx Что необходимо сделать: сначала надо «очистить» один из контроллеров домена, а потом будем использовать его в качестве эталона. Для этого сначала проводим инспекцию (что надо удалить). С этой целью используется опция /advisory_mode:

repadmin /removelingeringobjects Destination_domain_controller Source_domain_controller_GUID Directory_partition /advisory_mode
где:
Destination_domain_controller — имя контроллера, который будем «чистить».
Source_domain_controller_GUID — идентификатор контроллера, который будет использоваться в качестве «образца» для чистки.
Directory_partition — это разделы Active Directory (их можно посмотреть с помощью adsiedit.msc).

Узнать идентификатор контроллера несложно, есть 2 метода:

1. At a command prompt, type repadmin /showrepl /v name of the authoritative server, and then press ENTER. The object GUID of the domain controller is listed in the DC object GUID field.
2. Use the Active Directory Sites and Services tool to locate the object GUID of the source domain controller. To do this, follow these steps:
   1. Click Start, point to Administrative Tools, and then click Active Directory Sites and Services.
   2. Expand Sites, expand the site where your authoritative domain controller is located, expand Servers, and then expand the domain controller.
   3. Right-click NTDS Settings, and then click Properties.
   4. View the value in the DNS Alias box. The GUID that appears in front of _msdcs.forest_root_name.com is the object GUID of the domain controller. The Repadmin tool only requires the GUID. Do not include the _msdcs.forest_root_domain_name.com component in the Repadmin syntax.

Разделы Active Directory — как написано в инструкции:
?Domain directory partition (dc=domain_DN)
?Configuration directory partition (cn=Configuration,dc=forest_root_DN)
?Application directory partition or partitions
(cn=Application_directory_partition_name,dc=domain_DN)
(cn=Application_directory_partition_name,dc=forest_root_DN)
?Schema directory partition (cn=Schema, cn=Configuration,dc=,dc=forest_root_DN)

Итак, пример. У нас есть 3 контроллера домена: DC1, DC2, DC3, домен mydom.com. Сначала мы «почистим» DC1, используя в качестве образцов DC2 и DC3, а потом «почистим» DC2 и DC3, используя в качестве образца DC1: сначала берем «образец» для DC1 с DC2:
repadmin /removelingeringobjects DC1 ff4d1971-a0ed-4915-a297-b25041a10c74 DC=MYDOM,DC=COM /advisory_mode
repadmin /removelingeringobjects DC1 ff4d1971-a0ed-4915-a297-b25041a10c74 CN=Configuration,DC=MYDOM,DC=COM /advisory_mode
repadmin /removelingeringobjects DC1 ff4d1971-a0ed-4915-a297-b25041a10c74 CN=Schema,CN=Configuration,DC=MYDOM,DC=COM /advisory_mode
repadmin /removelingeringobjects DC1 ff4d1971-a0ed-4915-a297-b25041a10c74 CN=Schema,CN=Configuration,DC=MYDOM,DC=COM /advisory_mode
repadmin /removelingeringobjects DC1 ff4d1971-a0ed-4915-a297-b25041a10c74 DC=ForestDNSZones,DC=MYDOM,DC=COM /advisory_mode
repadmin /removelingeringobjects DC1 ff4d1971-a0ed-4915-a297-b25041a10c74 DC=DomainDNSZones,DC=MYDOM,DC=COM /advisory_mode

потом залезаем в логи (Directory Service, источник NTDS Replication) и смотрим:

«Active Directory has completed the verification . Source domain controller: .
Number of objects examined and verified:
0
. «

Если количество объектов не 0, смотрим что это за объекты, и если все ок, грохаем (то же самое, но без advisory_mode):
repadmin /removelingeringobjects DC1 224d1971-a0ed-4915-a297-b25041a10c74 DC=MYDOM,DC=COM
repadmin /removelingeringobjects DC1 224d1971-a0ed-4915-a297-b25041a10c74 CN=Configuration,DC=MYDOM,DC=COM
repadmin /removelingeringobjects DC1 224d1971-a0ed-4915-a297-b25041a10c74 CN=Schema,CN=Configuration,DC=MYDOM,DC=COM
repadmin /removelingeringobjects DC1 224d1971-a0ed-4915-a297-b25041a10c74 CN=Schema,CN=Configuration,DC=MYDOM,DC=COM
repadmin /removelingeringobjects DC1 224d1971-a0ed-4915-a297-b25041a10c74 DC=ForestDNSZones,DC=MYDOM,DC=COM
repadmin /removelingeringobjects DC1 224d1971-a0ed-4915-a297-b25041a10c74 DC=DomainDNSZones,DC=MYDOM,DC=COM

теперь берем «образец» для DC1 с DC3:
repadmin /removelingeringobjects DC1 3303F24A-14FC-44A3-A120-C810E1017053 DC=MYDOM,DC=COM /advisory_mode
repadmin /removelingeringobjects DC1 3303F24A-14FC-44A3-A120-C810E1017053 CN=Configuration,DC=MYDOM,DC=COM /advisory_mode
repadmin /removelingeringobjects DC1 3303F24A-14FC-44A3-A120-C810E1017053 CN=Schema,CN=Configuration,DC=MYDOM,DC=COM /advisory_mode
repadmin /removelingeringobjects DC1 3303F24A-14FC-44A3-A120-C810E1017053 CN=Schema,CN=Configuration,DC=MYDOM,DC=COM /advisory_mode
repadmin /removelingeringobjects DC1 3303F24A-14FC-44A3-A120-C810E1017053 DC=ForestDNSZones,DC=MYDOM,DC=COM /advisory_mode
repadmin /removelingeringobjects DC1 3303F24A-14FC-44A3-A120-C810E1017053 DC=DomainDNSZones,DC=MYDOM,DC=COM /advisory_mode

точно так же проверяем и выполняем те же команды, но уже без advisory_mode.

DC1 «очищен». Теперь так же «чистим» DC2 и DC3, но уже в качестве «образца» выступает DC1.
Для этого логинимся на DC2 (а потом на DC3) и выполняем:
Сначала с advisory_mode:
repadmin /removelingeringobjects DC2 114d1971-a0ed-4915-a297-b25041a10c74 DC=MYDOM,DC=COM /advisory_mode
repadmin /removelingeringobjects DC2 114d1971-a0ed-4915-a297-b25041a10c74 CN=Configuration,DC=MYDOM,DC=COM /advisory_mode
repadmin /removelingeringobjects DC2 114d1971-a0ed-4915-a297-b25041a10c74 CN=Schema,CN=Configuration,DC=MYDOM,DC=COM /advisory_mode
repadmin /removelingeringobjects DC2 114d1971-a0ed-4915-a297-b25041a10c74 CN=Schema,CN=Configuration,DC=MYDOM,DC=COM /advisory_mode
repadmin /removelingeringobjects DC2 114d1971-a0ed-4915-a297-b25041a10c74 DC=ForestDNSZones,DC=MYDOM,DC=COM /advisory_mode
repadmin /removelingeringobjects DC2 114d1971-a0ed-4915-a297-b25041a10c74 DC=DomainDNSZones,DC=MYDOM,DC=COM /advisory_mode

А потом то же самое без advisory_mode.

И то же самое повторяем для DC3: логинимся на него, запускаем эти команды с advisory_mode, смотрим логи, а потом запускаем без advisory_mode.

3. Разрешить/запретить репликацию с серверами, которых давно не было в сети

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

Содержимое REG файла:

После запуска разрешена синхронизация между контроллерами домена. Чтобы проверить, что контроллеры синхронизираются, необходимо на одном из них открыть: «Active Directory Sites and Services» -> Sites -> Default-First-Site-Name -> Servers Теперь по очереди открываем КАЖДЫЙ контроллер домена, у него — NTDS Settings, после чего кликаем правой кнопкой на имени контроллера домена (внутри NTDS Settings) и выбираем Replicate Now. Все должно синхронизироваться.

Теперь удаляем ключи из реестра (на всех контроллерах домена!):

Репликация в Active Directory

Планирование стратегии репликации

Репликация Active Directory — жизненно важная операция, которую необходимо тщательно планировать. Правильно спланированная репликация ускоряет ответ каталога, уменьшает сетевой трафик по WAN -каналам и сокращает административные издержки.

В Windows Server 2003 используется модель репликации с несколькими хозяевами, при которой на всех контроллерах домена хранятся равноправные копии БД Active Directory . Когда создается, удаляется или переносится объект либо изменяются его атрибуты на любом контроллере домена, эти изменения реплицируются на остальные контроллеры домена.

Внутрисайтовая (между контроллерами домена одного сайта) и межсайтовая репликация (между контроллерами домена, относящимися к разным сайтам) выполняется по -разному [ 3 ] , [ 4 ] .

Репликация внутри сайта

В пределах сайта Active Directory автоматически создает топологию репликации между контроллерами одного домена с использованием кольцевой структуры. Топология определяет путь передачи обновлений каталога между контроллерами домена до тех пор, пока обновления не будут переданы на все контроллеры домена.

Кольцевая структура обеспечивает существование минимум двух путей репликации от одного контроллера домена до другого, и если один контроллер домена временно становится недоступен, то репликация на остальные контроллеры домена все равно продолжится.

При внутрисайтовой репликации трафик репликации передается в несжатом формате. Это объясняется тем, что контроллеры домена, принадлежащие одному сайту, как предполагается, связаны каналами с высокой пропускной способностью. Помимо того, что данные не сжимаются, используется механизм репликации, основанный на уведомлении об изменениях. Значит, если в данные домена вносятся изменения, эти изменения быстро реплицируются на все контроллеры домена.

Репликация между сайтами

Для обеспечения репликации между узлами нужно представить сетевые соединения в виде связей сайтов. Active Directory использует информацию о сетевых соединениях для создания объектов-соединений, что обеспечивает эффективную репликацию и отказоустойчивость.

Необходимо предоставить информацию о применяемом для репликации протоколе, стоимости связи сайтов , о времени доступности связи и о том, как часто она будет использоваться. Исходя из этого Active Directory определит, как связать сайты для репликации.

При межсайтовой репликации все данные передаются в сжатом виде. Причина в том, что трафик, вероятно, передается по более медленным WAN-каналам (см. рис. 10.1) в сравнении с соединениями локальной сети, используемыми при внутрисайтовой репликации.

Однако при этом увеличивается нагрузка на серверы, поскольку, помимо прочих операций по обработке, им приходится упаковывать/распаковывать данные. Кроме того, репликация выполняется по расписанию в момент времени, лучше всего подходящий для данной организации.

Виды реплицируемой информации

Хранимая в каталоге информация делится на три категории, которые называются разделами каталога. Раздел каталога служит объектом репликации. В каждом каталоге содержится следующая информация [ 4 ] :

• информация о схеме — определяет, какие объекты разрешается создавать в каталоге и какие у них могут быть атрибуты;
• информация о конфигурации — описывает логическую структуру развернутой сети, например структуру домена или топологию репликации. Эта информация является общей для всех доменов в дереве или лесе;
• данные домена — описывают все объекты в домене . Эти данные относятся только к одному определенному домену , подмножество свойств всех объектов во всех доменах хранится в глобальном каталоге для поиска информации в дереве доменов или лесе.

Схема и конфигурация реплицируются на все контроллеры домена в дереве или лесе.

Все данные определенного домена реплицируются на каждый контроллер именно этого домена . Все объекты каждого домена , а также часть свойств всех объектов в лесе реплицируются в глобальный каталог.

Контроллер домена хранит и реплицирует [ 4 ] :

• информацию о схеме дерева доменов или леса;
• информацию о конфигурации всех доменов в дереве или лесе;
• все объекты и их свойства для своего домена. Эти данные реплицируются на все дополнительные контроллеры в домене, часть всех свойств объектов домена реплицируется в глобальный каталог для организации поиска информации.

Глобальный каталог хранит и реплицирует:

• информацию о схеме в лесе;
• информацию о конфигурации всех доменов в лесе;
• часть свойств всех объектов каталога в лесе (реплицируется только между серверами глобального каталога );
• все объекты каталога и все их свойства для того домена, в котором расположен глобальный каталог.

Протоколы репликации

Удаленные вызовы процедур выполняются при отправке сообщений репликации внутри сайта и между сайтами. Протокол RPC используется по умолчанию при всех операциях репликации Active Directory, поскольку является отраслевым стандартом и совместим с большинством типов сетей [ 3 ] .

Обмен данными из каталога производится с помощью разных сетевых протоколов, таких как IP или SMTP [ 4 ] :