Авторское примечание: Статья в первую очередь написана для начинающих системных администраторов, опытные вряд ли почерпнут для себя здесь что-нибудь новое и полезное. Навеяно статьей про 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 – внесение безопасных исправлений, но бездумно все-таки этого делать не стоит.
Вот собственно и все что я хотел сегодня рассказать. А как часто вам приходится пользоваться данной утилитой на производстве? Какие альтернативы вы знаете?
update 1: Что-то вспомнилось, опять же из личного опыта: если у вас большой домен, связанный небыстрыми (например, спутниковыми) каналами связи — утилита будет выдавать массу ошибок в случае ее отсутствия — чаще всего, что недоступен RPC. Это нормально, и про это надо знать. Если большинство тестов оканчивается подобным сообщением — значит нет связи, необходимо применять меры по устранению сбоя. Вторая часто распространенная проблема — ошибки в DNS — но это тема уже для отдельной статьи.
p.s. к update 1 -dcdiag /fix — в том числе регистрирует по новой записи в dns службы netlogon — это тоже бывает полезно знать!
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. При подготовке статьи я столкнулся с
Полностью описывать результаты работы команды я не вижу смысла. Это прекрасно описано в помощи к утилите (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 — это тоже бывает полезно знать!
