Мониторинг состояния репликации Active Directory с помощью Azure Monitor

Символ

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

Решение "Состояние репликации AD" регулярно отслеживает среду Active Directory на наличие ошибок репликации.

Установка и настройка решения

Для установки и настройки решений используйте указанные ниже данные.

Предварительные требования

  • Для решения "Состояние репликации AD" на каждом компьютере с агентом анализа журналов для Windows (также известном как Microsoft Monitoring Agent (MMA)) должна быть установлена поддерживаемая платформа .NET Framework 4.6.2 или более поздней версии. Этот агент используется решением System Center 2016 Operations Manager и Operations Manager 2012 R2, а также Azure Monitor.
  • Решение поддерживает контроллеры домена под управлением Windows Server 2008 и 2008 R2, Windows Server 2012 и 2012 R2, а также Windows Server 2016.
  • Рабочая область Log Analytics для добавления решения проверки работоспособности Active Directory в Azure Marketplace на портале Azure. Дополнительные настройки для этого не требуются.

Установка агентов на контроллерах домена

Агенты необходимо установить на контроллерах домена, являющихся членами домена, который будет оцениваться. Или установите агенты на рядовых серверах и настройте их таким образом, чтобы данные репликации AD отправлялись в Azure Monitor. Дополнительные сведения см. в статье о подключении компьютеров Windows к Azure Monitor. Если контроллер домена уже является частью существующей среды System Center Operations Manager, которую вы хотите подключить к Azure Monitor, см. статью о подключении Operations Manager к Azure Monitor.

Включение контроллера вне домена

Если вы не хотите подключать напрямую какой-либо из контроллеров домена к Azure Monitor, то можете собирать данные для пакета решения "Состояние репликации AD" и отправлять их с помощью любого другого подключенного к Azure Monitor компьютера в своем домене.

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

  2. Подключите компьютер Windows к Azure Monitor или подключите компьютер Windows к Azure Monitor с помощью существующей среды Operations Manager, если он еще не подключен.

  3. На этом компьютере настройте следующий раздел реестра.
    Раздел: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HealthService\Parameters\Management Groups<ManagementGroupName>\Solutions\ADReplication
    Значение: IsTarget.
    Данные значения: true

    Примечание

    Эти изменения не вступят в силу, пока вы не перезапустите службу Microsoft Monitoring Agent (HealthService.exe).

    Установка решения

    Следуйте инструкциям в разделе об установке решения для мониторинга, чтобы добавить решение Состояние репликации Active Directory в рабочую область Log Analytics. Дополнительная настройка не требуется.

Сведения о сборе данных состояния репликации AD

В следующей таблице приведены методы сбора данных и другие сведения о сборе данных для решения для контроля состояния репликации AD.

platform Direct Agent Агент SCOM Хранилище Azure Нужен ли SCOM? Отправка данных агента SCOM через группу управления Частота сбора
Windows Каждые пять дней

Основные сведения об ошибках репликации

Данные, собранные этим решением для мониторинга, доступны на странице Сводка рабочей области (не рекомендуется) в портал Azure. Откройте эту страницу в рабочих областях Log Analytics для рабочей области с вашим решением, а затем выберите Сводка рабочей области (нерекомендуемая) в разделе Классическое меню. Каждое решение представлено в виде плитки. Выберите плитку, чтобы получить более подробные данные, собранные этим решением.

На плитке Состояния репликации AD отображается текущее количество обнаруженных ошибок. Критические ошибки репликации — это ошибки, существующие не меньше 75 % от времени существования отметки полного удаления для леса Active Directory.

Элемент состояния репликации AD

Если щелкнуть элемент, можно просмотреть дополнительные сведения об ошибках. Панель мониторинга

Состояния сервера назначения и исходного сервера

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

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

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

Типы ошибок репликации

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

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

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

Время существования отметки полного удаления

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

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

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

С помощью области времени существования отметки полного удаления можно определить, где существует риск отключения репликации. Каждая ошибка в категории Over 100% TSL (Больше 100 % времени существования отметки полного удаления) представляет секцию, которая не была реплицирована между исходным сервером и сервером назначения по крайней мере в течение времени существования отметки полного удаления, заданного для леса.

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

Помимо выявления ошибок репликации, которые существовали дольше времени существования отметки полного удаления, также следует уделить внимание ошибкам, попавшим в категорию 50-75% TSL (50–75 % времени существования отметки полного удаления) или 75-100% TSL (75–100 % времени существования отметки полного удаления).

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

Как уже отмечалось, в элементе панели мониторинга решения для контроля состояния репликации AD показано число критических ошибок репликации в среде. Это ошибки, существующие больше 75 % времени существования отметки полного удаления (включая ошибки, которые существуют больше 100 % этого времени). Старайтесь, чтобы это количество было равно 0.

Примечание

Все проценты от времени существования отметки полного удаления вычисляются от фактического времени существования отметки полного удаления, заданном для леса Active Directory. Поэтому вы можете полагать эти проценты верными, даже если задали пользовательское значение времени существования отметки полного удаления.

Сведения о состоянии репликации AD

Если щелкнуть любой элемент в одном из списков, в журнал будет отправлен запрос, после чего отобразятся дополнительные сведения об этом элементе. Результаты будут отфильтрованы по элементу, чтобы показать только ошибки, относящиеся к нему. Например, если щелкнуть первый контроллер домена в списке Destination Server Status (ADDC02) (Состояние сервера назначения (ADDC02)), отобразятся отфильтрованные результаты запроса, содержащие только ошибки, в которых в качестве сервера назначения указан этот контроллер домена.

Ошибки состояния репликации AD в результатах запроса

Здесь можно применить дополнительные фильтры, изменить запрос в журнал и т. д. Дополнительные сведения о запросах к журналам см. в документации по анализу данных журналов в Azure Monitor.

В поле HelpLink отображается URL-адрес страницы TechNet с дополнительными сведениями об этой конкретной ошибке. Можно скопировать эту ссылку и вставить ее в окно браузера, чтобы просмотреть сведения об диагностике и устранении ошибки.

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

Экспортированные ошибки состояния репликации AD в Excel

Часто задаваемые вопросы

Вопрос. Как часто обновляются данные о состоянии репликации AD? Ответ. Данные обновляются каждые пять дней.

Вопрос. Можно ли настроить частоту обновления данных? Ответ. Пока что нет.

Вопрос. Необходимо ли добавить все контроллеры домена в мою рабочую область Log Analytics, чтобы просмотреть состояние репликации? Ответ. Нет, нужно добавить только один контроллер домена. Если у вас несколько контроллеров домена в рабочей области Log Analytics, в Azure Monitor отправляются данные со всех контроллеров.

Вопрос. Я не хочу добавлять какие-либо контроллеры домена в мою рабочую область Log Analytics. Смогу ли я тогда использовать решения для контроля состояния репликации AD?

Ответ. Да. Для этого вы можете задать значение раздела реестра. См. раздел Включение контроллера вне домена.

Вопрос. Как называется процесс, который собирает данные? Ответ. AdvisorAssessment.exe.

Вопрос. Сколько времени требуется для сбора данных? Ответ. Время сбора данных зависит от размера среды Active Directory, но обычно это менее 15 минут.

Вопрос. Какие данные какого типа собираются? Ответ. Сведения о репликации собираются по протоколу LDAP.

Вопрос. Можно ли настроить время сбора данных? Ответ. Пока что нет.

Вопрос. Какие разрешения требуются для сбора данных? Ответ. Разрешений обычного пользователя в Active Directory будет достаточно.

Устранение неполадок при сборе данных

Для сбора данных пакету решения для контроля состояния репликации AD требуется, чтобы к рабочей области Log Analytics был подключен по крайней мере один контроллер домена. Пока вы не подключите контроллер домена, будет отображаться сообщение о том, что сбор данных по-прежнему выполняется.

Если вам требуется помощь при подключении одного из контроллеров домена, ознакомьтесь с документацией по подключению компьютеров Windows к Azure Monitor. Кроме того, если ваш контроллер домена уже подключен к существующей среде System Center Operations Manager, вы можете ознакомиться с документацией по подключению System Center Operations Manager к Azure Monitor.

Если не требуется подключать контроллеры домена напрямую к Azure Monitor или System Center Operations Manager, см. дополнительные сведения в разделе Включение контроллера вне домена.

Дальнейшие действия