Как проверить active directory на ошибки

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

Проверка состояния контроллеров домена с помощью Dcdiag

Базовая встроенная утилита для проверки состояния контролеров домена – dcdiag.

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

dcdiag /s:DC01

Данная команда выполняет различные тесты указанного контроллера домена и возвращает статус по каждому тесту (Passed| Failed).

Типовые тесты:

• Connectivity – проверяет регистрацию DC в DNS, выполняет тестовые LDAP и RPC подключения;
• Advertising – проверяет роли и сервисы, опубликованные на DC;
  FRSEvent – проверяет наличие ошибок в службе репликации файлов (ошибки репликации SYSVOL);
• FSMOCheck – проверяет, что DC может подключиться к KDC, PDC, серверу глобального каталога;
• MachineAccount — проверяет корректность регистрации учетной записи DC в AD, корректность доверительных отношения с доменом;
• NetLogons – проверка наличие прав на выполнение репликации;
• Replications – проверка статуса репликации между контроллерами домена и наличие ошибок;
• KnowsOfRoleHolders – проверяет доступность контроллеров домена с ролями FSMO;
• Services – проверяет, запущены ли на контроллере домена необходимые службы;
• Systemlog – проверяет наличие ошибок в журналах DC;
• И т.д.

Полное описание всех доступных тестов есть здесь.

Помимо стандартных тестов, которые выполняются по-умолчанию, можно выполнить дополнительные проверки контроллера домена:

• Topology – проверяет, что KCC сгенерировал полную топологию для всех DC;
• CheckSecurityError
• CutoffServers – находит DC, который не получает репликацию из-за того, что партнёр недоступен;
• DNS – доступны 6 проверок службы DNS (/DnsBasic, /DnsForwarders, /DnsDelegation, /DnsDymanicUpdate, /DnsRecordRegistration, /DnsResolveExtName)
• OutboundSecureChannels
• VerifyReplicas – проверяет корректность репликации разделов приложения
• VerifyEnterpriseReferences

Например, чтобы проверить корректность работы DNS на всех контроллерах домена, используйте команду:

dcdiag.exe /s:DC01 /test:dns /e /v

В результате должна появится сводная таблица по проверкам разрешения имен службой DNS на всех контроллерах (если все ОК, везде должно быть Pass). Если где-то будет указано Fail, нужно выполнить проверку этого теста на указанном DC:

dcdiag.exe /s:DC01 /test:dns /DnsForwarders /v

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

dcdiag /s:DC01 /v >> c:psdc01_dcdiag_test.log

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

dcdiag.exe /s:winitpro.ru /a

Если нужно вывести только найденные ошибки, используйте параметр /q:

dcdiag.exe /s:dc01 /q

В моем примере утилита обнаружила ошибки репликации:

There are warning or error events within the last 24 hours after the SYSVOL has been shared. Failing SYSVOL replication problems may cause Group Policy problems.
......................... DC01 failed test DFSREvent

Чтобы утилита dcdiag попробовала автоматически исправить ошибки в Service Principal Names для данной учетной записи DC, используйте параметр /fix:

dcdiag.exe /s:dc01 /fix

Проверка ошибок репликации между контроллерами домена Active Directory

Для проверки репликации в домене используется встроенная утилита repadmin.

Базовая команда проверки репликации:

repadmin /replsum

Утилита вернула текущий статус репликации между всеми DC. В идеальном случае значение largest delta не должно превышать 1 час (зависит от топологии и настроек частоты межсайтовых репликаций), а количество ошибок = 0. В моем примере видно, что одна из последних репликаций заняла 14 дней, но сейчас все OK.

Чтобы выполнить проверку для всех DC в домене:

repadmin /replsum *

Проверку межсайтовой репликции можно выполнить так:

repadmin /showism

Для просмотра топологии репликации и найденных ошибках, выполните:

repadmin /showrepl

Данная команда проверит DC и вернет время последней успешной репликации для каждого раздела каталога (last attempt xxxx was successful).

Для запуска репликации паролей с обычного контроллера домена на контроллер домена на чтение (RODC) используется ключ /rodcpwdrepl.

Опция /replicate позволяет запустить немедленную репликацию указанного раздела каталога на определенный DC.

Для запуска синхронизации указанного DC со всеми партнерами по репликации, используйте команду

replmon /syncall <nameDC>

Для просмотра очереди репликации:

repadmin /queue

В идеальном случае очередь должна быть пуста:

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

Repadmin /showbackup *

Вы также можете проверить состояние репликации с помощью PowerShell. Например, следующая команда выведет все обнаруженные ошибки репликации в таблицу Out-GridView:

Get-ADReplicationPartnerMetadata -Target * -Partition * | Select-Object Server,Partition,Partner,ConsecutiveReplicationFailures,LastReplicationSuccess,LastRepicationResult | Out-GridView

Можете дополнительно с помощью Get-Service проверить состояние типовых служб на контроллере домена:

• Active Directory Domain Services (ntds)
• Active Directory Web Services (adws) – именно к этой службе подключаются все командлеты из модуля AD PowerShell
• DNS (dnscache и dns)
• Kerberos Key Distribution Center (kdc)
• Windows Time Service (w32time)
• NetLogon (netlogon)

Get-Service -name ntds,adws,dns,dnscache,kdc,w32time,netlogon -ComputerName dc03

Итак, в этой статье мы рассмотрели базовые команды и скрипты, которые можно использовать для диагностики состояния вашего домена Active Directory. Вы можете использовать их во всех поддерживаемых версия Windows Server, в том числе на контроллерах домена в режиме Server Core.

Время на прочтение
8 мин

Количество просмотров 167K

Авторское примечание: Статья в первую очередь написана для начинающих системных администраторов, опытные вряд ли почерпнут для себя здесь что-нибудь новое и полезное. Навеяно статьей про GPUPDATE /force (спасибо mrHobbY).

Active Directory – это большой и сложный организм (даже если он состоит и двух контроллеров домена и одного сайта), и для системного администратора очень важно в любой момент времени провести диагностику для анализа работы этого организма.
Ну, а так как по оснасткам ходить и смотреть малоэффективно, по логам системы тоже не всегда поймешь, что происходит, поэтому на помощь приходят различные утилиты. Одна из них – dcdiag от компании Microsoft.
Посмотрим на нее внимательно – ибо полезность данной утилиты трудно переоценить. Я не буду приводить многочисленные ключи данной команды – про них при желании можно и в справке прочитать — а остановлюсь только на тех, – которые использую сам при диагностике на практике.

Первое, что нужно сделать, чтобы работать с этой утилитой – это установить ее к себе на рабочую станцию или на сам сервер (тут каждый волен выбирать сам, но в последних версиях dcdiag – уже в помощи написано, что проверки необходимо запускать на самих серверах — контроллерах домена, за исключением тестов dcPromo и RegisterInDNS). Для Windows 2003 необходимо установить пакет Support Tools c дистрибутива операционной системы, для Windows 7 и 8 – необходимо установить пакет Remote System Administration Tools (они разные для win7, win7sp1, и win8 – будьте внимательны, когда будете скачивать). Кстати, RSAT — сам по себе полезный продукт – внутри много утилит, которые просто необходимы в повседневной жизни администратора домена.
После установки пакета команда уже доступна из командной строки.
Но не торопитесь запускать ее сразу, на рабочей станции ничего не получится без указания контроллера домена, к которому надо подключиться. Утилита выдаст соответствующее предупреждение:

Примечание: начиная с Windows 7 сообщения dcdiag переведены на русский. До этого – все только на английском. Может будет кому полезно. Хотя и в старых версиях очень простой и понятный английский язык.

Замечательно – мы выяснили – что желательно указать контроллер домена с помощью ключа /s: или контекст именования – /n:. Какой сервер указывать понятно – тот контроллер домена, который вы хотите проверить – а вот если указать контекст именования домена – (имя домена другими словами – можно указывать в форматах Netbios, DNS или DN.), то будет найден ближайший (в пределах сайта) контроллер домена (далее КД).
Проведем самую простую проверку: dcdiag /s:dc01-local
И опять беда, хотя кое-что уже видно:

dcdiag /s:dc01-local.local

Диагностика сервера каталогов

Выполнение начальной настройки:
   * Идентифицирован лес AD.
   Сбор начальных данных завершен.

Выполнение обязательных начальных проверок

   Сервер проверки: Localdc01-local
      Запуск проверки: Connectivity
         ......................... DC01-LOCAL - пройдена проверка Connectivity

Выполнение основных проверок

   Сервер проверки: Localdc01-local
      Запуск проверки: Advertising
         ......................... DC01-LOCAL - пройдена проверка Advertising
      Запуск проверки: FrsEvent
         Ошибка 5 при открытии File Replication Service журнала событий
         \DC01-LOCAL:File Replication Service:
          Отказано в доступе.
         ......................... DC01-LOCAL - не пройдена проверка FrsEvent
      Запуск проверки: DFSREvent
         ......................... DC01-LOCAL - пройдена проверка DFSREvent
      Запуск проверки: SysVolCheck
         ......................... DC01-LOCAL - не пройдена проверка SysVolCheck
      Запуск проверки: KccEvent
         Ошибка 5 при открытии Directory Service журнала событий
         \DC01-LOCAL:Directory Service:
          Отказано в доступе.
         ......................... DC01-LOCAL - не пройдена проверка KccEvent
      Запуск проверки: KnowsOfRoleHolders
         ......................... DC01-LOCAL - пройдена проверка
         KnowsOfRoleHolders
      Запуск проверки: MachineAccount
         ......................... DC01-LOCAL - пройдена проверка MachineAccount
      Запуск проверки: NCSecDesc
         ......................... DC01-LOCAL - пройдена проверка NCSecDesc
      Запуск проверки: NetLogons
         [DC01-LOCAL] В учетных данных пользователя отсутствует разрешение на
         выполнение данной операции.
         Учетная запись, используемая для этой проверки, должна иметь права на
         вход в сеть
         для домена данного компьютера.
         ......................... DC01-LOCAL - не пройдена проверка NetLogons
      Запуск проверки: ObjectsReplicated
         ......................... DC01-LOCAL - пройдена проверка
         ObjectsReplicated
      Запуск проверки: Replications
         [Проверка репликации,DC01-LOCAL] Сбой функции
         DsReplicaGetInfo(PENDING_OPS, NULL), ошибка 0x2105
         "Доступ к репликации отвергнут."
         ......................... DC01-LOCAL - не пройдена проверка Replications
      Запуск проверки: RidManager
         ......................... DC01-LOCAL - пройдена проверка RidManager
      Запуск проверки: Services
         Не удалось открыть диспетчер управления службой в
         dc01-local.local, ошибка 0x5 "Отказано в доступе."
         ......................... DC01-LOCAL - не пройдена проверка Services
      Запуск проверки: SystemLog
         Ошибка 5 при открытии System журнала событий \DC01-LOCAL:System:
          Отказано в доступе.
         ......................... DC01-LOCAL - не пройдена проверка SystemLog
      Запуск проверки: VerifyReferences
         ......................... DC01-LOCAL - пройдена проверка VerifyReferences


   Выполнение проверок разделов на: Schema
      Запуск проверки: CheckSDRefDom
         ......................... Schema - пройдена проверка CheckSDRefDom
      Запуск проверки: CrossRefValidation
         ......................... Schema - пройдена проверка
         CrossRefValidation

   Выполнение проверок разделов на: Configuration
      Запуск проверки: CheckSDRefDom
         ......................... Configuration - пройдена проверка
         CheckSDRefDom
      Запуск проверки: CrossRefValidation
         ......................... Configuration - пройдена проверка
         CrossRefValidation

   Выполнение проверок разделов на: LOCAL
      Запуск проверки: CheckSDRefDom
         ......................... LOCAL - пройдена проверка CheckSDRefDom
      Запуск проверки: CrossRefValidation
         ......................... LOCAL - пройдена проверка
         CrossRefValidation

   Выполнение проверок предприятия на: LOCAL.local
      Запуск проверки: LocatorCheck
         ......................... LOCAL.local - пройдена
         проверка LocatorCheck
      Запуск проверки: Intersite
         ......................... LOCAL.local - пройдена
         проверка Intersite

Как мы видим, часть тестов пройдена – но части отказано в доступе. Это из-за того, что dcdiag я запускал из-под обычной учетной записи домена, без администраторских прав. Понятно – что часть проверок пройти под ней просто невозможно. Поэтому, что бы получить правильную диагностику, необходимо запускать утилиту с административными полномочиями – либо запустить командную строку от имени администратора, либо использовать ключи /u: имя доменаимя пользователя и /p: пароль. Попробуем:
dcdiag /s:dc01-local /u:localuser19 /p:Password

Диагностика сервера каталогов

Выполнение начальной настройки:
   * Идентифицирован лес AD.
   Сбор начальных данных завершен.

Выполнение обязательных начальных проверок

   Сервер проверки: MagadanDC01-LOCAL
      Запуск проверки: Connectivity
         ......................... DC01-LOCAL - пройдена проверка Connectivity

Выполнение основных проверок

   Сервер проверки: MagadanDC01-LOCAL
      Запуск проверки: Advertising
         ......................... DC01-LOCAL - пройдена проверка Advertising
      Запуск проверки: FrsEvent
         ......................... DC01-LOCAL - пройдена проверка FrsEvent
      Запуск проверки: DFSREvent
         ......................... DC01-LOCAL - пройдена проверка DFSREvent
      Запуск проверки: SysVolCheck
         ......................... DC01-LOCAL - пройдена проверка SysVolCheck
      Запуск проверки: KccEvent
         ......................... DC01-LOCAL - пройдена проверка KccEvent
      Запуск проверки: KnowsOfRoleHolders
         ......................... DC01-LOCAL - пройдена проверка
         KnowsOfRoleHolders
      Запуск проверки: MachineAccount
         ......................... DC01-LOCAL - пройдена проверка MachineAccount
      Запуск проверки: NCSecDesc
         ......................... DC01-LOCAL - пройдена проверка NCSecDesc
      Запуск проверки: NetLogons
         ......................... DC01-LOCAL - пройдена проверка NetLogons
      Запуск проверки: ObjectsReplicated
         ......................... DC01-LOCAL - пройдена проверка
         ObjectsReplicated
      Запуск проверки: Replications
         ......................... DC01-LOCAL - пройдена проверка Replications
      Запуск проверки: RidManager
         ......................... DC01-LOCAL - пройдена проверка RidManager
      Запуск проверки: Services
            Недопустимый тип службы: RpcSs на DC01-LOCAL, текущее значение -
            WIN32_OWN_PROCESS, ожидаемое значение - WIN32_SHARE_PROCESS
         ......................... DC01-LOCAL - не пройдена проверка Services
      Запуск проверки: SystemLog
         ......................... DC01-LOCAL - пройдена проверка SystemLog
      Запуск проверки: VerifyReferences
         ......................... DC01-LOCAL - пройдена проверка VerifyReferences


   Выполнение проверок разделов на: Schema
      Запуск проверки: CheckSDRefDom
         ......................... Schema - пройдена проверка CheckSDRefDom
      Запуск проверки: CrossRefValidation
         ......................... Schema - пройдена проверка
         CrossRefValidation

   Выполнение проверок разделов на: Configuration
      Запуск проверки: CheckSDRefDom
         ......................... Configuration - пройдена проверка
         CheckSDRefDom
      Запуск проверки: CrossRefValidation
         ......................... Configuration - пройдена проверка
         CrossRefValidation

   Выполнение проверок разделов на: LOCAL
      Запуск проверки: CheckSDRefDom
         ......................... LOCAL - пройдена проверка CheckSDRefDom
      Запуск проверки: CrossRefValidation
         ......................... LOCAL - пройдена проверка
         CrossRefValidation

   Выполнение проверок предприятия на: LOCAL.Local
      Запуск проверки: LocatorCheck
         ......................... LOCAL.Local - пройдена
         проверка LocatorCheck
      Запуск проверки: Intersite
         ......................... LOCAL.Local - пройдена
         проверка Intersite

ак видим, проверки пройдены почти все – кроме проверки Services. Но тут у меня есть вполне логичное объяснение – я с помощью новой утилиты (из пакета для windows 7) пытаюсь проверять контроллер домена на базе win2003 – и вполне возможно, название службы может отличаться.

Лирическое отступление №1. При подготовке статьи я столкнулся с

epic fail

забавным феноменом, может в комментариях обсудим? :). В общем, запуская dcdiag из-под обычной учетной записи другого домена (связанного доверительными отношениями с исследуемым доменом local) и задавая параметры /u и /p – (имя пользователя и пароль административной учетной записи домена local) – утилита выдавала ошибки в части проверок — например sysvolchek (в версии dcdiag 2003 – frssysvol). Если же на рабочую станцию зайти под учетной записью с административными полномочиями в домене local — проверки прекрасно проходятся. Так что – может быть, все-таки не лишним будет проводить проверку на самом сервере. Конец лирического отступления №1.

Полностью описывать результаты работы команды я не вижу смысла. Это прекрасно описано в помощи к утилите (dcdiag /h). Видно главное – с данным контроллером домена проблем нет и все тесты пройдены. Но из проверки одного сервера – не следует факт, что AD сейчас находится в

шоколаде

работоспособном состоянии. И вот здесь нам на помощь придет ключ для проверки всех серверов предприятия.
Это ключ /e. Данный ключ заставляет утилиту обойти все КД в домене с запуском всех тестов на каждом сервере. Полезно вместе с этим применить /v – вывод расширенной информации по каждому тесту. Ну и чтобы проанализировать все это – полезно данные вывести в файл – причем лог отдельно, сообщения об ошибках – отдельно. Помогут в этом ключи /f: имя_файла_лога и ferr:/имя_файла_лога_ошибок (в новых версиях ключ /ferr убран). Если вы хотите провести проверку не того домена, в котором находитесь сейчас – добавите ключ для указания наименования контекста /n:.

Полностью команда выглядит так:
dcdiag /n:local /e /v /f:c:logsadtest.log /ferr:c:logsaderrors.log /u:localuser19 /p:Password

Внимание! В версиях dcdiag, начиная с windows 2008 ключ /ferr: убран из поддерживаемых (специально повторился :)).
Если у вас сложная структура леса, да еще и с медленными каналами связи приготовьтесь подождать. Да даже и если несложная – скажем у меня в одном реальном лесе – 10 КД, 5 сайтов и каналы 256 кбит/сек. Выполнение данной команды занимает в среднем до 20 минут.
Результат исполнения очень рекомендуется внимательно просмотреть на наличие проблем. Ну и очень желательно запускать данную утилиту регулярно для диагностики здоровья AD.
Для хардкора можно еще добавить ключ /fix – внесение безопасных исправлений, но бездумно все-таки этого делать не стоит.

Вот собственно и все что я хотел сегодня рассказать. А как часто вам приходится пользоваться данной утилитой на производстве? Какие альтернативы вы знаете?

update 1: Что-то вспомнилось, опять же из личного опыта: если у вас большой домен, связанный небыстрыми (например, спутниковыми) каналами связи — утилита будет выдавать массу ошибок в случае ее отсутствия — чаще всего, что недоступен RPC. Это нормально, и про это надо знать. Если большинство тестов оканчивается подобным сообщением — значит нет связи, необходимо применять меры по устранению сбоя. Вторая часто распространенная проблема — ошибки в DNS — но это тема уже для отдельной статьи.
p.s. к update 1 -dcdiag /fix — в том числе регистрирует по новой записи в dns службы netlogon — это тоже бывает полезно знать!

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

DCDiag – важная утилита для проверки состояния контроллеров домена. Войдите на любой контроллер домена, запустить командную строку и выполните команду:

dcdiag /e /v /q

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

Затем нужно проверить здоровье DNS серверов (я запускаю эти команды в консоли PowerShell):

DCDiag /Test:DNS /e /v /s:msk-dc01.test.com >c:PSDcdiagDNStest.txt

Затем откройте полученный отчет:

Notepad c:PSDcdiagDNStest.txt

Если со службой DNS нет проблем, то в разделе “Summary of DNS test results” везде должно быть указано PASS.

Если в отчете есть ошибки, нужно исправить их вручную. Если вручную исправить ошибки DNS не удается, попробуйте исправить их автоматически командой dcdiag с параметром fix:

DCDiag /Test:DNS /e /v /s:msk-dc01.test.com /fix

Затем на всех всех контроллерах домена выполните команду:

ipconfig /registerdns

После проверки контроллеров домена и DNS службы нужно проверить состояние репликации Active Directory.

Войдите на любой DC и выполните проверку репликации командой:

repadmin /replsum

Если наибольшее из значений largest delta для любого DC не превышает 1 часа и replication fails = 0, значит в вашем домене нет проблем репликации

Утилиты dcdiag и repadmin доступны на любом DC с ролью ADDS. Если вы хотите использовать эти утилиты в десктопной Windows 10, нужно установить RSAT.

Если вы обнаружили ошибки репликации, можно получить подробную информацию о них командой:

repadmin /showreps

Данная команда покажет какой контекст наименования не реплицируется в AD.

Следующая команда используется для быстрой проверки репликации на конкретном сервере. Если нужно проверить репликацию на всех DCs, используйте параметр wildcard (может занять длительное время)

repadmin /replsummary [DCname|wildcard]

Проверьте USN записи:

repadmin /showutdvec

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

replmon /syncall msk-dc01

Далее обязательно проверьте синхронизацию времени на контроллерах домена командой:

w32tm /monitor

NTP offset должен быть около 0 для всех DC. Если нет, вам нужно схему проверить синхронизацию времени в вашем домене Active Directory.

Проверьте, что на всех контроллерах домена есть расшаренные сетевые папки SYSVOL и Netlogon. Эти папки нужны для применения и репликации групповых политик (объектов GPO).

Список общих папок на DC можно вывести командой:

net share

Теперь проверьте корректность работы Netlogons в Active Directory:

dcdiag /test:netlogons

Если с Netlogon все в порядке для всех тестов должно быть указано passed test.

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

gpresult

This document is to serve basic step-by-step method to initiate the first and primary action of the overall troubleshooting process when a domain
controller is down.

1. Check recent changes

This can include patch management, services stopping unexpectedly, etc.

The approach you take is to look in the event logs in event viewer, system, application, security, and group policy logs are most common logs however a domain controller also has

Active Directory,
DNS, file services, AD web services logs as well as others that all can help point to the issue. Also, review the services.msc, make sure all
required services are started, stopped or services getting crashed. Make sure your domain controllers NIC information is correctly
stated.  If running IPSEC verify your policy and make sure on both ends of the policy that it is correct and valid.

2. Is everything on the domain controller working as intended?

To verify this you open an admin command prompt and run the following commands:

• NET SHARE (This command will show if the sysvol is shared out or not)
• IPCONFIG / FlushDNS (DNS caching may generate a false impression that DNS «round robin» is not taking place from the DNS server to the Windows client)
• REPADMIN /KCC (KCC is Knowledge Consistency Check and this will recalculate the replication topology of your active directory infrastructure)
• REPADMIN  /SYNCALL (This will force replicate with its replication partners)
• REPADMIN /SYNCALL APED
  (This will force replicate to all domain controllers)
• GPUPDATE /FORCE (This will enforce the group policy assigned to the domain controller)
• DCDIAG /C /V >C:dcdiag.txt
  (This will perform a verbose mode DCDIAG and save it
  to a text file)
• Portqry.exe (This command-line utility is used to verify recommended AD port communication)
• w32tm /query /status (Verify Time Synchronization)

Needless to say that if any of these commands and outputs show any errors then you need to mark down the error and research from there.

3. Were networking devices altered in any way?

This involves routers, switches, firewalls, etc. Too often a network engineer makes changes that can break an Active Directory infrastructure and the best way to troubleshoot this is the following:

• Can you ping the device?
• Can you resolve DNS queries using
  NSLOOKUP? (Using nslookup -a ipaddress)
• Using LDP.EXE can you bind to the Active Directory store?
• Use a port query tool verify the required AD ports are open/ listening and not closed/ filtered?
• Talk with the network engineer. Ask if he or she changed the VLAN or

  ACL’s that your AD infrastructure uses?

• Did he or she change/ update the intrusion prevention system?
• Did the switch port security kick in?

References

The links below are troubleshooting references.

• Service overview and network port requirements for Windows:
  http://support.microsoft.com/kb/832017
• Troubleshooting Active Directory Replication Problems:
  http://technet.microsoft.com/en-us/library/4f504103-1a16-41e1-853a-c68b77bf3f7e
• Troubleshooting Active Directory Domain Services:
  http://technet.microsoft.com/en-us/library/cc990288(v=ws.10).aspx
• Diagnosing and Troubleshooting Active Directory Problems:
  http://technet.microsoft.com/en-us/library/cc961826.aspx
• Troubleshooting Active Directory-Related DNS Problems:
  http://technet.microsoft.com/en-us/library/bb727055.aspx
• Troubleshooting DNS:
  http://technet.microsoft.com/en-us/library/cc753041.aspx

As stated in the beginning, this is a very basic approach to troubleshooting. Every infrastructure is different and as such the approach must be different, however, this guide is a baseline to the most basic of troubleshooting and can greatly help even the
most seasoned administrator quickly and proficiently find the exact problem and get a solution implemented.

Keep an eye on Active Directory (AD) health with commands that are built into Windows Server.

Active Directory is coordinated by domain controllers. These controllers are essential to the smooth running of your AD implementations. Therefore, it is important to know how to check on their statuses.

A health check for Active Directory domain controllers can be performed with native Microsoft tools that cost nothing. However, there are some skills you need to acquire in order to carry out the check. We will show you how.

Repadmin

The first tool that you need in order to check up on your domain controllers is called repadmin. This is a command that is built into Windows Server, so you don’t need to download or install any software in order to use it.

All of the domains in a forest need to be coordinated through replication. The repadmin utility lets you check on how that process is faring by accessing a summary report from repadmin. This is available through the command repadmin /replsumary.

In the output of the summary, you will be able to see that all of your domain controllers are replicating properly. The largest replication delta means the longest time gap that occurred between replications for that domain controller. You can also see in the output if any replication activities failed.

You can get more detail of the replication activity of each domain controller with the command repadmin /showrepl. To limit the output to just the information for one domain controller, put its label at the end of the showrepl option, such as repadmin /showrepl DC1. The showrepl option will display the neighbors (replication partners) that update the domain controller.

You can home in on the replication errors if any were reported in the summary output by specifying the /errorsonly option, eg. repadmin /showrepl /errorsonly.

If one of your domain controllers is out of date, you can command an immediate replication run with the option repadmin /syncall. Name the domain controller that needs to be updated in the repadmin command. This command should be run on the server that hosts the AD domain. For example, to update domain controller DC2 immediately, you would use repadmin /syncall dc2. There is a long list of options that can be added to the end of this command. To see them all, enter repadmin /syncall /?.

To see the full list of repadmin commands, type repadmin /?.

Services-check in PowerShell

Access PowerShell to see that the Active Directory Domain services are running properly. These are the six services to look at:

• DNS server
• DFS replication
• Intersite messaging
• Kerberos key distribution
• Active Directory Domain Services
• NetLogon

In order to check that these four services are all running, use the following two lines:

$Services='DNS','DFS Replication','Intersite Messaging','Kerberos Key Distribution Center','NetLogon',’Active Directory Domain Services’
ForEach ($Service in $Services) {Get-Service $Service | Select-Object Name, Status}

Although this is a complicated request to write, the output is very straightforward, you should just get a report that each of these services is running.

DCDiag (dcdiag.exe)

A key tool that you need in order to keep tabs on your AD domain controllers is called DCDiag, or dcdiag.exe. This also covers issues around replication. As well as this, it can check on DNS servers and other essential services. The command is bundled in with the Remote Server Administration Tools (RAST) and it is also included with the AD DS role.

DCDiag is able to run 30 different tests on your Active Directory domain controllers and their supporting services. Among these tests are:

• Initial tests to verify the availability of key services and to ensure that they are contactable. These tests must be performed before all others and they can’t be left out. They check on the DNS server, that the domain controller can be contacted over the network, that the domain controller allows binding to an LDAP instance, and to the AD RPC interface.
• Advertising tests that check on the ability of other devices to locate the domain controller, which means that the controller is correctly notifying all other devices of its presence. The details of the response to this test are important – not just that there is a response – because it includes flags that indicate which services the domain controller can locate. These services are an LDAP server, the Write or Read-Only status, the time server, whether the DC is a global catalog and whether it is ready to respond, and the Key Distribution Center (KDC).
• Cross-reference objects test to see if the application partition’s cross-reference objects have the correct domain name.
• Cross-reference validation gets the naming contexts in the DC and checks them.
• Security services check to test that there is at least one reachable KDC per domain, that the Knowledge Consistency Checker (KCC) is working, that the GC’s computer object has replicated to other domain controllers, that it also has an account within the Active Directory setup that marks it as a domain controller and has the correct flags set. It also checks on the likelihood of fragmentation of Kerberos packets.
• DC connectivity tests examine whether all domain controllers can communicate with their partner DCs.
• File Replication Service tests look in the Event log for any error warnings related to the FRS that occurred over the last 24 hours. This is for Windows Server versions before 2008.
• Distributed File Service Replication tests examine DFSR Event log warnings over the last 24 hours to verify that the replication system is working correctly. This is for Windows Server 2008 and later.
• Registry key validation is carried out to ensure that the domain controller’s Netlogon SysvolReady value in the registry is properly set. This test contributes to the FRS and DFRS tests that are outlined above.
• Account validation makes sure that the user accounts that require access to the domain controller’s NetLogon and Sysvol values in order to function can actually get access. Other account-related tests include a verification that the account of the domain controller can access Active Directory and that it is marked as a Domain Controller account, that all flags on the account are correct and that it has the correct server reference. These account tests also offer repair options in the commands that run the checks.
• Object replication verification checks a small number of objects and attributes on several domain controllers to ensure that they have been replicated. The test will also show the last update date and time of each value on each instance. Note that this replication is for the data within the domain controller.
• Replication checks return data on recent replication attempts, showing statuses and times of each event. It particularly focuses on whether any replication took more than 12 hours and whether any domain controller has replication disabled.
• RID Master tests see whether the RID Master role holder can be located and contacted and has valid RID pool values.
• Services tests look at the statuses of all vital services for AD, such as DNS, FRS/DFRS, and KDC.
• Event log tests ensure that Windows Event logs related to Active Directory are being preserved. These print all related log messages from the last 60 minutes.
• Replication topology checks look at whether inter and intra-site replication is possible for a specific domain controller by exploring the settings of all upstream and downstream replication partners.

It is possible to see all of the test categories available in dcdiag.exe by issuing the command dcdiag /h.

How to run DCDiag tests

The dcdiag.exe program makes operating tests very easy. You don’t need to issue a command for each test. Instead, one short dcdiag.exe request launches a group of tests. Some guides tell you that you have to name the dcdiag program in full in order to run it, typing dcdiag.exe. However, this is not necessary – typing dcdiag is enough.

There are two formats to running the command depending on whether you want to query the domain controller that is resident on the host on which you run the command or on a DC that is hosted on a remote server. If you want to test a remote domain controller, you put its name immediately after the command with the /s: switch; if you are examining the local domain controller, you leave that bit out.

It is also possible to specify a username and password for a remote domain controller account. The label for the account name is /u: and for the password is /p. So, an example of a command to test a remote domain controller could be:

dcdiag /s:DC01 /u:Administrator /p:ComPlex1PssWd7

To run tests on a local domain controller, you would just need to type in

dcdiag

The good news is that this one command runs a battery of tests. There is a list of individual test names that you can run individually.

DCDiag options

DCDiag options go after the command and an optional identifier for a remote domain controller. You can get a list of them by entering dcdiag /? Or dcdiag /h. Here is the list:

• /a Test all domain controllers on this site.
• /e Test all domain controllers for this enterprise.
• /q Quiet mode. Only show error messages.
• /v Verbose mode. Display detailed information on each test.
• /c Comprehensive mode. Run all tests except DCPromo, RegisterInDNS, Topology, CutoffServers, and OutboundSecureChannels.
• /i Ignore superfluous error messages.
• /fix Fix the Service Principal Name (only for the MachineAccount test).
• /f: <filename> Send all output to the named file.
• /test: <testname> Perform only the named test.
• /skip: <testname> Skip the named test from the series.
• /ReplSource: <SourceDomainController> Test the relationship between the subject DC and the named DC.

It isn’t necessary to add any options to the command; DCDiag can be run alone, without any further keywords, just the command name itself.

Running specific tests with DCDiag (dcdiag.exe)

The straightforward dcdiag command runs a battery of tests. It is possible to just run one of these tests or a category of tests. For example, DNS-related tests are all grouped under the test name DNS. To run these tests on a local server, you just need to enter:

dcdiag /test:DNS

This command will run a suite of tests:

• DNSBasic Basic tests, such as connectivity, DNS client configuration, service availability, and zone existence.
• DnsForwarders Checks the configuration of forwarders plus the DnsBasic tests.
• DnsDelegation Checks for proper delegations plus the DnsBasic tests.
• DnsDynamicUpdate Checks whether a dynamic update is enabled in the Active Directory zone plus the DnsBasic tests.
• DnsRecordRegistration Checks if the address (A), canonical name (CNAME), and well-known service (SRV) resource records are registered, creating an inventory report. Also performs the DnsBasic tests.
• DnsResolveExtName [/DnsInternetName:<InternetName>] Tests the DNS records by resolving Microsoft.com. if the optional DnsInternetName is specified, this will be resolved instead. Also runs the DnsBasic tests.
• DnsAll Performs all tests, except for DnsResolveExtName.

As well as running a group of tests, the /test option can launch individual tests. So, in the DNS option above, the user could also choose to just run the DnsBasic package with the command:

dcdiag /test:DnsBasic

DCDiag (dcdiag.exe) is a very useful tool but be aware that some tests can take a long time to run. Especially if you use the /e option to test the entire system, don’t expect to see a report straight away. Those administrating the system for a large company with many inter-connected sites that share an AD structure should launch the command and then go to lunch while waiting for a response.

Summary

By using Repadmin, a PowerShell services check, and DCDiag, you can get a very good view of your AD structure. However, despite the great services of these free utilities, you will still be using manual methods to maintain a complicated IT system.

Active Directory is vital for effective system security but it can be difficult to visualize and manage. Consider an automated tool instead. You should check out ManageEngine ADManager Plus and the SolarWinds Active Directory Monitoring tool for some good automated AD management tools.

Domain Controller Health Check FAQs