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

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

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

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

Вопрос

Возникла проблема с репликацией между контроллерами домена.

Есть два контроллера домена: dcprimary и dcreserve. И один домен intersoleast.pro. Оба КД крутятся на виртуальных машинах Windows Server 2012.

dcreserve настраивал следующим образом:

1. установил роль AD

2. поднял уровень до КД

3. указал, что устанавливаем в существующий лес новый контроллер

4. ввел учетные данные пользователя, состоящего в группе Администраторы Домена

5. sysvol располагается по умолчанию

6. для репликации выбрал КД dcprimary

Все установилось без проблем.

Репликация DNS прошла. При создании объекта на любом из КД, он появляется на другом.

Однако если выключить dcprimary, то при попытке открыть оснастки AD на dcreserve появляется ошибка:

«Не удалось найти сведения об именах по следующей причине:

Указанный домен не существует или к нему невозможно подключиться.»

Из ошибок на dcprimary:

1. Предупреждение 2092 Этот сервер является владельцем роли FSMO, но не считает ее действительной. Для раздела, содержащего FSMO, этот сервер не выполнил успешной репликации ни с одним из партнеров репликации с момента своего перезапуска. Ошибки репликации мешают выполнению проверки этой роли.

2. Предупреждение 2213 Служба репликации DFS остановила репликацию на томе C:. Это происходит, если рабата базы данных DFSR JET была завершена с ошибками, а автоматическое восстановление отключено. Чтобы устранить эту проблему, заархивируйте файлы в соответствующих реплицированных папках, а затем возобновите репликацию с помощью метода WMI ResumeReplication.

3. Ошибка 1202 На данном компьютере теперь расположен указанный экземпляр Active Directory, но веб-службам Active Directory не удалось обработать его запросы. Веб-службы Active Directory будут периодически пытаться повторить эту операцию.

1. Ошибка 1054 Ошибка при обработке групповой политики. Windows не удалось получить имя контроллера домена. Возможная причина: ошибка разрешения имен. Проверьте, что служба DNS настроена и работает правильно.

Подскажите, пожалуйста, как это можно исправить, у меня идеи закончились 🙁

• Перемещено Elina Lebedeva Moderator 19 июля 2013 г. 7:04 Windows Server 2012

Ответы

Возьмите GUID из события 2213 для тома C, и выполните из командной строки с повышенными привилегиями:

wmic /namespace:\rootmicrosoftdfs path dfsrVolumeConfig where volumeGuid=» » call ResumeReplication — в качестве подставьте значение из события.

• Предложено в качестве ответа Dmitriy Razbornov 11 августа 2013 г. 14:11
• Помечено в качестве ответа Иван Проданов Microsoft contingent staff, Moderator 11 октября 2013 г. 4:59

Все ответы

repadmin /showreps на dcprimary

C:UsersАдминистратор>repadmin /showreps
Default-First-Site-NameDCPRIMARY
Параметры DSA: IS_GC
Параметры сайта: (none)
DSA — GUID объекта: b4475690-4d9f-48d4-814e-59751f2a633c
DSA — код вызова: 5ee6d820-392f-451d-bb72-86104cfd9cae

DC=intersoleast,DC=pro
Default-First-Site-NameDCRESERVE через RPC
DSA — GUID объекта: e72c9ef2-569c-47fc-a3e1-7395ba1b04b9
Последняя попытка @ 2013-07-18 18:58:33 успешна.

CN=Configuration,DC=intersoleast,DC=pro
Default-First-Site-NameDCRESERVE через RPC
DSA — GUID объекта: e72c9ef2-569c-47fc-a3e1-7395ba1b04b9
Последняя попытка @ 2013-07-18 18:58:33 успешна.

CN=Schema,CN=Configuration,DC=intersoleast,DC=pro
Default-First-Site-NameDCRESERVE через RPC
DSA — GUID объекта: e72c9ef2-569c-47fc-a3e1-7395ba1b04b9
Последняя попытка @ 2013-07-18 18:58:33 успешна.

DC=DomainDnsZones,DC=intersoleast,DC=pro
Default-First-Site-NameDCRESERVE через RPC
DSA — GUID объекта: e72c9ef2-569c-47fc-a3e1-7395ba1b04b9
Последняя попытка @ 2013-07-18 18:58:33 успешна.

DC=ForestDnsZones,DC=intersoleast,DC=pro
Default-First-Site-NameDCRESERVE через RPC
DSA — GUID объекта: e72c9ef2-569c-47fc-a3e1-7395ba1b04b9
Последняя попытка @ 2013-07-18 18:58:33 успешна.

repadmin /showreps на dcreserve

C:Usersserveradmin>repadmin /showreps
Default-First-Site-NameDCRESERVE
Параметры DSA: IS_GC
Параметры сайта: (none)
DSA — GUID объекта: e72c9ef2-569c-47fc-a3e1-7395ba1b04b9
DSA — код вызова: ef157281-9424-42b1-8fee-655cf71cee68

DC=intersoleast,DC=pro
Default-First-Site-NameDCPRIMARY через RPC
DSA — GUID объекта: b4475690-4d9f-48d4-814e-59751f2a633c
Последняя попытка @ 2013-07-18 19:50:48 успешна.

CN=Configuration,DC=intersoleast,DC=pro
Default-First-Site-NameDCPRIMARY через RPC
DSA — GUID объекта: b4475690-4d9f-48d4-814e-59751f2a633c
Последняя попытка @ 2013-07-18 18:54:11 успешна.

CN=Schema,CN=Configuration,DC=intersoleast,DC=pro
Default-First-Site-NameDCPRIMARY через RPC
DSA — GUID объекта: b4475690-4d9f-48d4-814e-59751f2a633c
Последняя попытка @ 2013-07-18 18:54:11 успешна.

DC=DomainDnsZones,DC=intersoleast,DC=pro
Default-First-Site-NameDCPRIMARY через RPC
DSA — GUID объекта: b4475690-4d9f-48d4-814e-59751f2a633c
Последняя попытка @ 2013-07-18 18:54:11 успешна.

DC=ForestDnsZones,DC=intersoleast,DC=pro
Default-First-Site-NameDCPRIMARY через RPC
DSA — GUID объекта: b4475690-4d9f-48d4-814e-59751f2a633c
Последняя попытка @ 2013-07-18 18:54:12 успешна.
Процесс DsReplicaGetInfo() завершился ошибкой с кодом состояния 8453 (0x2105):
Доступ к репликации отвергнут.
Процесс DsReplicaGetInfo() завершился ошибкой с кодом состояния 8453 (0x2105):
Доступ к репликации отвергнут.

• Изменено Socialist Administrator 18 июля 2013 г. 15:54 опечатка

Возьмите GUID из события 2213 для тома C, и выполните из командной строки с повышенными привилегиями:

wmic /namespace:\rootmicrosoftdfs path dfsrVolumeConfig where volumeGuid=» » call ResumeReplication — в качестве подставьте значение из события.

• Предложено в качестве ответа Dmitriy Razbornov 11 августа 2013 г. 14:11
• Помечено в качестве ответа Иван Проданов Microsoft contingent staff, Moderator 11 октября 2013 г. 4:59

Возьмите GUID из события 2213 для тома C, и выполните из командной строки с повышенными привилегиями:

wmic /namespace:\rootmicrosoftdfs path dfsrVolumeConfig where volumeGuid=» » call ResumeReplication — в качестве подставьте значение из события.

Дима, реально пора собирать воркшоп «AD for dummies». Очень много однотипных проблем от непонимания базовых механизмов работы AD — уже утомляет.

Active Directory? Ask me how.

Ошибки на обоих КД, кажется, удалось победить.

Теперь все уперлось в репликацию.

При отключении dcprimary второй КД все так же не может работать с оснастками АД.

dcprimary

C:UsersАдминистратор>repadmin /syncall /aes
СООБЩЕНИЕ ОБРАТНОГО ВЫЗОВА: Сейчас выполняется следующая репликация:
От: e72c9ef2-569c-47fc-a3e1-7395ba1b04b9._msdcs.intersoleast.pro
Кому: b4475690-4d9f-48d4-814e-59751f2a633c._msdcs.intersoleast.pro
СООБЩЕНИЕ ОБРАТНОГО ВЫЗОВА: Репликация остановлена по запросу пользователя:
От: e72c9ef2-569c-47fc-a3e1-7395ba1b04b9._msdcs.intersoleast.pro
Кому: b4475690-4d9f-48d4-814e-59751f2a633c._msdcs.intersoleast.pro
СООБЩЕНИЕ ОБРАТНОГО ВЫЗОВА: Завершена операция SyncAll.

Функция SyncAll сообщает о следующих ошибках:
Репликация остановлена по запросу пользователя:
От: e72c9ef2-569c-47fc-a3e1-7395ba1b04b9._msdcs.intersoleast.pro
Кому: b4475690-4d9f-48d4-814e-59751f2a633c._msdcs.intersoleast.pro

dcreserve

C:Windowssystem32>repadmin /syncall /aes
СООБЩЕНИЕ ОБРАТНОГО ВЫЗОВА: Сейчас выполняется следующая репликация:
От: b4475690-4d9f-48d4-814e-59751f2a633c._msdcs.intersoleast.pro
Кому: e72c9ef2-569c-47fc-a3e1-7395ba1b04b9._msdcs.intersoleast.pro
СООБЩЕНИЕ ОБРАТНОГО ВЫЗОВА: Репликация остановлена по запросу пользователя:
От: b4475690-4d9f-48d4-814e-59751f2a633c._msdcs.intersoleast.pro
Кому: e72c9ef2-569c-47fc-a3e1-7395ba1b04b9._msdcs.intersoleast.pro
СООБЩЕНИЕ ОБРАТНОГО ВЫЗОВА: Завершена операция SyncAll.

Функция SyncAll сообщает о следующих ошибках:
Репликация остановлена по запросу пользователя:
От: b4475690-4d9f-48d4-814e-59751f2a633c._msdcs.intersoleast.pro
Кому: e72c9ef2-569c-47fc-a3e1-7395ba1b04b9._msdcs.intersoleast.pro

NTDS вроде реплицировался без проблем, а вот SYSVOL на dcreserve пустой(только папки, без содержания).

И еще вопрос. В настройках сети на втором КД в качестве DNS основным должен быть указан 127.0.0.1 а альтернативным ip первого КД, верно?

DFSR репликация Domain System Volume между DC – диагностика и восстановление

Поучительная история о том, как не надо удалять контроллеры из домена и как чинить упавшую репликацию между контроллерами.

Итак, смеркалось… Ко мне обратился коллега с просьбой помочь разобраться в странной, необъяснимой ™ проблеме: между DC выделенной инфраструктуры ВНЕЗАПНО не реплицируются шары Netlogon и Sysvol. При этом, разумеется, «никто ничего не трогал» (с), однако какое-то время назад из этого домена был удален контроллер OLDDC со всеми FSMO ролями, каковые роли, со слов коллеги, были перед этим корректно перенесены на один из оставшихся в строю контроллеров DC1 (все имена действующих героев серверов и доменов изменены на произвольные).

Путем беглого просмотра логов на одном из пострадавших контроллеров были довольно быстро выловлены три ключевые ошибки:

1058 — The processing of Group Policy failed.
1014 — Name resolution for the name _ldap._tcp.DC1. timed out after none of the configured DNS servers responded.
9033 — The DFS Replication service is stopping communication with partner DC1 for replication group Domain System Volume due to an error. The service will retry the connection periodically.

Далее – наш любимый dcdiag, который в числе прочего мусора выдал крайне примечательную вещь:

TEST: Delegations (Del)
Delegation information for the zone: domain.ru.
Delegated domain name: _msdcs.domain.ru .
Error: DNS server: OLDDC.domain.ru .

IP: [ Missing glue A record ]

[Error details: 9714 (Type: Win32 — Description: DNS name does not exist .)]

Все чудесатее и чудесатее. Чешем репу, открываем консоль DNS и проверяем NS записи в зоне _msdcs.domain.ru. Вроде все на месте и все указывают на боевые домен-контроллеры. А вот в зоне domain.ru для зоны-заглушки _msdcs.domain.ru как раз и обнаружилась NS запись с указанием старого OLDDC, причем она же – единственная.

Правим запись, делаем принудительную репликацию AD, рестартуем службу DFSR на контроллерах. В логах наблюдаем:

5004 — The DFS Replication service successfully established an inbound connection with partner DC1 for replication group Domain System Volume.

Все? Как бы не так: репликация по-прежнему не работает. Курим лог дальше. Обнаруживаем вот это:

4614 — The DFS Replication service initialized SYSVOL at local path C:WindowsSYSVOLdomain and is waiting to perform initial replication.

Initial replication, как несложно догадаться, так и не проходит. Мораль – надо восстанавливать хирургическими методами. Пробуем обойтись малой кровью, не трогая PDC: выполняем процедуру non-authoritative synchronization на подчиненном контроллере – не помогает. Тут уж иного выхода, кроме как authoritative synchronization, нет. Сам механизм пошагово описан в приведенной статье KB, повторять его не вижу смысла, однако хотел бы заострить внимание на некоторых моментах:

1. Перед началом процедуры крайне желательно сделать полный бэкап папки C:WindowsSYSVOLdomain (а в случае, если при установке DC дефолтные пути менялись – той папки, которая была прописана при установке роли ADDS).
2. Никаких изменений в GPO во время процедуры проводиться не должно.
3. После выполнения authoritative synchronization на основном DC, необходимо выполнить non-authoritative synchronization на всех подчиненных. При этом перед началом данной процедуры рекомендуется очистить на них папки C:WindowsSYSVOLdomainPolicies и C:WindowsSYSVOLdomainscripts, предварительно на всякий случай тоже забэкапив их.
4. Если на каком-то из DC не находится утилита dfsrdiag – ставим фичу DFS Management Tools из ветки Remote Server Administration Tools.

Если все сделано правильно, то в конце на каждом DC мы получим такое сообщение в логе:

4604 — The DFS Replication service successfully initialized the SYSVOL replicated folder at local path C:WindowsSYSVOLdomain.

А мораль сей басни такова: при удалении DC из домена, тем более при переносе с него ролей FSMO, будет далеко не лишним пройтись по консолям DNS и Sites and Services в поисках оставшихся от него «хвостов». В данном случае это не было сделано и могло бы привести к печальным последствиям, поскольку отсутствие репликации между контроллерами означает, в том числе, и рассинхронизацию GPO.

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

Сообщения: 360
Благодарности: 12

Профиль | Отправить PM | Цитировать

Сообщения: 4677
Благодарности: 1090

——-
в личке я не консультирую и не отвечаю на профессиональные вопросы. для этого есть форум.

Если же вы забыли свой пароль на форуме, то воспользуйтесь данной ссылкой для восстановления пароля.

Сообщения: 360
Благодарности: 12

Сообщения: 4677
Благодарности: 1090

——-
в личке я не консультирую и не отвечаю на профессиональные вопросы. для этого есть форум.

Сообщения: 360
Благодарности: 12

Сообщения: 4677
Благодарности: 1090

——-
в личке я не консультирую и не отвечаю на профессиональные вопросы. для этого есть форум.

Сообщения: 25778
Благодарности: 7508

Сообщения: 360
Благодарности: 12

cameron, Iska, если на КД (на котором была создана организационная единица) через ADUC подключиться к другому КД (на который нужно синхронизировать) или на КД (на который нужно синхронизировать) подключиться к КД (на котором была создана организационная единица), то организационная единица синхронизируется мгновенно.

Но все таки почему она не синхронизируется без подключения через ADUC к другому КД? Выставление расписания синронизации на четыре раза в час не помогает. Принудительная синхронизация тоже не помогает.

Сообщения: 4677
Благодарности: 1090

——-
в личке я не консультирую и не отвечаю на профессиональные вопросы. для этого есть форум.

Сообщения: 360
Благодарности: 12

cameron, есть на виртульных машинах два контроллера домена на Windows 2012 R2 Standard. Теперь опишу пошагово действия:
1. Создаю на КД1 организационную единицу.
2. На КД2 эта организационная единица не появляется ни через час ни через сутки.
3. КД2 уходит в принудительный lock. Вхожу заново; нет этой организационной единицы.
4. Все через тот же ADSS добираюсь до Replicate Now; организационной единицы как не было так и нет.
5. Выхожу из системы и повторно вхожу (как альтернатива перегружаю КД2) и только после этого появляется та самая организационная единица, которая сутки назад была создана на соседнем КД1.

Вот так и выяснил. Ну я честное не знаю как еще это можно было заметить или не заметить.

Как я уже писал пробовал и repadmin /syncall и также не помогало. Вдобавок к выходу/входу из системы и перезагрузке КД, смена КД в ADUC оказалось тоже помогает реплицировать организационные единицы. Но ведь так быть не должно я полагаю.