Устранение неполадок с ошибкой репликации AD 8461

В этой статье описываются симптомы, причины и шаги разрешения для случаев задержки репликации AD и создания ошибки Win32 8461:

Операция репликации была предварительно выполнена.

Исходный номер базы знаний: 2981628

Симптомы

Ниже приведены конкретные симптомы.

• Признак 1.

  DCDIAG сообщает, что тест репликации Active Directory завершился сбоем с состоянием ошибки (8461): операция репликации была выполнена.

  Пример текста ошибки из DCDIAG выглядит следующим образом:

  Сервер тестирования: <имя контроллера домена сайта><>
  Запуск теста: репликация
  * Проверка репликации

  ПРЕДУПРЕЖДЕНИЕ О ЗАДЕРЖКЕ РЕПЛИКАЦИИ
  [Проверка репликаций,<Имя> контроллера домена] Этот путь репликации был преумножен работой с более высоким приоритетом.
  Из <исходного контроллера домена> в <целевой контроллер домена>
  Контекст именования: путь DC=<DN>
  Репликация вызвала ошибку (8461):
  Операция репликации была предварительно выполнена.
  Репликация новых изменений по этому пути будет отложена.
  Ход выполнения обычно выполняется по этому пути.

• Признак 2

  REPADMIN.EXE сообщает, что последняя попытка репликации была отложена по обычной причине, результат 8461 (0x210d).

  REPADMIN Команды, которые обычно ссылаются на состояние 8461, но не ограничиваются:

  • REPADMIN /REPLSUM
  • REPADMIN /SHOWREPL
  • REPADMIN /SHOWREPS
  • REPADMIN /SYNCALL

• Симптом 3.

  Repadmin /rehost завершается сбоем и создается код состояния 8461.

• Симптом 4.

  Repadmin /queue выходные данные показывают одну или несколько задач с состоянием PREEMPTED.

  [12142] Enqueued 2011-11-26 06:05:55 по приоритету 40
  СИНХРОНИЗАЦИЯ ИЗ ИСТОЧНИКА
  NC dc=west, dc=contoso,dc=com
  GUID GUID <объекта DSA BOulder\BoulderDC DC DSA>
  Addr transport addr <DSA.>_msdcs.contoso.com
  ASYNCHRONOUS_OPERATION NEVER_COMPLETED NEVER_NOTIFY ПРЕДВАРИТЕЛЬНО

• Симптом 5.

  Команда "реплицировать сейчас" в сайтах и службах Active Directory (DSSITE). MSC) завершается ошибкой и создает следующее сообщение об ошибке:

  Операция репликации была предварительно выполнена.

  Заголовок диалогового окна: репликация
  Текст сообщения: во время попытки синхронизации dns-имени контекста <именования секции> каталога из исходного контроллера домена контроллера <домена произошла следующая ошибка.>
  для целевого контроллера <домена:>
  Операция репликации была предварительно выполнена.

• Симптом 6.

  События в журнале событий служб каталогов ссылаются на состояние ошибки 8461.

  Источник событий и идентификатор события	Сообщение
  Репликация NTDS 1839	Следующее число операций ожидается в очереди репликации. Старейшая операция ждала с следующего времени. Время: <число> операций ожидания даты<>: <значение> этого условия может произойти, если общая рабочая нагрузка репликации на этом контроллере домена слишком велика или интервал репликации слишком мал.
  Репликация NTDS 2094	Предупреждение о производительности: репликация была отложена при применении изменений к следующему объекту. Если это сообщение часто возникает, это означает, что репликация происходит медленно, и сервер может столкнуться с трудностями при изменении.

  Источник: репликация NTDS
  Идентификатор события 1839
  Тип: предупреждение
  Описание.
  Следующее число операций ожидается
  в очереди репликации. Старейшая операция имеет
  ждал с следующего времени.
  Время:
  Количество операций ожидания:
  Это условие может произойти, если общее
  Рабочая нагрузка репликации на этом контроллере домена
  слишком большой или интервал репликации слишком мал.

  Примечание.

  Событие 1580 также регистрируется при выполнении длительных задач репликации, если подробные диагностика ведения журнала были заданы значения 0x1 или больше.

  [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\NTDS\Diagnostics] "5 событий репликации"=dword:00000001

  Источник событий и идентификатор события

  Строка события

  Репликация NTDS 1580

  Долго выполняющаяся задача репликации служб домен Active Directory входящего трафика завершена со следующими параметрами. Истекшее время (минуты): 84 Операция Синхронизация реплики Параметры: 0x21000051 Параметр 1: DC=Contoso,DC=com Параметр 2: <guid объекта объекта object object для исходных DCs ntds> Параметр 3. Параметр 4. Долго выполняющаяся задача репликации также может возникать, если система была недоступна или раздел каталога был недоступен в течение длительного периода времени. Долго выполняющаяся задача репликации может указывать на большое количество обновлений или ряд сложных обновлений, происходящих в исходной службе каталогов. Выполнение этих обновлений во время некритичного времени может предотвратить задержки репликации. Долго выполняющаяся задача репликации является нормальной в случае добавления нового раздела каталога в службы домен Active Directory. Это может произойти из-за новой установки, продвижения глобального каталога или подключения, созданного средством проверки согласованности знаний (KCC). Дополнительные данные Значение ошибки: Операция успешно завершена.

Причина

Это состояние репликации возвращается при наличии более приоритетных задач репликации в очереди входящих контроллеров домена назначения. Это не означает условие сбоя; Задача репликации не отменена, а задача помещается в шаблон удержания до завершения более высокой приоритетной работы. Обычно это сообщение периодически возвращается в больших средах, и важно отметить, что условие является временным.

Хотя эта проблема распространена и временная, некоторые другие проблемы репликации AD могут привести к невыполненной работы в очереди. Если это происходит, вы можете начать видеть задачи репликации, которые часто выполняются. Частое ведение журнала события 2094 "Предупреждение о производительности" (пример события показан в разделах "Симптомы" и "Разрешение") является еще одним признаком необходимости устранения неполадок.

Исследование этих проблем
repadmin /queue Объяснение и приоритет репликации

Анализ выходных данных очереди с течением времени, чтобы определить, обрабатываются ли задачи
Объяснение repadmin /showrepl /verbose

Репликация Active Directory была предварительно выполнена.	Ход выполнения входящего репликации был прерван запросом на репликацию с более высоким приоритетом, например запрос, созданный вручную с repadmin /sync помощью команды.	Дождитесь завершения репликации. Это информационное сообщение указывает на обычную операцию.

Загрузка репликации

• Слишком много партнеров
• Слишком частые обновления объектов и атрибутов
• Частые обновления в сочетании с уведомлением об изменениях между сайтами, что приводит к высокой частоте избыточных уведомлений об изменениях
• Небольшое окно расписания репликации

Проблема на основе производительности

• Производительность диска и памяти
• Производительность сети

Решение

Это состояние не указывает на условие сбоя. Это временная проблема во многих случаях и не требуется никаких действий по разрешению.

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

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

• Переходный режим

• Загрузка репликации

  • Согласованная загрузка
  • Временная загрузка

• Проблема с производительностью

  • Производительность ОС
  • Производительность диска
  • Производительность сети

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

Если задачи репликации помещаются в очередь. Просмотрите текущую задачу и изучите ее.

Используйте данные журнала событий, выходные данные repadmin и монитор производительности, чтобы изолировать причину проблемы. Определите скорость обработки обновлений и частоту изменений.

Загрузка репликации

Постоянно

Контроллер домена имеет слишком много партнеров репликации или слишком большой нагрузки репликации. Симптомы перегруженного контроллера домена:

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

  Примечание.

  Вы можете использовать repadmin /queue с течением времени и сопоставить их с данными о производительности, чтобы определить этот сценарий.

• Частое вхождение состояния репликации 8461

• Решение. Уменьшение входящих подключений (баланс подключений между контроллерами домена концентратора (ADLB.exe полезно здесь), добавление новых контроллеров домена и перебалансируйте подключения, разверните RODC на периферийных сайтах и уменьшите чрезмерную репликацию изменений.

Чрезмерная репликация

Атрибуты, которые часто обновляются. Определите обновления атрибутов с помощью подробных событий журнала событий репликации (или с помощью repadmin /showchanges), а затем сопоставляются с repadmin /showobjmeta несколькими объектами в целевом контроллере домена. Просмотрите атрибут, определенный в событии, и найдите высокий номер версии или получите несколько журналов для одного объекта в течение дня и проверьте, часто ли увеличивается номер версии.

Временные процедуры

• Массовые изменения редко
• После размещения секции в первый раз или во время повторного размещения

Проблема на основе производительности

Распространенные симптомы для сборки очереди, вызванной производительностью, включают

Идентификатор события 2094

Тип события: предупреждение
Источник событий: репликация NTDS
Категория событий: репликация
Идентификатор события: 2094
Описание.
Предупреждение о производительности: репликация была отложена
при применении изменений к следующему объекту. Если это
сообщение часто возникает, указывает на то, что
репликация происходит медленно, и сервер может выполняться медленно.
имеют трудности с изменениями.
Объект DN: CN=JUSTINTU,OU=Workstations,DC=contoso,DC=com
GUID объекта: <GUID>
Раздел DN: DC=contoso,DC=com
Сервер: <GUID>._msdcs.contoso.com
Истекшее время (с): 13
Действие пользователя:
Распространенной причиной этой задержки является то, что этот объект особенно велик либо в размере его значений, либо в количестве значений. Сначала следует рассмотреть возможность изменения приложения, чтобы уменьшить объем данных, хранящихся в объекте, или количество значений. Если это большая группа или список рассылки, можно рассмотреть возможность повышения версии леса до Windows Server 2003, так как это позволит более эффективно работать репликации. Следует оценить, обеспечивает ли платформа сервера достаточную производительность с точки зрения памяти и мощности обработки. Наконец, можно рассмотреть возможность настройки базы данных Active Directory, переместив базу данных и журналы в отдельные разделы диска.

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

Дополнительное ограничение предупреждения данных (с): 10 ограничение реестра: System\CurrentControlSet\Services\NTDS\Parameters\Replicator максимальное ожидание объекта обновления (с)

Определите, происходят ли изменения, применяемые к базе данных, медленно с помощью мониторинга производительности и repadmin /queue выходных данных. Сопоставляйте счетчики репликации AD с базовыми счетчиками производительности ОС (диск, память, сеть и ЦП).

DC

Диск

Сеть

Очередь содержит 55 элементов.
Текущая задача начала выполняться в DateTime>.<
Задача выполняется в течение 508 минут, 53 секунды.
[6485] Enqueued 2011-11-26 01:55:33 в приоритете 590
SYNC FROM SOURCE NC DC=corp,DC=contoso,DC=com
DC Хьюстон\5thWardDC
GUID <объекта DC>
Addr DC transport addr <GUID>._msdcs.contoso.com
FORCE
[12142] Enqueued <DateTime> с приоритетом 40
SYNC FROM SOURCE NC dc=west,dc=contoso,dc=com
DC Boulder\BoulderDC
GUID <объекта DC>
Addr DC transport addr <GUID>._msdcs.contoso.com
ASYNCHRONOUS_OPERATION NEVER_COMPLETED NEVER_NOTIFY ПРЕДВАРИТЕЛЬНО

Дополнительная информация

Устранение неполадок при медленной репликации AD

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

Терминология: медленное и скрытое

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

Наиболее вероятные причины:

• Проблемы с производительностью контроллера домена и ОС

  • Истощение ресурсов
  • Узкое место диска

• Проблемы с базой данных AD

  • Логическое или физическое повреждение
  • Проблемы с объектами или атрибутами

• Проблемы с загрузкой контроллера домена

  • Обработка слишком большого количества клиентов

  • Шторм репликации

    • Высокая скорость изменения объектов и атрибутов
    • Синхронизация полной секции

В скрытой репликации AD контроллер домена не уведомляется об изменениях в течение длительного времени:

Наиболее вероятные причины:

• Конфигурация топологии AD (расписание, ссылки сайта, расписание репликации, отключенная топология)

Эта стратегия сбора документов и данных предназначена для устранения неполадок с медленной репликацией AD.

Симптомы медленной репликации AD

Сбор данных

Данные repadmin

Используется Repadmin /queue для документирования задач репликации в очереди. Отслеживайте очередь, чтобы узнать, существует ли задержка при обработке задач репликации. Зайдите все repadmin /queue выходные данные в один текстовый файл, чтобы иметь хорошие данные журнала.

Repadmin /queue DCName >DCNameReplQueue.txt  
Choice /d y /t 300  
Repadmin /queue DCName >>DCNameReplQueue.txt  
Choice /d y /t 300  
Repadmin /queue DCName >>DCNameReplQueue.txt  
Choice /d y /t 900  
Repadmin /queue DCName >>DCNameReplQueue.txt  
Choice /d y /t 900  
Repadmin /queue DCName >>DCNameReplQueue.txt  
Choice /d y /t 1800  
Repadmin /queue DCName >>DCNameReplQueue.txt

Просмотрите выходные данные, чтобы узнать, обрабатываются ли задачи репликации своевременно. Верхняя часть файла содержит текущую задачу и время его выполнения. Если одна и та же задача всегда находится в верхней части выходных данных, можно использовать подробные выходные данные repadmin /showrepl для мониторинга хода выполнения.

Изменения repadmin

Repadmin /showrepl

Используйте Repadmin /showrepl и /verbose параметр для отслеживания состояния последней репликации и количества изменений, которые осталось реплицировать.

Repadmin /showrepl /verbose DCNameDomainDN  

Repadmin /showrepl /verbose 5thwardCorpDC dc=corp,dc=contoso,dc=com

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

Repadmin /showrepl /verbose DCNameDomainDN SourceDcDSAObjectGUID

Repadmin /showrepl /verbose 5thwardCorpDC <GUID> dc=corp,dc=contoso,dc=com

Repadmin /showutdvec

Используйте Repadmin /showutdvec в исходном и целевом контроллере домена для определения разностной репликации.

repadmin /showutdvec DCName DomainDN

repadmin /showutdvec LiverpoolDC1 dc=north,dc=fabrikam,dc=com

Получите Repadmin /showutdvec /latency из исходного и целевого контроллера домена для секции, о чем идет речь.

В выходных данных задокументируйте следующее:

1. Из исходного контроллера домена showutdvec: USN # рядом с source DCName
2. От целевых контроллеров домена showutdvec USN# рядом с SOURCE DCNanme

Исходный контроллер домена

Даллас\2008DC1 @ USN 451265 @ DateTime <>
Даллас\SourceDC @ USN 1126541 @ DateTime <>
Хьюстон\2012DC3 @ USN 469842 @ Time <DateTime>
66a1b264-80b8-44f8-8356-9ebcd7a34f15 @ USN 32811 @ Time DateTime <>
Даллас\2012DC2 @ USN 460219 @ DateTime <>
Даллас\DestinationDC @ USN 1353465 @ Time <DateTime>
Даллас\2003DC1 @ USN 15556 @ Time DateTime <>

Целевой контроллер домена

Даллас\2008DC1 @ USN 451265 @ DateTime <>
Даллас\SourceDC @ USN 801224 @ Time <DateTime>
Хьюстон\2012DC3 @ USN 469842 @ Time <DateTime>
66a1b264-80b8-44f8-8356-9ebcd7a34f15 @ USN 32811 @ Time DateTime <>
Даллас\2012DC2 @ USN 460219 @ DateTime <>
Даллас\DestinationDC @ USN 1359087 @ Time <DateTime>
Даллас\2003DC1 @ USN 15556 @ Time DateTime <>

Исходный контроллер домена

SourceDC @ USN 1126541

Целевой контроллер домена

SourceDC @ USN 801224

1126541-801224 = 325317

Целевой контроллер домена — 325 317 USN позади.

Примечание.

Вы также можете получить исходные контроллеры домена из исходного контроллера домена с помощью следующей команды:

repadmin /showattr SourceDC . /atts:highestcommittedusn DN: 1> highestCommittedUSN: 1126541

Данные о производительности

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

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

Создание определяемого пользователем набора сбора данных

1. Откройте диспетчер сервера в полной версии Windows Server 2008 или более поздней версии.
2. Разверните наборы сборщиков данных производительности > диагностики>.
3. Щелкните правой кнопкой мыши определяемый пользователем и выберите новый > набор сборщика данных.
4. Введите имя, например диагностику AD DS, и оставьте выбранный по умолчанию вариант "Создать" из шаблона (рекомендуется). Затем выберите Далее.
5. Выберите диагностику Active Directory в списке шаблонов, а затем нажмите кнопку "Далее" и следуйте инструкциям мастера (внесите необходимые изменения).
6. Щелкните правой кнопкой мыши новый набор сборщика данных, определяемого пользователем, и просмотрите свойства.
7. Чтобы изменить время выполнения, измените параметры общей длительности на вкладке "Условие остановки" и нажмите кнопку "ОК", чтобы применить изменения.

Варианты, которые следует учитывать:

• Общая длительность — можно остановить сборщик данных после сбора в течение заданного периода времени.

• Ограничения — вы можете остановить сбор данных после достижения порогового значения размера или времени (с параметром автоматического перезапуска).

  Если вы хотите ограничить размер журнала, можно использовать ограничения ограничений.

  • Перезапустите набор сборщика данных по ограничениям

  • Duration

  • Максимальный размер

    

Просмотр свойств счетчика производительности для определяемого пользователем набора сборщиков данных

1. Выберите новый набор сборщика данных, определяемого пользователем.
2. Щелкните правой кнопкой мыши счетчик производительности и выберите пункт "Свойства".

Здесь доступны параметры изменения интервала выборки и добавления или удаления дополнительных счетчиков.

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

Все рекомендуемые счетчики включены в набор сборщика диагностики AD по умолчанию с тремя исключениями:

• Database ==>Instances(lsass/NTDSA)\ *

• LogicalDisk(*)\*

  Для LogicalDisk: все экземпляры не требуются. Системный диск и диски, в которых хранятся базы данных и журналы, должны быть включены в минимальную статистику системы безопасности\*

• Статистика системы безопасности\*

Добавление счетчиков базы данных AD DS в набор определяемых пользователем данных

1. В свойствах счетчика производительности нажмите кнопку "Добавить".

2. Разверните базу данных ==>Экземпляры (все счетчики должны быть выделены).

3. В разделе "Экземпляры выбранного объекта" выберите lsass/NTDSA

4. Нажмите кнопку "Добавить" и нажмите кнопку "ОК".

   

5. Добавьте также объекты ЛогическогоDisk и системного статистики.

   

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

Когда вы будете готовы приступить к сбору данных о производительности, запустите только что определенный набор коллекций:

Чтобы запустить только что определенный набор сбора данных из MMC, выполните следующие действия.

1. В Монитор производительности mmc перейдите в раздел "Производительность", "Наборы сборщиков данных" или "Определяемый пользователем"
2. Щелкните правой кнопкой мыши новый набор средств диагностики AD DS и выберите "Пуск".
3. Вы можете убедиться, что она запущена, выбрав определяемую пользователем диагностику AD DS, должна иметь состояние "Запуск"

После завершения тестирования остановите набор диагностики AD DS:

1. В Монитор производительности mmc перейдите к разделу "Производительность" или "Наборы сборщиков данных" или "Определяемый пользователем".
2. Щелкните правой кнопкой мыши новый набор средств диагностики AD DS и выберите "Остановить". Вы можете убедиться, что он остановлен, выбрав "Определяемый пользователем".

Диагностика AD DS должна перейти от состояния "Запуск до компиляции" и, наконец, остановлена , обратите внимание, что MMC не очень хорош для обновления его представления. Таким образом, если он, кажется, застрял в выполнении или компиляции после нажатия кнопки Мыши, попробуйте обновить экран.

Скомпилированный отчет можно просмотреть в разделе "Производительность", "Отчеты", "Определяемые пользователем" или "Диагностика AD DS"

Путь по умолчанию в проводнике Windows: %systemdrive%\PerfLogs\Admin\AD DS Diagnostics

Инструкции командной строки: сбор диагностики AD из командной строки:

Чтобы запустить коллекцию данных из командной строки, выполните следующую команду из командной строки с повышенными привилегиями: logman start "user defined\AD DS Diagnostics" -ets
Чтобы остановить сбор данных до 5 минут по умолчанию, выполните следующую команду: (получите по крайней мере один полный пятиминутный пример для этой проблемы). logman stop "user defined\AD DS Diagnostics" -ets

Диагностические данные регистрируются здесь: C:\PerfLogs\Admin\AD DS Diagnostics\DateStamp

Пример скрипта сбора данных

logman start "system\Active Directory Diagnostics" -ets time /t >slow.txt  
repadmin /showrepl /verbose LiverpoolDC1 dc=north,dc=fabrikam,dc=com >slowrepl.txt  
repadmin /queue LiverpoolDC1 >>slow.txt  
repadmin /showutdvec LiverpoolDC1 dc=north,dc=fabrikam,dc=com >>slow.txt  
:start  
ping 127.0.0.1 -n 60 >NUL  
time /t >>slow.txt time /t >>slowrepl.txt  
repadmin /showrepl /verbose LiverpoolDC1 dc=north,dc=fabrikam,dc=com >>slowrepl.txt
repadmin /queue LiverpoolDC1 >>slow.txt  
repadmin /showutdvec LiverpoolDC1 dc=north,dc=fabrikam,dc=com >>slow.txt  
goto start

Данные журнала событий

Ведение журнала по умолчанию, включенное в журнале событий служб каталогов, полезно отслеживать события, указывающие на медленное применение изменений. (EVENT X) Подробное ведение журнала диагностики можно включить, чтобы узнать, какие изменения в настоящее время применяются. Включение ведения журнала диагностики на уровне, упомянутом в этой статье, приведет к тому, что журнал заполняется довольно быстро, поэтому его можно включить только при активном устранении неполадок с этим условием. Чтобы дать представление о скорости событий, зарегистрированных на этом уровне детализации:

Журнал событий служб каталогов, настроенный на 100 МБ, завернутый менее чем за две минуты (1 минуту 27 секунд). Журнал содержал 195 728 событий. Из всех событий 189 340 были идентификатором события 1412 (добавление атрибута).

• Увеличение размера журнала событий служб каталогов

• Размер журнала событий таким образом, чтобы расширенное ведение журнала не приводило к тому, что журнал не заключит слишком короткий период.

• Включение ведения журнала диагностики репликации AD в 0x5:

  HKLM\System\CurrentControlSet\Services\NTDS\Diagnostics 5 Replication Events = 5

Экспортируйте журнал событий служб каталогов вскоре после получения состояния 8461 и уменьшите ведение журнала диагностики на соответствующий уровень.

Просмотрите журнал событий следующим образом:

Насколько быстро значения атрибутов записываются в базу данных? ->Directory Services Event ID 1412 или еще лучше, используйте счетчик производительности: DirectoryServices / DRA Inbound Properties Applied/sec

На уровне диагностики 5 для событий репликации для создания пользовательского объекта около 25 или около того события 1412 (в зависимости от того, что было записано во время создания пользователя), записываются (по одному на значение атрибута). При добавлении всех атрибутов событие создания объекта регистрируется (идентификатор события 1365).

В разделе описания события содержатся следующие данные:

Внутреннее событие:
Следующие изменения объектов были применены к локальной базе данных служб домен Active Directory Services.
Свойство: 900dd (sAMAccountName)
Объект: CN=xtestingusers14167,CN=Users,DC=north,DC=fabrikam,DC=com Object
GUID: <GUID>
Удаленная версия: 1
Удаленная метка времени: <DateTime>
Удаленный исходный USN: 540828

Раздел "Свойство" содержит идентификатор атрибута и lDAPDisplayName атрибута.

Одно событие записывается на значение на этом уровне журнала отладки. Отфильтруйте события и определите, сколько записей происходит в данный период. Просмотрите сведения о событии, чтобы определить, записывают ли мы значения для нескольких атрибутов, чтобы создать экземпляр объекта или если мы записывем один и тот же атрибут в нескольких объектах. Хотя этот уровень анализа может показаться громоздким, это может быть полезно в определении первопричины. Например, если вы видите, что мы записываем только несколько событий в секунду, то это может указывать на то, что транзакции записываются в базу данных медленно или, возможно, у нас слишком много партнеров, которые отправляют избыточные изменения (идентификатор события 1239).

Обратите внимание, что это совершенно нормально, чтобы увидеть идентификатор события 1239, когда диагностика репликации установлено значение 0x5. Если вы отфильтруете событие 1239, и вы видите ничего другого, и у вас есть довольно длинный журнал событий, то это может указывать на проблему. Эта проблема наблюдалась клиентом с большой средой Active Directory, которая включила уведомление об изменении между сайтами. Если определить наличие большого количества событий в секунду, репликация, вероятно, не влияет на проблему производительности.

Метаданные объектов

Если событие регистрируется, указывающее, что изменение занимает много времени для обработки идентификатора события, запишите объектGUID и получите следующие выходные данные:

Метаданные репликации:

Repadmin /showobjmeta "<GUID=ObjectGUID>" >objectmeta.txt

Просмотрите выходные данные для недавно измененных атрибутов. Обратите особое внимание на атрибуты с часто измененными номерами версий. Атрибут с высоким числом версий может указывать на то, что частые изменения вносятся в атрибут. Если вы подозреваете это, можно просмотреть значение атрибута, чтобы получить определенный контекст относительно того, почему атрибут был изменен, или вы можете позволить некоторое время пройти, а затем получить дополнительные repadmin /showobjmeta выходные данные, чтобы проверить, увеличивается ли версия одного и того же атрибута в том же объекте.

Данные объекта и атрибута:

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

Значения атрибута объекта из repadmin:

Repadmin /showattr DCName "<GUID=ObjectGUID>" /allvalues /long >objectByGuid.txt

Значения атрибута объекта из LDP

Подключение и привязка к серверу в LDP и копирование всех выходных данных объекта в текстовый файл

ldpoutput.txt

Данные, связанные с сетью

Tasklist /svc >nets.txt Netstat -anob >>nets.txt

Счетчики производительности репликации Data AnalysisKey AD

• Оставшиеся объекты полной синхронизации DRA
• Примененные объекты DRA входящего трафика/с
• DRA Inbound Objects / Second (входящие репликации)
• Отфильтрованные объекты DRA / с (предлагает все новые атрибуты)
• Общее число исходящих байтов DRA с момента загрузки очереди репликации:

DirectoryServices\DRA Ожидающие синхронизации репликации	Указывает количество синхронизаций каталогов, которые помещаются в очередь для этого сервера. Этот счетчик помогает определить невыполненные работы репликации, чем выше число, тем больше невыполненной работы.	Этот счетчик должен быть максимально низким. В противном случае серверное оборудование, вероятно, замедляет репликацию.

Используйте этот счетчик для определения очереди репликации. Repadmin /queue DCName также сообщает об этом.

Проверка текущей производительности:

Примененные объекты DRA входящего трафика/с	Показывает количество объектов, полученных от соседей через входящие репликации и примененные.
Примененные свойства входящего трафика DRA/с	Показывает общее количество свойств объекта (атрибутов), примененных от партнеров входящего репликации.

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

База данных:

Производительность сервера:

Обновления входящих объектов DirectoryServices\DRA, оставшиеся в пакете	Указывает количество обновлений объектов, полученных в последнем пакете обновления репликации каталога, который еще не применен к локальному серверу.	Этот счетчик указывает на то, что отслеживаемый сервер получает изменения, но их применение к базе данных занимает много времени. Этот счетчик должен быть максимально низким. Если это не так, обычно это означает, что оборудование сервера замедляет репликацию.

Сеть:

Object\counter	Description	Рекомендации
DirectoryServices\DRA Inbound Bytes Total/sec	Указывает общее количество байтов, полученных в секунду при репликации входящего трафика. Это число — сумма байтов несжатых и сжатых данных, полученных во время входящего трафика.

Тестирование

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

Чтобы дать представление о скорости событий, зарегистрированных на этом уровне детализации:

Журнал событий служб каталогов, настроенный на размер 100 МБ, завернутый менее чем за две минуты (1 минуту 27 секунд). Журнал содержал 195 728 событий. Из всех событий 189 340 были идентификатором события 1412 (добавление атрибута). Число событий 1412 в секунду:

01: 2400
02: 3570
03: 3540
04: 2160
05: 1170
06: 1890
07: 2225
08: 1435
09: 4233
10: 2817

Идентификатор события 1365 (создание объекта) регистрировался 6312 раз в 1 минуту 27 секунд. За одну минуту были созданы 4630 пользовательских объектов, состоящих из 138 900 атрибутов) или около 77 объектов в секунду.

Для эффективного устранения этой проблемы требуется понимание счетчиков производительности NTDS.

Создание объектов в секунду осуществляется с помощью следующих счетчиков производительности:

• NTDS / DRA Inbound Objects Applied/sec

• Добавление базы данных в секунду

• NTDS / DRA Inbound Values (только DNs)/sec Этот номер включает объекты, ссылающиеся на другие объекты. Значения для различающихся имен, таких как членство в списке групп или списков рассылки, дороже применяются, чем другие виды значений, так как объект списка групп или рассылки может включать сотни или тысячи членов. В отличие от этого, простой объект может иметь только один или два атрибута. Большое число из этого счетчика может объяснить, почему входящие изменения медленно применяются к базе данных. Создание атрибутов в секунду:

• NTDS / DRA Inbound Properties Applied/sec

Часто встречается специальное условие

Repadmin /rehost приводит к состоянию 8461:

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

Выходные данные repadmin /queue должны показать, что запрос на добавление секции был помещен в очередь и в конечном итоге будет обработан. Однако иногда необходимо использовать альтернативный метод повторного размещения секций:

1. Repadmin /unhost
2. Подождите идентификатор события 1660
3. Отключение перевода подключений KCC
4. Repadmin /addIf Процесс преумножен до завершения /add, можно отключить входящий репликацию и использовать repadmin /replicate , а /readonly /force также параметры для повторного размещения секции перед повторной активацией входящего репликации.

Сбор данных

Если вам нужна помощь от службы поддержки Майкрософт, мы рекомендуем собрать информацию, выполнив действия, описанные в разделе "Сбор сведений" с помощью TSS для проблем с репликацией Active Directory.