Dcdiag не пройдена проверка dns
Чтобы проверить параметры системы доменных имен (DNS), которые могут помешать репликации Active Directory, можно начать с выполнения базового теста, обеспечивающего правильную работу DNS для вашего домена. После выполнения базового теста можно протестировать другие аспекты функций DNS, включая регистрацию записей ресурсов и динамическое обновление.
хотя вы можете выполнять этот тест основных функций DNS на любом контроллере домена, обычно этот тест выполняется на контроллерах домена, на которых могут возникать проблемы репликации, например контроллеры домена, которые сообщают о событиях с идентификаторами 1844, 1925, 2087 или 2088 в журнале DNS службы каталогов Просмотр событий.
Решение
Существует несколько обходных способов решения этих проблем:
Игнорируйте все эти ошибки при запуске DCDIAG.
Чтобы остановить ошибки, связанные с журналом событий, встроите встроенные правила входящих брандмауэров на DCs, чтобы журналы событий можно было получить удаленный доступ:
Удаленное управление журналом событий (NP-In) удаленное управление журналом событий (RPC) Удаленное управление журналом событий (RPC-EPMAP)
Это можно сделать с помощью оснастки брандмауэра Windows с расширенными системами безопасности (WF.MSC), с помощью групповой политики брандмауэра (Конфигурация *компьютера\ Политики\ Windows Параметры* Безопасность Параметры\ Windows брандмауэр с расширенным обеспечением безопасности) или с помощью NETSH.EXE ADVFIREWALL .
Чтобы остановить ошибку службы RPCSS, можно отказаться от тестирования с /SKIP:SERVICES помощью . К этому есть оговорки, см. дополнительные сведения. Эту конкретную ошибку лучше вообще игнорировать, когда она возвращается из DCs Win2003.
Ожидается, что тип поведения этой службы будет 0x10 (изолирован) на Windows Server 2003 и 0x20 (общий) на Windows Server 2008 и более поздней. Не измените его в зависимости от того, что говорит DCDIAG, если только вы не будете запускать версию DCDIAG, которая будет работать с этой ОС. Между Windows Server 2003 и Windows Server 2008 поведение службы RPC изменилось, но в этом svchost.exe еще ничего не было. В Windows Server 2008 R2 к общему процессу svchost была добавлена новая служба RPCEptMapper. Вы можете увидеть, кто будет запускать в этом же процессе, ищите это значение в ключах реестра служб:
%systemroot%\system32\svchost.exe -k RPCSS.
Не измените тип службы на Windows Server 2003, чтобы остановить ошибку. Могут возникнуть непредвиденные проблемы в долгосрочной перспективе, так как это не проверенная конфигурация. Эти проблемы трудно определить или проследить за этой корневой причиной. Долгосрочное решение проблемы службы RPCSS: замените оставшиеся серверы Windows Server 2003 более поздней операционной системой.
Чтобы остановить ошибки OutboundSecureChannels, используйте /skip:outboundsecurechannels . Тесты не допустимы и могут быть протестированы с NETDOM.EXE помощью и NLTEST.EXE .
Проверка регистрации записи ресурса
- Откройте командную строку как администратор. Чтобы открыть командную строку от имени администратора, нажмите кнопку Пуск. В поле Начать поиск введите Командная строка.
- Вверху меню Пуск щелкните правой кнопкой мыши элемент Командная строка и выберите пункт Запуск от имени администратора. Если отобразится диалоговое окно Контроль учетных записей пользователей, подтвердите, что отображаемое в нем действие - то, которое требуется, и нажмите кнопку Продолжить. С помощью средства Dcdiag можно проверить регистрацию всех записей ресурсов, необходимых для расположения контроллера домена, выполнив dcdiag /test:dns /DnsRecordRegistration команду.
Эта команда проверяет регистрацию следующих записей ресурсов в DNS:
- псевдоним (CNAME): запись ресурса на основе глобального уникального идентификатора (GUID), которая находит партнера репликации.
- узел (A): запись ресурса узла, которая содержит IP-адрес контроллера домена.
- Записи ресурсов LDAP SRV: службы (SRV), которые находят LDAP-серверы.
- GC SRV: записи ресурсов службы (SRV), которые находят серверы глобального каталога
- PDC SRV: записи ресурсов службы (SRV), которые находят хозяева операций эмулятора основного контроллера домена.
Для проверки регистрации записи ресурса псевдонима (CNAME) можно использовать следующую процедуру.
Проверка динамического обновления
- Откройте командную строку как администратор. Чтобы открыть командную строку от имени администратора, нажмите кнопку Пуск. В поле Начать поиск введите Командная строка. Вверху меню Пуск щелкните правой кнопкой мыши элемент Командная строка и выберите пункт Запуск от имени администратора. Если отобразится диалоговое окно Контроль учетных записей пользователей, подтвердите, что отображаемое в нем действие - то, которое требуется, и нажмите кнопку Продолжить.
- В командной строке введите следующую команду и нажмите клавишу ВВОД: dcdiag /test:dns /v /s: /DnsDynamicUpdate заменяйте различающееся имя, NetBIOS-имя или имя DNS контроллера домена для < DCName. >В качестве альтернативы можно проверить все контроллеры домена в лесу, введя/e: вместо/s:. Если IPv6 не включен на контроллере домена, следует рассчитывать на сбой записи ресурса узла (AAAA) в тесте, что является нормальным условием, когда IPv6 не включен.
Если безопасные динамические обновления не настроены, для их настройки можно использовать следующую процедуру.
Проверка динамического обновления
Если основная проверка DNS показывает, что записи ресурсов не существуют в DNS, используйте динамический тест обновления, чтобы определить, почему служба сетевого входа в систему не зарегистрировала записи ресурсов автоматически. Чтобы убедиться, что Active Directory зона домена настроена на принятие безопасных динамических обновлений и на регистрацию тестовой записи (_dcdiag_test_record), выполните следующую процедуру. Тестовая запись удаляется автоматически после теста.
Проверка состояния контроллеров домена с помощью Dcdiag
Базовая встроенная утилита для проверки состояния контролеров домена – dcdiag.
Чтобы быстро проверить состояние конкретного контроллера домена AD воспользуйтесь командой:
Данная команда выполняет различные тесты указанного контроллера домена и возвращает статус по каждому тесту (Passed| Failed).
- Connectivity – проверяет регистрацию DC в DNS, выполняет тестовые LDAP и RPC подключения;
- Advertising – проверяет роли и сервисы, опубликованные на DC;
FRSEvent – проверяет наличие ошибок в службе репликации файлов (ошибки репликации SYSVOL); - FSMOCheck – проверяет, что DC может подключиться к KDC, PDC, серверу глобального каталога;
- MachineAccount — проверяет корректность регистрации учетной записи DC в AD, корректность доверительных отношения с доменом;
- NetLogons – проверка наличие прав на выполнение репликации;
Помимо стандартных тестов, которые выполняются по-умолчанию, можно выполнить дополнительные проверки контроллера домена:
- 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
Dcdiag /s:DC01 | select-string -pattern '\. (.*) \b(passed|failed)\b test (.*)'
Чтобы получить состояние всех контроллеров домена, используйте:
Если нужно вывести только найденные ошибки, используйте параметр /q:
dcdiag.exe /s:dc01 /q
В моем примере утилита обнаружила ошибки репликации:
dcdiag.exe /s:dc01 /fix
Чтобы проверить основные функциональные возможности DNS:
на контроллере домена, который требуется протестировать, или на компьютере, входящем в домен, на котором установлены средства доменные службы Active Directory (AD DS), откройте командную строку от имени администратора. Чтобы открыть командную строку от имени администратора, нажмите кнопку Пуск.
В поле Начать поиск введите Командная строка.
Вверху меню Пуск щелкните правой кнопкой мыши элемент Командная строка и выберите пункт Запуск от имени администратора. Если отобразится диалоговое окно Контроль учетных записей пользователей, подтвердите, что отображаемое в нем действие - то, которое требуется, и нажмите кнопку Продолжить.
В командной строке введите следующую команду и нажмите клавишу ВВОД: dcdiag /test:dns /v /s: /DnsBasic /f:dcdiagreport.txt подставьте фактические различающееся имя, NetBIOS-имя или имя DNS контроллера домена для < DCName. >В качестве альтернативы можно проверить все контроллеры домена в лесу, введя/e: вместо/s:. Параметр/f указывает имя файла, которое в предыдущей команде dcdiagreport.txt. Если требуется поместить файл в расположение, отличное от текущего рабочего каталога, можно указать путь к файлу, например/f:c:reportsdcdiagreport.txt.
откройте файл dcdiagreport.txt в Блокнот или в аналогичном текстовом редакторе. чтобы открыть файл в Блокнот, в командной строке введите блокнот dcdiagreport.txt и нажмите клавишу ввод. Если файл помещен в другой рабочий каталог, укажите путь к файлу. Например, если вы поместили файл в к:Репортс, введите Notepad c:reportsdcdiagreport.txt и нажмите клавишу ВВОД.
Перейдите к сводной таблице в нижней части файла. Обратите внимание на имена всех контроллеров домена, которые сообщают о состоянии "предупреждать" или "ошибка" в сводной таблице. Попробуйте определить, существует ли проблемный контроллер домена, выполнив поиск по строке "DC: DCName", где DCName — фактическое имя контроллера домена.
Чтобы проверить изменения конфигурации, повторно выполните команду Dcdiag/test: DNS/v с параметром/e: или/s:, как нужно. Если на контроллере домена не включена версия IP 6 (IPv6), то следует рассчитывать на сбой проверки узла (AAAA) в тесте, но если IPv6 не используется в сети, эти записи не требуются.
Проверка регистрации записи ресурса
Конечный контроллер домена использует запись ресурса DNS-псевдонима (CNAME) для указания партнера по репликации исходного контроллера домена. хотя контроллеры домена, работающие Windows server (начиная с Windows server 2003 с пакетом обновления 1 (sp1)), могут обнаружить исходные партнеры репликации с помощью полных доменных имен или, если это не удается, ожидается, что NetBIOS-намессе запись ресурса псевдонима (CNAME) будет проверяться на предмет правильной работы DNS.
Для проверки регистрации записей ресурсов, включая регистрацию записи ресурса псевдонима (CNAME), можно использовать следующую процедуру.
Проверка регистрации записи ресурса псевдонима (CNAME)
- Откройте оснастку DNS. Чтобы открыть службу DNS, нажмите кнопку Пуск. В окне начать поиск введите днсмгмт. msc и нажмите клавишу ВВОД. Если откроется диалоговое окно Контроль учетных записей пользователей, убедитесь, что оно отображает нужное действие, и нажмите кнопку продолжить.
- Используйте оснастку DNS, чтобы выбрать любой контроллер домена, на котором работает служба DNS-сервера, где на сервере размещается зона DNS с тем же именем, что и домен Active Directory контроллера домена.
- В дереве консоли щелкните зону с именем _msdcs. Dns_Domain_Name.
- В области сведений убедитесь, что имеются следующие записи ресурсов: запись ресурса псевдонима (CNAME) с именем Dsa_Guid. _msdcs. < Dns_Domain_Name >и соответствующую запись ресурса узла (a) для имени DNS-сервера.
Симптомы
Рассмотрим следующий сценарий.
Администрирование среды AD. Может быть смесь Windows Server 2003, Windows Server 2003 R2, Windows Server 2008 и Windows Сервер 2008 R2.
При запуске DCDIAG.EXE /E /A (или) Windows Server 2008 или Windows Server 2008 R2 (включен в операционные системы) вы видите следующие ошибки во /C всех Windows DCs Server 2003:
Начальный тест: Службы
Недействительный тип службы: RpcSs на DCDIAG-2003, текущее значение
WIN32_OWN_PROCESS ожидаемое значение WIN32_SHARE_PROCESS
. Службы тестирования DCDIAG-2003
При запуске (или) Windows Server 2008 или Windows Server 2008 R2 (включен в операционные системы) вы видите следующие ошибки во всех DCDIAG.EXE /E /A /C DC Win2008 и Win2008 R2:
Начальный тест: FrsEvent
Служба репликации файлов журнала событий на сервере
dcdiag-2008.margiestravel.com не удалось получить запрос, ошибка 0x6ba
"Сервер RPC недоступен".
. dcdiag-2008 не удалось тест FrsEvent
Начальный тест: DFSREvent
Репликация журнала событий DFS на сервере
dcdiag-2008r2.margiestravel.com не удалось получить запрос, ошибка 0x6ba
"Сервер RPC недоступен".
. dcdiag-2008r2 не удалось проверить DFSREvent
Начальный тест: KccEvent
Служба каталогов журналов событий на сервере
dcdiag-2008.margiestravel.com не удалось получить запрос, ошибка 0x6ba
"Сервер RPC недоступен".
. dcdiag-2008 не удалось проверить KccEvent
Начальный тест: SystemLog
Система журнала событий на сервере
dcdiag-2008.margiestravel.com не удалось получить запрос, ошибка 0x6ba
"Сервер RPC недоступен".
. dcdiag-2008 не удалось проверить SystemLog
При DCDIAG.EXE /E запуске (или /A или /C) на Windows Server 2003 (включено с установкой вне диапазона средств поддержки):
- Никакие ошибки не регистрируются ни для одного из компьютеров, независимо от оси.
При запуске DCDIAG.EXE /C (который /test:verifyenterprisereferences включает) на Windows Server 2008 или Windows Server 2008 R2, а функциональный режим домена — Windows Server 2008 или выше, а FRSS по-прежнему используется для репликации SYSVOL, вы увидите следующие ошибки:
Начальный тест: VerifyEnterpriseReferences
При проверке различных важных ссылок DN были найдены следующие проблемы. Обратите внимание, что эти проблемы
может быть отчитаться из-за задержки в репликации. Поэтому выполните решение следующих проблем, только если
одна и та же проблема сообщается на всех DCs для данного домена или если проблема сохраняется после репликации
было разумное время для репликации изменений.
[1] Проблема: отсутствует ожидаемое значение
Базовый объект: CN=SRV-01,OU=Domain Controllers,DC=margiestravel,DC=com
Описание базового объекта: "Объект учетной записи DC"
Имя атрибута объекта значения: msDFSR-ComputerReferenceBL
Описание объекта значения: "Объект участника SYSVOL FRS"
Рекомендуемое действие. См. статью База знаний: Q312862
[2] Проблема: недостающее ожидаемое значение
Базовый объект: CN=SRV-02,OU=Domain Controllers,DC=margiestravel,DC=com
Описание базового объекта: "Объект учетной записи DC"
Имя атрибута объекта значения: msDFSR-ComputerReferenceBL
Описание объекта значения: "Объект участника SYSVOL FRS"
Рекомендуемое действие. См. статью База знаний: Q312862
Ошибка LDAP 0x20 (32) — нет такого объекта.
. SRV-01 не удалось проверить VerifyEnterpriseReferences
При запуске (который включает) и указан на DCDIAG.EXE /C /test:outboundsecurechannels Windows Server /testdomain: 2008 или на Windows Server 2008 R2 вы видите следующие ошибки:
Выполнение базовой проверки DNS контроллера домена
Основная проверка DNS проверяет следующие аспекты функциональности DNS:
членство в Enterprise "администраторы" или "эквивалентное" является минимальным требованием для выполнения этих процедур.
Для проверки основных функций DNS можно использовать следующую процедуру.
Дополнительная информация
Тест Windows Server 2008/2008 R2 DCDIAG Services проверяет следующие службы, которые будут запущены, настроены с помощью параметров запуска по умолчанию и настроены с типами процессов по умолчанию:
Это настоящие имена служб в реестре под HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services
RPCSS — запуск автоматически — общий процесс
EVENTSYSTEM — запуск автоматически — общий процесс
DNSCACHE — запуск автоматически — общий процесс
NTFRS — запуск автоматически — собственный процесс
ISMSERV — запуск автоматически — общий процесс
KDC — запуск автоматически — общий процесс
SAMSS — запуск автоматически — общий процесс
SERVER — запуск автоматически — общий процесс
WORKSTATION — запуск автоматически — общий процесс
W32TIME — запуск вручную или автоматически — общий процесс
NETLOGON — запуск автоматически — общий процесс
(Если функциональный уровень домена Windows Server 2008 или более поздний)
DFSR — запуск автоматически — собственный процесс
(Если цель Windows Server 2008 или более поздней)
NTDS — запуск автоматически — общий процесс
(При использовании репликации AD на основе SMTP)
IISADMIN — запуск автоматически — общий процесс
SMTPSVC — запуск автоматически — общий процесс
Причина
Все эти действия ожидаются.
Версии DCDIAG Windows Server 2008/200R2 предназначены для тестирования RPCSS для общего параметра процесса Windows Server 2008, а не предыдущего изолированного параметра процесса, используемого в Windows Server 2003 и более старых операционных системах. Средство не различает OSs для этой службы.
Версии DCDIAG Windows Server 2008/200R2 предполагают, что функциональный уровень домена Windows Server 2008 означает, что DCs реплицирует SYSVOL с DFSR.
Версии Windows Server 2008/200R2 DCDIAG неправильно тестировали состояние доверия
Windows Сервер 2008/2008 R2 не разрешает удаленное подключение к журналу событий на основе правил брандмауэра по умолчанию.
Версия Windows Server 2003 DCDIAG не сообщает об ошибке, если она не может подключиться к журналу событий; он сообщает об этом только в том случае, если он подключается и находит ошибки.
Версия Windows Server 2003 DCDIAG не тестировать конфигурацию службы RPCSS.
Включение безопасных динамических обновлений
- Откройте оснастку DNS. Чтобы открыть службу DNS, нажмите кнопку Пуск.
- В окне начать поиск введите днсмгмт. msc и нажмите клавишу ВВОД. Если откроется диалоговое окно Контроль учетных записей пользователей, убедитесь, что оно отображает нужное действие, и нажмите кнопку продолжить.
- В дереве консоли щелкните правой кнопкой мыши соответствующую зону и выберите пункт Свойства.
- На вкладке Общие убедитесь, что тип зоны — интегрированная Active Directory.
- В меню динамические обновления щелкните только безопасные.
Если записи ресурсов DNS не отображаются в DNS для исходного контроллера домена, вы проверили динамические обновления и хотите зарегистрировать записи ресурсов DNS немедленно, можно принудительно выполнить регистрацию вручную с помощью следующей процедуры. Служба сетевого входа в систему на контроллере домена регистрирует записи ресурсов DNS, необходимые для того, чтобы контроллер домена находился в сети. Служба DNS-клиента регистрирует запись ресурса узла (A), на которую указывает запись псевдонима (CNAME).
21.04.2021
itpro
Active Directory, DNS, PowerShell, Windows Server 2016
комментариев 10
Active Directory это надежный, но в то же время крайне сложный и критичный сервис, от работоспособности которого зависит работа всей вашей сети. Системный администратор должен постоянно мониторить корректность работы Active Directory. В этой статье мы рассмотрим основные методики, позволяющие вам быстро проверить и диагностировать состояние вашего домена Active Directory, контроллеров домена и репликации.
Проверка ошибок репликации между контроллерами домена Active Directory
Для проверки репликации в домене используется встроенная утилита repadmin.
Базовая команда проверки репликации:
Утилита вернула текущий статус репликации между всеми DC. В идеальном случае значение largest delta не должно превышать 1 час (зависит от топологии и настроек частоты межсайтовых репликаций), а количество ошибок = 0. В моем примере видно, что одна из последних репликаций заняла 14 дней, но сейчас все OK.
Чтобы выполнить проверку для всех DC в домене:
Проверку межсайтовой репликции можно выполнить так:
Для просмотра топологии репликации и найденных ошибках, выполните:
Данная команда проверит DC и вернет время последней успешной репликации для каждого раздела каталога (last attempt xxxx was successful).
Для запуска репликации паролей с обычного контроллера домена на контроллер домена на чтение (RODC) используется ключ /rodcpwdrepl.
Опция /replicate позволяет запустить немедленную репликацию указанного раздела каталога на определенный DC.
Для запуска синхронизации указанного DC со всеми партнерами по репликации, используйте команду
Для просмотра очереди репликации:
В идеальном случае очередь должна быть пуста:
Вы также можете проверить состояние репликации с помощью PowerShell. Например, следующая команда выведет все обнаруженные ошибки репликации в таблицу Out-GridView:
Get-ADReplicationPartnerMetadata -Target * -Partition * | Select-Object Server,Partition,Partner,ConsecutiveReplicationFailures,LastReplicationSuccess,LastRepicationResult | Out-GridView
- 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.
Предыдущая статья Следующая статья
Когда истекает пароль пользователя в AD, оповещаем пользователей о необходимости сменить пароль
Настройка двухфакторной аутентификации (2FA) в Windows с помощью MultiOTP
16.02.2018
itpro
Active Directory
Комментариев пока нет
Представьте такую ситуацию: компьютеры в вашей сети не могут найти свой контроллер домена, соответственно пользователи не могут зайти в систему. Всюду возмущенные крики и вопли… Что же делать? В данном случае можно попробовать воспользоваться процедурой траблшутинга процесса поиска контроллера домена (domain controller location process), как одной из базовых методик диагностики проблем входа в систему.
Проверка
Чтобы определить причину проблемы, выполните следующие действия:
1. Убедитесь, что компьютер имеет верные настойки сетевой карты, в том числе IP-адрес, DNS сервер и шлюз по умолчанию. Чтобы отобразить всю эту информацию, откройте окно командной строки и наберите ipconfig /all. Если конфигурация неверная, исправьте ее.
2. С помощью команды Ping проверьте доступность IP адреса маршрутизатора, указанного в качестве дефолтного, доступность DNS сервера и ближайшего контроллера домена в вашем сайте. Если хотя бы до одного из этих элементов связь не проходит, найдите и устраните эту проблему.
5. С помощью команды Nslookup удостоверьтесь, что DNS содержит необходимые и актуальные данные записи для поиска контроллера домена. Если результатом одного из следующих тестов будет ошибка, и вам не будет возвращены правильные имена и ip адреса хостов, перезагрузите контроллеры домена, чтобы заставить их перерегистрироваться в DNS (также убедитесь что DNS настроен на прием динамических обновлений и может создавать записи ресурсов SRV ):
Авторское примечание: Статья в первую очередь написана для начинающих системных администраторов, опытные вряд ли почерпнут для себя здесь что-нибудь новое и полезное. Навеяно статьей про 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 — сам по себе полезный продукт – внутри много утилит, которые просто необходимы в повседневной жизни администратора домена.
После установки пакета команда уже доступна из командной строки.
Но не торопитесь запускать ее сразу, на рабочей станции ничего не получится без указания контроллера домена, к которому надо подключиться. Утилита выдаст соответствующее предупреждение:
Замечательно – мы выяснили – что желательно указать контроллер домена с помощью ключа /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 /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 – внесение безопасных исправлений, но бездумно все-таки этого делать не стоит.
Вот собственно и все что я хотел сегодня рассказать. А как часто вам приходится пользоваться данной утилитой на производстве? Какие альтернативы вы знаете?
Эта статья помогает устранять ошибки, которые возникают при DCDIAG.EXE /E или /A /C командах.
Применяется к: Windows Server 2012 R2
Исходный номер КБ: 2512643
Читайте также: