Как проверить доступность домена active directory
Перейти к содержимому

Как проверить доступность домена active directory

  • автор:

Проверка здоровья контроллеров домена Active Directory и репликации

date21.04.2021
useritpro
directoryActive Directory, DNS, PowerShell, Windows Server 2016
commentsкомментариев 16

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

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

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

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

Данная команда выполняет различные тесты указанного контроллера домена и возвращает статус по каждому тесту (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;
  • И т.д.

dcdiag проверка состояния контроллера домена active directory

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

  • 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

dcdiag проверка службы DNS в домене

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

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

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

dcdiag /s:DC01 /v >> c:\ps\dc01_dcdiag_test.log

расширенная диагностика состояния контроллера домена командой dcdiag

Dcdiag /s:DC01 | select-string -pattern ‘\. (.*) \b(passed|failed)\b test (.*)’

powershell скрипт - вывести информацию о тестах контроллера домена

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

dcdiag.exe /s:winitpro.ru /a

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

dcdiag.exe /s:dc01 /q

dcdiag вывести только ошибки

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

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

dcdiag.exe /s:dc01 /fix

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

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

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

repadmin /replsum проверка репликации в домене

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

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

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

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

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

repadmin /showrepl проверка последней успешной репликации между контроллерами домена

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

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

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

replmon /syncall <nameDC>

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

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

repadmin /queue - очередь репликации

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

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

проверка репликации с помощью Get-ADReplicationPartnerMetadata

html отчет со статусом репликации в домене

  • 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

проверка служб ADDS на контроллере домена

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

Предыдущая статьяПредыдущая статья Следующая статья Следующая статья

DCDIAG – диагностика здоровья AD одной утилитой

Авторское примечание: Статья в первую очередь написана для начинающих системных администраторов, опытные вряд ли почерпнут для себя здесь что-нибудь новое и полезное. Навеяно статьей про 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 я запускал из-под обычной учетной записи домена, без администраторских прав. Понятно – что часть проверок пройти под ней просто невозможно. Поэтому, что бы получить правильную диагностику, необходимо запускать утилиту с административными полномочиями – либо запустить командную строку от имени администратора, либо использовать ключи /u: имя домена\имя пользователя и /p: пароль. Попробуем:
dcdiag /s:dc01-local /u:local\user19 /p:Password

ак видим, проверки пройдены почти все – кроме проверки 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 – внесение безопасных исправлений, но бездумно все-таки этого делать не стоит.

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

Checking Active Directory Domain Controller Health and Replication

Active Directory is a reliable, but complex and critical service, and the operability of the whole enterprise network depends on it. A system administrator should constantly check if Active Directory works correctly. In this article, we will go over the main methods of how to check and diagnose the health of your Active Directory domain, domain controllers, and replication.

How to Check AD Domain Controller Health Using Dcdiag?

Dcdiag is a basic built-in tool to check Active Directory domain controller health. To quickly check the state of an AD domain controller, use the command below:

The command runs different tests against the specified domain controller and returns a state for each test (Passed/Failed).

  • Connectivity – checks if the DC is registered in DNS, establishes test LDAP and RPC connections;
  • Advertising – checks roles and services published on the DC;
  • FRSEvent – checks if there are any errors of file replication service (SYSVOL replication errors);
  • FSMOCheck – checks if the DC can connect to KDC, PDC, and Global Catalog server;
  • MachineAccount — checks if the DC account is registered in AD correctly and if the domain trust relationship is correct;
  • NetLogons – checks the logon privileges to allow replication to proceed;
  • Replications – checks the state of replication between domain controllers and if there are any errors;
  • KnowsOfRoleHolders – checks the availability of the domain controllers with FSMO roles;
  • Services – checks if services on the domain controllers are running;
  • Systemlog – checks if there are any errors in the DC logs;
  • Etc.

Testing AD domain controllers health using dcdiag.exe

Besides default tests, you can run additional domain controller checks:

  • Topology – checks if KCC has generated full topology for all DCs
  • CheckSecurityError
  • CutoffServers – finds a DC that is not replicated since its partner is unavailable
  • DNS – 6 DNS checks are available ( /DnsBasic , /DnsForwarders , /DnsDelegation , /DnsDymanicUpdate , /DnsRecordRegistration , /DnsResolveExtName )
  • OutboundSecureChannels
  • VerifyReplicas – checks if the application partitions are replicated correctly
  • VerifyEnterpriseReferences

For example, to check if DNS is working correctly on all domain controllers, use the following command:

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

dcdiag dns tests

It will result in a summary table showing test results on how DNS resolves names on all DCs (if it is OK, you will see Pass in every cell). If you see Fail, you need to run this test against the specified DC:

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

To get more information from domain controller test results and save it to a text file, use this command:

dcdiag /s:DC01 /v >> c:\ps\dc01_dcdiag_test.log

dcdiag log file

Dcdiag /s:DC01 | select-string -pattern ‘\. (.*) \b(passed|failed)\b test (.*)’

Dcdiag summary report powershell script

To get the state of all domain controllers, use:

dcdiag.exe /s:woshub.com /a

If you want to display only the errors you have found, use the /q option:

dcdiag.exe /s:dc01 /q

dcdiag failed test

In my example, the tool has detected some replication errors:

To make dcdiag automatically fix the Service Principal Names errors for the DC account, use the /fix option:

dcdiag.exe /s:dc01 /fix

Checking Active Directory Replication Errors Between DCs

The built-in repadmin tool is used to check replication in the Active Directory domain.

Here is the basic command to check AD replication:

repadmin /replsummary - checking active directory replication

The tool has returned the current replication status between all DCs. Ideally, the largest delta value should be less than 1 hour (depends on the AD topology and intersite replication frequency settings), and the number of errors = 0. In my example, you can see that one of the latest replication took 14 days, but now it is OK.

To check replication for all DCs in the domain:

To test intersite replication:

To view the replication topology and errors (if any), run this command:

The command will check the DCs and return the time and date of the last successful replication for each directory partition ( last attempt xxxx was successful ).

Repadmin /showrepl - replication status. show when the domain controller last attempted to perform inbound replication of Active Directory

To run password replication from a writable domain controller to a read-only domain controller (RODC), the /rodcpwdrepl option is used.

The /replicate option starts the replication of the specified directory partition to a specific DC immediately.

To synchronize a specified DC with all its replication partners, use the command below:

replmon /syncall <nameDC>

To view the replication queue:

Ideally, the replication queue should be empty.

Monitoring AD replication queues (repadmin /queue)

You can also check the replication state using PowerShell. For example, the following command will display all replication errors it finds in the Out-GridView table:

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

Get-ADReplicationPartnerMetadata shows an replication partner metadata object for each of its replication partners (domain controllers)

powershell script: get replication health summary report

You can also check the state of ADDS basic services on a domain controller using the Get-Service cmdlet:

  • Active Directory Domain Services ( ntds )
  • Active Directory Web Services ( adws ) – all cmdlets from the AD PowerShell module connect to this service
  • DNS ( dnscache and dns )
  • Kerberos Key Distribution Center ( kdc )
  • Windows Time Service ( w32time )
  • NetLogon ( netlogon )

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

get adds services states on a domain controller

So, in this article, we have shown basic tools, commands, and PowerShell scripts you can use to diagnose the health of your Active Directory domain. You can use them in all supported Windows Server versions, including the domain controllers running in the Server Core mode.

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

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

Итак, для диагностики работы контроллера домена используется специализированная утилита — DCDIAG

dcdiag-1

Лучше всего выполнять проверку локально, т.е. на самом контроллере домена от учетной записи с правами администратора. Если же существует несколько DC, то на помощь придет команда автоматической проверки нескольких серверов (для удобства данные выводятся в текстовые файлы):

dcdiag /n:local /e /v /f:c:\logs\adtest.log /ferr:c:\logs\aderrors.log /u:local\user19 /p:Password

  • /n:local — имя домена
  • /e автоматическая проверка всех серверов с ролью DC
  • /v расширенная проверка
  • /f — записать лог файл
  • /ferr — записать лог файл ошибок (актуально для WinSRV2003, в новых версиях — неактуально)
  • /u имя домена и пользователя

Теперь перейдем к анализу и проверки репликаций Active Directory. Межсайтовая топология отслеживается так:

Данную информацию можно просмотреть и через графическую оснастку, открыв «Active Directory Sites and Services».

Отображение партнеров по репликации и времени последней репликации выполняется следующей командой:

Следующей командой можно проверить

repadmin /replsummary [nameDC|wildcard]

При этом ключ /replsummary используется для быстрой проверки репликации на конкретном сервере, а ключ wildcard — для всех серверов.

Проверка USN записей:

Синхронизация конкретного контроллера домена с участниками репликации:

Представленными выше командами можно выполнить диагностику работы контроллера дома, а также репликаций AD. Особенно актуальны такие операции при замене DC, описанных, например, в предыдущей статье — Правильное удаление вышедшего из строя контроллера домена из Active Directory.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *