Active Directory это надежный, но в то же время крайне сложный и критичный сервис, от работоспособности которого зависит работа всей вашей сети. Системный администратор должен постоянно мониторить корректность работы Active Directory. В этой статье мы рассмотрим основные методики, позволяющие вам быстро проверить и диагностировать состояние вашего домена Active Directory, контроллеров домена и репликации.
Содержание:
- Проверка состояния контроллеров домена с помощью Dcdiag
- Проверка ошибок репликации между контроллерами домена 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:\ps\dc01_dcdiag_test.log
Следующая команда PowerShell позволяет вывести только информацию о выполненных тестах:
Dcdiag /s:DC01 | select-string -pattern '\. (.*) \b(passed|failed)\b test (.*)'
Чтобы получить состояние всех контроллеров домена, используйте:
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).
Для вывода расширенной информации, используйте:
repadmin /showrepl *
Для запуска репликации паролей с обычного контроллера домена на контроллер домена на чтение (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.
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:\PS\DcdiagDNStest.txt
Затем откройте полученный отчет:
Notepad c:\PS\DcdiagDNStest.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
Время на прочтение
8 мин
Количество просмотров 169K
Авторское примечание: Статья в первую очередь написана для начинающих системных администраторов, опытные вряд ли почерпнут для себя здесь что-нибудь новое и полезное. Навеяно статьей про 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.
Сбор начальных данных завершен.
Выполнение обязательных начальных проверок
Сервер проверки: Local\dc01-local
Запуск проверки: Connectivity
......................... DC01-LOCAL - пройдена проверка Connectivity
Выполнение основных проверок
Сервер проверки: Local\dc01-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:local\user19 /p:Password
Результат работы
Диагностика сервера каталогов
Выполнение начальной настройки:
* Идентифицирован лес AD.
Сбор начальных данных завершен.
Выполнение обязательных начальных проверок
Сервер проверки: Magadan\DC01-LOCAL
Запуск проверки: Connectivity
......................... DC01-LOCAL - пройдена проверка Connectivity
Выполнение основных проверок
Сервер проверки: Magadan\DC01-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:\logs\adtest.log /ferr:c:\logs\aderrors.log /u:local\user19 /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 это надежный, но в то же время крайне сложный и критичный сервис, от работоспособности которого зависит работа всей вашей сети. Системный администратор должен постоянно мониторить корректность работы Active Directory. В этой статье мы рассмотрим основные методики, позволяющие вам быстро проверить и диагностировать состояние вашего домена Active Directory, контроллеров домена и репликации.
Содержание:
- Проверка состояния контроллеров домена с помощью Dcdiag
- Проверка ошибок репликации между контроллерами домена 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
Следующая команда PowerShell позволяет вывести только информацию о выполненных тестах:
Dcdiag /s:DC01 | select-string -pattern '. (.*) b(passed|failed)b test (.*)'
Чтобы получить состояние всех контроллеров домена, используйте:
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
Для проверки репликации в домене используется встроенная утилита repadmin.
Базовая команда проверки репликации:
repadmin /replsum
Утилита вернула текущий статус репликации между всеми DC. В идеальном случае значение largest delta не должно превышать 1 час (зависит от топологии и настроек частоты межсайтовых репликаций), а количество ошибок = 0. В моем примере видно, что одна из последних репликаций заняла 14 дней, но сейчас все OK.
Чтобы выполнить проверку для всех DC в домене:
repadmin /replsum *
Проверку межсайтовой репликции можно выполнить так:
repadmin /showism
Для просмотра топологии репликации и найденных ошибках, выполните:
repadmin /showrepl
Данная команда проверит DC и вернет время последней успешной репликации для каждого раздела каталога (last attempt xxxx was successful).
Для вывода расширенной информации, используйте:
repadmin /showrepl *
Для запуска репликации паролей с обычного контроллера домена на контроллер домена на чтение (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 — это тоже бывает полезно знать!
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.
Table of Contents
- 1. Check recent changes
- 2. Is everything on the domain controller working as intended?
- 3. Were networking devices altered in any way?
- References
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.
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
Первым делом нужно запустить общий тест:
[code]netdom query fsmo
dcdiag /e /v /q
dcdiag /n:local /e /v /f:c:adtest.log[/code]
Ключи /q можно убрать если нужна информация не только об ошибках.
Проверим здоровье DNS серверов.
Выполним команду на одном из контроллеров домена:
[code]DCDiag /Test:DNS /e /v /s:controller.contoso.com >DcdiagDNS.txt[/code]
дальше полученный отчет открываем:
[code]notepad dcdiagdns.txt[/code]
Если всё хорошо то увидим везде слово PASS:
Если полученные ошибки ручками не получается поправить – пробуем:
[code]DCDiag /Test:DNS /e /v /s:controller.contoso.com /fix[/code]
А также ipconfig /registerdns на контроллерах.
Теперь проверим здоровье репликации Active Directory.
Запускаем общую проверку статуса репликации на контроллере:
[code]repadmin /replsum[/code]
Получаем:
Если значение наиб. дельты не боле часа – с репликацией всё в порядке. Количество сбоев должно быть равно 0.
Если же возникли ошибки то можно использовать следующую команду чтобы посмотреть какой контекст наименования не реплицируется:
[code]repadmin /showreps[/code]
Получим такой вывод:
Диагностика службы времени.
Общая проверка синхронности часов на контроллерах:
[code]w32tm /monitor[/code]
Получим:
Смещение не должно быть больше или меньше 0 целых на всех контроллерах. В нашем случае +2 секунды на одном из них. Как это исправить читаем тут.
Диагностика групповых политик.
Сначала проверим расшаренные папки SYSVOL и Netlogon. Через них распространяются групповые политики.
Проверим расшарены ли эти папки. На каждом контроллере домена:
[code]net share[/code]
Получаем такой результат:
Всё в порядке шары на месте.
Теперь тест dcdiag:
[code]dcdiag /test:netlogons[/code]
Если тест пройден увидим следующее:
В этом случае с шарами всё в порядке.
Чтобы проверить применяются ли GPO можно запустить мастер результатов групповой политики из оснастки Управление групповой политикой (GPMC). Либо выполнить следующую команду:
[code]gpresult /user domainuser /z >gpresult.txt[/code]
поправить тут
[code]notepad gpresult.txt[/code]
В результате откроется отчет в котором можно увидеть ошибки применения к данному пользователя групповых политик.
Источник.
DCDiag: How to Check Domain Controller Health using Powershell. DCDiag is a powerful command line tool used to diagnose problems with domain controllers in a Microsoft Windows Active Directory environment. We use it to check the health of domain controllers, identify errors or inconsistencies, and troubleshoot replication issues. DCDiag also helps administrators detect and resolve problems with DNS configuration, SYSVOL replication, and other critical services required for Active Directory to function correctly.
We examine DCDiag, a potent Microsoft Windows tool. We use it to test DNS services, evaluate the health of domain controllers, and even automatically correct mistakes. Although relatively simple, the tool is strong enough to maintain all our domain controllers’ health.
Shall we start with article DCDiag: How to Check Domain Controller Health using Powershell
DCDiag: How to Check Domain Controller Health using Powershell
Installing the DCDiag Tool
If we are running Windows Server, we should have DCDiag installed. Microsoft built DCDiag into the modern Windows Server versions, from 2012R2 and later versions.
Purpose of the DCDiag Tool
The purpose of DCDiag is to diagnose and troubleshoot issues with domain controllers in a Windows Server environment. It is a command-line tool that performs a wide range of health checks on a domain controller, including tests to DNS, replication, LDAP, security analysing a single or multiple DCs simultaneously within our AD forest or enterprise. Let’s go over a few of the various tests DCDiag does on a domain controller:
- Connectivity tests – DCDiag checks if domain controller is connected to the network and can communicate with other domain controllers.
- DNS tests – reviews whether the domain controller resolves and registers the DNS correctly.
- Replication tests – tests whether the domain controller replicates accurately with other domain controllers.
- Trust tests – DCDiag checks whether the domain controller trusts other domains and whether other domains trust the domain controller.
- LDAP tests – checks whether LDAP queries work properly on the domain controller.
- Kerberos tests – DCDiag checks whether Kerberos authentication works correctly on the domain controller.
- SYSVOL tests – DCDiag checks whether SYSVOL replication works correctly on the domain controller.
- Global Catalog tests – DCDiag checks whether the DC is acting as a Global Catalog server and whether Global Catalog queries are working correctly.
DCDiag Tool Overview
Well, with article DCDiag: How to Check Domain Controller Health using Powershell is a simple command line utility. We run DCDiag on a CMD Prompt or a PowerShell window. Remember to use administrator privileges.
The basic syntax of DCDiag is as follows:
dcdiag.exe /s:[:] [/u:\ /p:*||””]
- /s – The Domain Controller
- /u:\ – The Username
- \p:* – The Password
This basic command line returns the test results showing the primary (connectivity) test and any specified test on the domain controller. To learn how to use DCDiag command along with all its switches, let’s start with the help command:
DCDiag Switch Parameters
To use any of the following switches, append it after the DCDiag command. A summary of the popular command switches:
- /s <ServerName> – Specifies the server’s name to test. If no server name is specified, DCDiag tests the local computer.
- /v – Provides verbose output and additional information about the tests performed.
- /test:<TestName> – Specifies the name of the test to run. We run multiple tests by specifying multiple /test switches.
- /e – Performs a comprehensive set of tests on the specified domain controller.
- /fix – Attempts to fix any problems found during the tests.
- /f:<LogFileName> – Specifies the log file’s name to create.
- /c – Specifies that DCDiag should only perform the tests required for advertising the domain controller’s services.
- /skip:<TestName> – Skips the specified test.
- /l:<LogFileName> – Specifies the log file name to append to rather than overwriting.
- /q – Specifies quiet mode, which suppresses the display of informational messages.
- /test:DNS – Runs DNS tests on the specified domain controller.
- /test:KCC – Runs KCC tests on the specified domain controller.
- /test:Replications – Runs replication tests on the specified dc.
- /test:Advertising – Runs advertising tests on the specified dc.
- /test:Services – Runs service tests on the specified dc.
Above are some of the most used DCDiag command line switches, but many more options are available. We can see a complete list of switches and their definitions by running the help command above.
Try Our Active Directory Health DC Reporting Tool
Try us out for Free, Access to all features. – 200+ AD Report templates Available. Easily customise your own AD reports.
Running DCDiag and Use Cases
To run DCDiag, type the DCDiag command without any switches to do a basic DCDiag test on our local DC (or argument).
Since DCDiag automatically identifies the current (local) DC, neither a domain controller nor administrative credentials are required. In the following section, we discuss multiple use cases using DCDiag’s switch parameters.
Remote DC Health Checks
We must add the /s: switch to the end of the name of the DC and its credentials to run diagnostics on a remote DC (username and password). For instance:
dcdiag.exe /s:dc01 /u:dc01\Administrator /p:password
The DCPromo and the Register in DNS, which are locally executed and not for a domain controller, will not be affected by the /s switch.
Note that when we enter the /u (username) information, we must specify the account name with domain admin permissions and use the correct format: domain/username. So, for example, we append the username (Administrator) with the domain name (dc01): /u:dc01\Administrator.
Checking Health for all DCs
We interconnect each AD site that may contain a collection of DCs to each other. The /a switch is beneficial if we divide the AD into sites. It allows us to run the DCDiag utility simultaneously for all site DCs:
Using DCDiag to Test DNS
No matter what we are testing, the DCDiag tool always checks each domain controller’s DNS registration during the primary connectivity test by default. Also, we might conduct specific DNS tests, such as forwarders, registration records, and others, all of which aid in investigating DNS problems. To test DNS, use the command below:
dcdiag.exe /s:dc01 /test:dns
The following fundamental tests runs by default except for the external name resolution. All DNS results display the DNSBasic test. If there is no value, the /test:dns switch automatically default to /DNSall. Here are some DNS-specific tests that we call when using the DCDiag tool:
- /DNSBasic – Checks if the domain controller’s DNS server is configured correctly and resolves names.
- /DnsDelegation – Tests, if DNS delegations are configured correctly for the domain controller.
- /DnsForwarders – Checks whether DNS forwarders are configured correctly for the domain controller.
- /DnsDynamicUpdate – Checks, whether the domain controller performs dynamic updates to DNS.
- /DnsRecordRegistration – Tests, if domain controller’s DNS registration is up-to-date and accurate.
These tests ensure a domain controller’s DNS configuration is correct and functioning properly. If DCDiag finds any issues during these tests, DCDiag addresses them promptly to avoid potential problems with Active Directory and other network services. A DNS test should look like this:
Customizing DCDiag Results
DCDiag allows us to customize the results by showing us less or more information. Also export the results for later analysis. Here are some examples on how we customize DCDiag reporting.
Run DCDiag in Quiet Mode
The quiet /q switch becomes quite handy, reducing the output size by displaying only the error message list. Here is an example of DCDiag in quiet mode:
The output with the /q is filtered only to errors which looks like this:
Run DCDiag with Verbose Output
By adding the /v verbose flag, run DCDiag with verbose output. It provide us with more information about our daily tasks, such as errors, warnings, informational messages, etc. The /v switch is the quiet /q switch’s opposite.
As previously noted, the DCDiag (without /v) provides sufficient details to identify and resolve any issue with our domain controller, which may be enough in most circumstances. Here is an example of the snippet with the verbose switch:
The output with the /v switch should look like this:
We only recommend the verbose output if we see warnings or errors in the standard summary table and want to investigate the problem in more detail.
Exporting DCDiag Results
The DCDiag utility tool allows us to export the health check results. For example, we save all the test results into a text file by appending the /f switch to the DCDiag command. For example:
dcdiag.exe /s:dc01 f:c:\dcdiag_dc01_test01.txt
Note that we customize the log file’s name and save it in any specific folder. We open the results in notepad or any program that supports .txt files.
We also export results to XLSX or XML. However, this function only works for the /test:dns switch:
dcdiag.exe /test:dns /x or, /test:dns/x:
The DCDiag is solely a diagnostic instrument. Therefore, it performs different tests and exclusively provides its findings. The /fix switch, however, is a terrific switch that tries to remedy the stated issues safely.
Note: Even though DCDiag designs the (fix) switch to make safe automatic repairs, it still changes the domain controller. As a result, examine the test results before using the /f switch, and always create a backup of the DC.
Using DCDiag with PowerShell
There is no DCDiag counterpart in Windows PowerShell. However, we use DCDiag in PowerShell by running the dcdiag.exe command with the appropriate parameters using the Invoke-Expression or Invoke-Command cmdlets. Here’s an example of how to use DCDiag in PowerShell to run the DNS tests:
Invoke-Expression "dcdiag.exe /test:DNS /v"
In this example, we used the Invoke-Expression cmdlet to run the dcdiag.exe command with the /test:DNS parameter to run the DNS tests and the /v parameter to provide verbose output. Of course, we can replace /test:DNS with any other DCDiag test we want to run. Alternatively, we use the Invoke-Command cmdlet to run DCDiag on a remote computer.
Invoke-Command -ComputerName "ServerName" -ScriptBlock { dcdiag.exe /test:DNS /v }
In the previous example, we used the -ScriptBlock parameter with Invoke-Command to specify the code we wanted to run on the remote computer. The -ScriptBlock parameter takes a script block, essentially a block of code enclosed in braces {}.
When we use Invoke-Command with the -ScriptBlock parameter, we execute the script block on the remote computer specified with the -ComputerName parameter, and the script block returns the output to the local computer. Using the -ScriptBlock parameter with Invoke-Command is a powerful way to execute commands or scripts on remote computers. It helps manage large numbers of computers in a network environment, just like how we used the DCDiag tool.
Thank you for reading DCDiag: How to Check Domain Controller Health using Powershell. We shall conclude the article now.
DCDiag: How to Check Domain Controller Health using Powershell Conclusion
In conclusion, DCDiag is an essential tool for administrators who manage Active Directory environments. Providing a comprehensive suite of health checks for domain controllers helps administrators diagnose and troubleshoot issues easily. The ability to perform detailed tests related to DNS, replication, LDAP, security, and more makes DCDiag a valuable tool for ensuring the health and stability of domain controllers and the Active Directory environment.
By incorporating DCDiag into regular maintenance and monitoring routines, administrators help prevent more severe issues from occurring and ensure that their Active Directory environment remains secure and reliable.
Try InfraSOS for FREE
Invite your team and explore InfraSOS features for free
- Free 15-Days Trial
- Easy Setup
- Full Access to Enterprise Plan