Tw-city.info

IT Новости
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Репликация между доменами

Репликация в 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 ] :

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

Утилита 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:

Читать еще:  Альбомная страница в word

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 — сайты и службы» для настройки параметра частоты в свойствах объекта связи сайтов. Через указанный интервал (например через каждые 60 минут) контроллер домена, выполняющий роль сервера-плацдарма в сайте, запрашивает изменения у исходного партнера репликации, находящегося в другом сайте.

Минимальным требованием для выполнения этой процедуры является членство в группе Администраторы предприятия в лесу или в группе Администраторы домена в корневом домене леса или наличие эквивалентных прав. Подробные сведения об использовании соответствующих учетных записей и членства в группах см. на странице https://go.microsoft.com/fwlink/?LinkId=83477 .

Откройте оснастку «Active Directory — сайты и службы». Чтобы открыть оснастку «Active Directory — сайты и службы», нажмите кнопку Пуск, выберите пункт Администрирование, а затем щелкните Active Directory — сайты и службы.

В дереве консоли щелкните папку межсайтового транспорта, где содержится связь сайтов, для которой следует настроить возможность межсайтовой репликации.

    Active Directory — сайты и службыСайтыМежсайтовый транспортIP или SMTP

В области сведений щелкните правой кнопкой мыши связь сайтов, для которой следует настроить расписание, и выберите Свойства.

В поле Реплицировать каждые введите или выберите количество минут между сеансами репликации.

Используйте межсайтовый транспорт по протоколу IP, если только в сети нет удаленных сайтов, сетевое подключение к которым не является постоянным, или если нет отсутствующих подключений по протоколу IP. Репликация по протоколу SMTP имеет ряд ограничений по сравнению с репликацией по протоколу IP. Дополнительные сведения об использовании транспорта SMTP см. в разделе Общее представление о межсайтовой репликации.

Дополнительные сведения

  • Для выполнения этой процедуры необходимо входить в группу «Администраторы домена» в корневом домене леса или в группу «Администраторы предприятия» в данном лесу либо получить соответствующие разрешения через делегирование. По соображениям безопасности для выполнения этой процедуры рекомендуется использовать команду От имени администратора. Войдите в систему, используя учетную запись самого низкого уровня, и укажите административные учетные данные при управлении доменными службами Active Directory.

Читать еще:  Корневой домен это

Частота репликации связи сайтов по умолчанию равна 180 минутам.

Значение Реплицировать каждые будет воспринято как ближайшее значение, кратное 15 минутам, в диапазоне от минимального значения, равного 15 минутам, до максимального значения, равного 10 080 минутам (1 неделя).

Self Engineering

Путь саморазвития ИТ инженера

Сетевые сервисы Windows 2012 — репликация Active Directory

Наконец-то собрался переписать свои заметки по теме из черновика в тетрадке в электронный формат. Изложить постарался максимально кратко и ёмко.

  1. Основные сведения
  2. Механизмы репликации
    • 2.1 Внутрисайтовая репликация
    • 2.2 Межсайтовая репликация
  3. Диагностика репликации

1. Основные сведения

Все данные Active Directory хранятся в специализированной базе данных на движке ESENT. Физически она представляет собой файл NTDS.DIT. Все изменения в AD производятся на конкретном контроллере домена и вносятся в его NTDS.DIT и лишь потом эти изменения передаются на остальные контроллеры домена.

Логически база данных состоит из четырёх разделов:

Schema — содержит описания объектов и их атрибутов, которые могут быть созданы в AD. Меняется редко — при процедуре расширения схемы, которая производится, например, при установке MS Exchange или при апгрейде ОС контроллеров домена. Расширение схемы необратимо, его нельзя откатить никак, кроме способа восстановления всех DC, успевших реплицировать данные, из бэкапа. Репликацию данного раздела может инициировать только контроллер домена, имеющий роль Schema master. Реплицируется на все контроллеры леса.

Configuration — содержит сведения о конфигурации AD (сколько доменов, сайтов, сайтлинков и т.д.). Инициатором репликации может выступать любой DC. Реплицируется на все контроллеры леса.

Domain — содержит учётные записи (пользователей, группы, компьютеры, принтеры…). Инициатором выступает любой DC. Реплицируется на все контроллеры домена.

Application — раздел для хранения данных какими-то приложениями, не относящимися к AD непосредственно. В частности, если вы выбрали в настройках DNS-зоны «интегрированная в AD», то она хранится здесь. Репликация зависит от настройки.

Репликация между контроллерами происходит не абы как и не по принципу «каждый с каждым», а на основе репликационных связей. За их создание отвечает сервис KCC (Knowledge Consistency Checker). Он стартует на каждом контроллере домена раз в 15 минут и добавляет или удаляет необходимые связи. Так что нет ничего страшного, если сразу после установки нового DC в сети, он ещё не числится ничьим партнёром репликации. Посмотреть и настроить связи можно в оснастке Active Directory Sites and Services.

Связи создаются сервисом KCC на основании правила «трёх прыжков» — то есть, чтобы от одного контроллера домена до любого другого было не более трёх переходов или двух посредников.

Следует иметь ввиду, что связи, созданные вручную, сервисом KCC не управляются, то есть восстанавливать им замену, в случае недоступности одного из партнёров по репликации, сервис не будет.

Можно не ждать 15 минут, и инициировать создание связей силами KCC принудительно:

repadmin /kcc — принудительное создание связи для

repadmin /kccsite — принудительное создание связей для всех DC в сайте

repadmin /kcc * — запустить процесс на всех контроллерах доменов в лесу.
2. Механизмы репликации

На каждом контроллере домена ведётся учёт количества изменений с помощью счётчика highestCommittedUSN. Создание/изменение объекта включает в себя создание/изменение нескольких атрибутов, каждое из которых увеличивает highestCommittedUSN на 1. Каждый атрибут, помимо прочих, имеет параметры:

Org.USN — значение счётчика highestCommittedUSN автора изменений (контроллера домена, на котором они производились) на момент изменения.

Loc.USN — значение счётчика highestCommittedUSN текущего контроллера домена (принимающего изменённые данные в ходе репликации).

Посмотреть атрибуты и значения их параметров объекта можно командой repadmin /showmeta. Например:

repadmin /showmeta «CN=User1,OU=TestOU,DC=contoso,DC=com»

В ходе репликации, контроллер домена кэширует значения highestCommittedUSN своих партнёров. При следующем сеансе он сравнивает закэшированное значение с текущим. Если новое значение больше предыдущего, целевой контроллер принимает решение стянуть изменения. Для этого исходный контроллер делает выборку объектов и атрибутов, у которыех Loc.USN больше, чем последний highestCommittedUSN.

В случае конфликтов:

  • сравнивается параметр Ver конфликтного атрибута. Чей выше, тот и прав.
  • если Ver равны, сравнивается время изменения. Чьё позже, тот и прав.
  • если и время равно, то прав будет контроллер домена с большим GUID.
  • В случае, если на двух контроллерах одновременно создали учётную запись с одинаковым именем, более ранняя будет переименована (старое имя+GUID контроллера)
  • В случае, если на одном контроллере в какой-то OU создаётся объекта, а на другом в это же время удаляется OU, объект, в ходе репликации, будет перенесён в служебный контейнер «Lost and Found«

Репликация всегда происходит в режиме Pull (вытягивание), поскольку каждый контроллер единолично отвечает за целостность своей базы данных.

Принудительный запуск репликации:

repadmin /syncall — синхронизация указанного сервера со всеми партнёрами по репликации.
2.1 Внутрисайтовая репликация

Через 15 секунд после внесения изменений, контроллер домена оповещает своих партнёров о необходимости репликации. Если партнёров несколько, то каждому следующему оповещение отправляется с 3-секундной задержкой.

repadmin /notifyopt — настройка таймингов оповещений.

Изменение пароля пользователя и блокировка учётной записи инициируют репликацию без 15-секундной задержки.

Кроме того, репликация происходит по расписанию каждый час. На случай, если во время инициирования репликации по изменению, целевой контроллер был недоступен или был занят дефрагментацией базы.
2.2 Межсайтовая репликация

Для репликации между сайтами создаются связи сайтов (Site Link), в которых задаётся расписание («окно» в течение которого возможна репликация и периодичность), используемый протокол (SMTP или IP) и стоимость (Cost). По умолчанию создана DEFAULTIPSITELINK с использованием IP и репликацией раз в 180 минут. Посмотреть связи или создать новые можно в оснастке Active Directory Sites and Services.

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

За репликацию между сайтами отвечают не все подряд контроллеры доменов, а в каждом сайте выбирается специально обученный — Bridgehead (сервер плацдармов). То есть именно он занимается репликацией изменений данного сайта с аналогичным bridgehead’ом другого сайта. Как и в случае с репликационными связями между контроллерами доменов, за выбор сервера-плацдарма отвечает служба KCC. Точно также эта служба не работает с назначенными вручную Bridgehead’ами и если таковой выйдет из строя, репликация скорее всего будет невозможна (если не был также вручную назначен ещё один-несколько).

Читать еще:  Работа в домене что это

repadmin /bridgeheads — посмотреть текущие серверы плацдармов.

Стоит также упомянуть тут такое явление, как Site Link Bridging — связь между Site1 и Site3 через сеть Site2, но минуя контроллеры домена, расположенные в Site2. То есть используя только маршрутизируемую сеть. Это при условии, что между Site1 и Site3 прямой связи нет, а контроллеры домена в Site2 по какой-то причине оказались недоступны.

Такой бриджинг настраивается также автоматически пресловутой службой KCC. Можно отключить (галочка в свойствах протокола-транспорта в оснастке Active Directory Sites and Services). К сожалению, автоматизация включается/отключается только полностью для всех сайтов. Однако, можно создать вручную только для нужных, предварительно отключив автоматику.

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

На картинке вначале статьи можно увидеть два таких моста — от DC3 к DC2 и от DC8 к DC1.
3. Диагностика репликации

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

В качестве отправной точки для диагностики, неплохой идеей будет использовать анализ логов Directory Services на проблемном контроллере домена.

Также поможет dcdiag /test:connectivity, а ещё nslookup, как средство проверки правильной работы DNS.

Ну и конечно repadmin. Часть его ключей описана выше, ещё часть можно увидеть в справке (repadmin /?), а кое-что — в расширенной справке (repadmin /? /experthelp).

Опыт восстановления контроллера домена Active Directory


В один не очень замечательный день перестал отвечать на запросы сервер контроллера домена Active Directory. Второй контроллер домена тоже оказался неработоспособным. Оба они находились в синем экране смерти с кодом 0xc0002e2. Пришлось проводить восстановление Active Directory.

@duzlov (Дмитрий Узлов) и @sergey_algin (Сергей Альгин) запаслись крепким кофе и начали работу.

Использование ntdsutil для тестирования базы данных Active Directory

Перезагрузка серверов в разных режимах не помогла. Причем один из серверов при загрузке выдавал огромное количество предупреждений и ошибок про контроллер дисков. Вскрытие сервера показало, что вышла из строя батарея raid-контроллера. Похоже, что это и послужило причиной сбоя сервера.

Я перегрузил сервер в режиме восстановления служб Active Directory (Directory Service Restore Mode (DSRM)).

Сделал копии всех файлов, находящихся в каталогах c:windowsNTDS; c:windowsSYSVOL.

В командной строке запустил утилиту ntdsutil, служащую для работы с базой данных ntds.dit:

В командной строке ntdsutil необходимо активировать базу данных Active Directory:

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

База данных рассыпалась, виноват сбой в контроллере дисков:

Повреждения базы данных Active Directory (фото из Интернет)

На втором сервере ситуация была схожей. Было решено восстановить сервер из резервной копии.

После восстановления сервера из резервной копии казалось, что все проблемы разрешатся, но этого не случилось.

Сервер уходил в бесконечную перезагрузку. Зато база данных ntds.dit, журналы, SYSVOL были в надлежащем состоянии.

К сожалению, все попытки восстановить работоспособность сервера не привели к успеху.

После чтения документации и статей в Интернет я решил попробовать неописанный в них способ восстановления – попытку подмены файлов базы данных Active Directory, SYSVOL во вновь установленном сервере.

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

IFM (Install from Media) – метод установки дополнительного контроллера в существующий домен с использованием набора файлов. Это помогает уменьшить трафик репликации и применимо в сценариях с удаленными территориальными офисами, связанными медленными WAN-каналами.

Подробнее про IFM можно прочесть в статье technet.

В структуре IFM есть копии файлов ntds, SYSVOL и кусты реестра. Но для использования этих файлов при типовой установке требуется наличие работоспособных контроллеров домена. В нашей ситуации этот способ использовать нельзя.

Установка новой серверной операционной системы

Для подтверждения гипотезы с подменой необходимых файлов было решено установить новую операционную систему и перезаписать файлы Active Directory.

После установки системы я установил роли AD DS, DNS, DHCP. Это необходимо для того, чтобы в файловой системе уже присутствовали все необходимые бинарные компоненты для запуска служб.

Затем перегрузил сервер с внешнего носителя в Windows PE, сделал копии Windows, ProgramData, Users и начал эксперимент.

Первым делом я перезаписал в каталоги c:windows; c:windowsNTDS и c:windowsSYSVOL файлы с имеющейся копии. Удалил все файлы *.log в каталоге NTDS:

Перезагрузка сервера и снова

Вывод, что для восстановления работоспособного контроллера домена наличия NTDS и SYSVOL недостаточно. Это и так было понятно, но проверить всё-таки стоило.

Снова перезагрузка сервера в Windows PE, восстановление папок Windows, ProgramData и Users. Проверка – сервер загружается.

Вторая попытка – копирование помимо NTDS и SYSVOL ещё и ProgramData, Users и кустов реестра.

Кусты реестра находятся в папке %SystemRoot%System32Config. Скопировал все кусты реестра. Перезагрузка и снова синий экран.

В третьей попытке восстановления я решил не копировать ProgramData, Users и ограничился копированием NTDS, SYSVOL и кустов реестра SAM и SYSTEM.

Перезагрузка – УДАЧА! Сервер загрузился, в него можно было войти под доменной учётной записью, он определился как контроллер домена.

DNS был интегрирован в Active Directory, все записи DNS тоже были на месте. База DHCP не восстановилась. Но, если на клиентском компьютере установить static IP, пользователь и компьютер могут получить доступ к ресурсам.

Но внутри самого сервера были проблемы, связанные с отсутствием прав доступа к меню Пуск, контекстному меню в Проводнике. Можно было запустить командную строку и работать из неё.

Проверка целостности ntds с помощью ntdsutil показала, что всё в порядке.

Было решено заново установить серверную операционную систему и создать новый контроллер домена.

Проверка репликации базы данных показала, что не синхронизируются netlogon и sysvol. Для решения этой задачи необходимо провести процедуру полномочной синхронизации.

Полномочная синхронизация для DFSR репликации SYSVOL

Ссылка на основную публикацию
ВсеИнструменты 220 Вольт
Adblock
detector