Dcdiag только ошибки

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

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

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

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

dcdiag /s:DC01

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

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

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

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

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

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

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

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

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

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

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

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

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

dcdiag.exe /s:winitpro.ru /a

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

dcdiag.exe /s:dc01 /q

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

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

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

dcdiag.exe /s:dc01 /fix

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

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

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

repadmin /replsum

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

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

repadmin /replsum *

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

repadmin /showism

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

repadmin /showrepl

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

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

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

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

replmon /syncall <nameDC>

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

repadmin /queue

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

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

Repadmin /showbackup *

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

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

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

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

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

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

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

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

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

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

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

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

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

dcdiag /s:dc01-local.local

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

epic fail

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

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

шоколаде

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

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

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

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

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

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

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

dcdiag /e /v /q

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

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

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

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

Notepad c:PSDcdiagDNStest.txt

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

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

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

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

ipconfig /registerdns

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

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

repadmin /replsum

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

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

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

repadmin /showreps

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

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

repadmin /replsummary [DCname|wildcard]

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

repadmin /showutdvec

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

replmon /syncall msk-dc01

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

w32tm /monitor

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

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

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

net share

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

dcdiag /test:netlogons

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

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

gpresult

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

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

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

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

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

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

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

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

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

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

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

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

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

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

dcdiag.exe /s:winitpro.ru /a

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

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

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

dcdiag.exe /s:dc01 /fix

Проверка ошибок репликации между контроллерами домена 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:

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

Источник

Инвентаризация компьютеров в домене. Лень-двигатель прогресса

Всех приветствую.
Недавно начальство попросило меня подумать над вопросом о сборе информации о комплектации компьютеров у нас в домене. Сначала просьба была только на счет процессоров памяти и жестких дисков. Первая мысль — хождение по отделам и просьба освободить компьютер на минутку. В случае с 1 компьютером не сложно, но если их 1500. Мысли были направленны в сторону PowerShell.

Для начала надо было извлечь список всех компьютеров в домене. В данном примере мой домен Test.lan. Импортируем весь этот список в файл AllComputers.csv.
Для этого не забываем добавить модуль АД для PS. У меня на рабочем месте он прописан в профиле, и вам советую сделать тоже самое:

Здесь надо пояснить, что у меня в домене есть папка Disable, где располагаются учетные записи всех отключенных компьютеров. Если они отключены, то какой смысл к ним стучаться. По этому эту папку мы исключаем из поиска.

Всем понятно, что далеко не все компьютеры, которые находятся в домене, включены, работают или вообще имеют место быть. По этому перед тем, как перейти к проверке, мы проверяем связь с ним. Конечно можно этого не делать, если у вас 100 компьютеров. А если у вас 2000 компьютеров, потеря времени при количестве выключенных компьютеров порядка 800 съест у вас не мало времени. Так же стоит сразу вспомнить компьютеры, к которым у нас нет доступа. Так же смысла стучаться в их дверь нет.

Многие могут возразить:
«Для чего такие сложности? Зачем сначала делать список а потом импортировать его. Не легче ли сразу?»
Согласен, легче. Но иметь перед глазами список компьютеров, согласитесь, приятно. К тому же, список пронумерован. И Вы всегда знаете сколько у вас компьютеров в АД.

Любую информацию (наверное, почти любую) можно узнать, если залезть в WMI объекты, а PS позволяет это делать просто на ура. Так что я сразу углубился в поиски нужных WMI объектов.
Здесь можно поглядеть все классы с их атрибутами.
Убедившись, что компьютер в сети, что доступ у нас к нему есть, смотрим его внутренности:

Вот в принципе и все.
Скрипт можно доработать до своих потребностей.
Так что теперь начальство вряд ли напугает вас инвентаризацией компьютеров.

Источник

Нарушение доверительных отношений между рабочей станцией и контроллером домена (решение)

В сети с парком в 150 машин после обновление операционной системы до MS Windows 7 стала постоянно наблюдаться проблема со входом пользователя в систему. В один прекрасный день пользователь включив компьютер обнаруживал, что войти в систему он не может, при этом видит ошеломляющее по своей информативности сообщение:
«Не удалось установить доверительные отношения между этой рабочей станцией и основным доменом»

Решение тут одно. Вывести машину из домена и ввести обратно. Когда в день эта ситуация стала повторятся больше одного раза, да и просто надоело, задумался о профилактике. И вот тут интернет промолчал. После некоторого времени уныния, а уныние, как известно — грех, было решено копать. В результате пыток раскопок, была получена причина 99% случаев (и я подозреваю что оставшийся 1% просто не признался в той же самой причине). Причина — это служба восстановления при загрузке, которая включается при некорректном завершении работы. На первом же экране диалога служба спрашивает пользователя восстанавливать систему или нет. В случае положительного ответа система откатывается до более раннего состояния и, возможно, бьется sid машины. Как бы то ни было, домен пускать к себе пользователей с такой машину после такой операции не станет. Надеяться на пользователя в таком вопросе бесполезно. Можно просить его отказываться, в случае возникновения такой ситуации, но пользователь с очень большой вероятностью нажмет кнопку «восстановить» а потом разведет руками, мол бес попутал. В общем надо пакетно отключить службу восстановления при загрузке на n-машинах.

Локально решение выглядит, как консольная команда:

Для сети потребуется утилита PsExec из пакета Microsoft Sysinternals PsTools, описание утилиты и сам пакет лежат тут

psexec.exe кладем в одну папку с нашим командным файлом (назовем его broff.cmd)
внутри broff.cmd пишем:

Вот и все. Пользователь больше нам не враг.

Источник

Как установить доверительные отношения между компьютером и основным доменом

Здравствуйте Уважаемые читатели Хабрахабра! В просторах интернета каждый из нас может найти много отдельных статей о не прохождении аутентификации компьютера через домен-контроллер, если точнее сказать, компьютер подключенный к домену теряет связь с ним.

Итак, приступим к изучению этой проблемы.

У многих IT – инженеров, которые работают в больших и малых компаниях, имеются компьютеры с операционной системой Windows 7, 8.1 и т.п. и все эти компьютеры подключены к доменной сети (DC).

Данная проблема происходит из-за того, что сетевой протокол Kerberos не может синхронизироваться и пройти аутентификацию с компьютером (The trust relationship between this workstation and the primary domain failed), который подключен к домену. Тогда мы можем увидеть такую ошибку (см. фото ниже).

После чего мы ищем стороннюю программу, скачиваем ее, создаем загрузочную флешку и локального админа, далее логируемся через него и выходим с домена, добавляем компьютер в Workgroup-у и потом обратно подключаем этот компьютер к домену.

Используя Windows Batch scripting, я хочу создать bat file и автоматизировать процесс создания и добавления локального админа. Единственное, что нам будет необходимо, так это после создания данного файла запустить его.

Открываем наш текстовой редактор, вписываем команду, которая показана внизу.

Пройдем все команды по пунктам для устранения неясных моментов.

• net user admin (вместо слова админ Вы можете добавить любое имя, которое Вас устраивает, по умолчанию ставится administrator, в моем случае это admin).
Далее мы видем пароль, который я там поставил Ww123456(Вы можете поставить любой запоминающийся для Вас пароль).

После мы видем /add /active:yes –добавить и активировать: ДА

• WMIC USERACCOUNT WHERE «Name=’admin’» SET PasswordExpires=FALSE – данная команда означает, что админ, который добавляется, имел постоянный пароль без срока действия (см. картинку ниже).

• Третий и четвертый пункт связаны между собой тем, что по умолчанию, когда создается локальный админ в пункте Member Of стоит Users (см. фото). Нам он не нужен (Users), потому что мы создаем полноправного администратора для нашей ОС. Поэтому четвертая команда — net localgroup Users admin /delete – удаляет Users, а предыдущая команда — net localgroup Administrators admin /add, добавляет администратора (см. фото).

• Последняя команда- netsh advfirewall set allprofiles state off, отключает брандмаузер Windows-a.
Иногда, чтобы установить какую-либо программу или дать какую-либо команду в Windows-e необходимо отключить firewall (После запуска скрипта Вы можете ввести команду- netsh advfirewall set allprofiles state on и включить его заново. У меня по умолчанию стоит off, так как я использую сторонний брандмаузер. Данный момент на усмотрение каждого лично).

Далее идем к нашему блокноту, нажимаем File, save as… (сохранить как. ) вводим имя нашего скрипта( в моем случае: localadmin).Затем ставим точку (.) и пишем формат скрипта bat. Выбираем место, где сохранить данную запись и нажимаем save. Более детально показано на картинке.

Получается вот такой скрипт (см. фото).

Данный скрипт при запуске необходимо открывать от имени администратора:

• Нажимаем правую кнопку мыши и Run as administrator (см. фото).

После запуска скрипта у Вас должно появиться вот такое окошко (см. фото).

Если по каким-либо причинам выйдет ошибка, то в 90% таких случаев это связано с тем, что у Вас образ с которого Вы установили Windows, имеет нелицензионный характер, какие-либо repack или т.п. Скачивайте и используйте лицензионный и проверенный софт.

После удачного добавления локального админа, Вы можете этот скрипт запустить на всех рабочих машинах в Вашем офисе, в которых установлена ОС Windows.

Если у Вас когда-нибудь появится такая ошибка: The trust relationship between this workstation and the primary domain failed- Вам нужно будет только сделать switch user и где логин написать.admin (запомните! В начале до слеша ставится точка!), далее внизу вводите пароль, который Вы добавили в Ваш скрипт (в моем случае: Ww123456). После этого Вы заходите на рабочую ОС.

Осталось снять наш компьютер с домена и добавить в Workgroup-у. Вместо Workgroup-а вписываем любую букву (см. фото).

Далее вводится пароль администратора домена и компьютер просит нас о перезагрузке.
После перезагрузки ещё раз заходим под нашим локальным админом и дальше уже добавляем компьютер к нашему домену. Система в очередной раз требует перезагрузиться и Вуаля! Наш User опять может подключиться к домену без всяких проблем!

P.S – Данная система работает также для серверной части Windows, однако если Вы будете писать такой скрипт для серверов после отключения брандмаузера необходимо будет включить его еще раз (до — netsh advfirewall set allprofiles state off, после netsh advfirewall set allprofiles state on).

Источник

Не удалось установить доверительные отношения между этой рабочей и доменом

Заметим, что представленная далее инструкция подойдёт для компьютеров под управлением Windows 7, 8, XP или 10.

Причины возникновения ошибки

Не все знают, но после подключения к домену компьютеру присваивается уникальный номер, то есть идентификатор безопасности (в сокращении SID). Помимо этого, учётная запись ПК содержит пароль, который меняется или раз в 30 дней, или после длительного отсутствия входа в систему. Нередко человек неправильно выключает компьютер, из-за чего при последующем его запуске на экране появляется предложение восстановить контрольную точку. Если согласиться, то произойдёт откат операционной системы до более раннего состояния.

Как было сказано выше, пароль изменяется раз в 30 дней, поэтому система может вернуться до состояния, когда действовал предыдущий код безопасности. Естественно, пароли на рабочей станции и контроллере будут разными, что приведёт к возникновению рассматриваемой ошибки.

Варианты решения проблемы

Убрать сбой «Не удалось установить доверительные отношения между этой рабочей станцией и основным доменом» не так сложно, как кажется. Главное – рассмотреть все представленные в нашей статье способы, чтобы не пропустить важной и полезной информации.

Удаление компьютера из домена

Этот метод рекомендует использовать компания Microsoft, поэтому в его правильности сомневаться не стоит. Принцип действий сводится к удалению компьютера из домена, а затем к его повторному подключению. Не допустить ошибок поможет пошаговая инструкция, представленная ниже:

Обратите внимание, что если имя рабочей группы не менять, то кнопка «Ок» останется неактивной.

Скорее всего после выполнения представленного руководства рассматриваемая ошибка исчезнет. Если этого не произошло, то не расстраивайтесь и переходите к следующему способу.

Использование утилиты Netdom

Заметим, что утилита Netdom входит в состав Windows Server начиная с 2008 года. Загрузить её на компьютер может любой пользователь, воспользовавшись составом пакета RSAT (Remote Server Administration Tools). Итак, не будет разглагольствовать, а перейдём непосредственно к инструкции:

Предлагаем разобрать предназначение каждой составляющей команды:

Кстати, после выполнения представленной выше команды компьютер перезагружать необязательно. Достаточно выйти из учётной записи администратора, а затем авторизоваться под данными другого пользователя.

Использование PowerShell

Утилита PowerShell имеется в операционной системе Windows 8 и выше. Для более ранних версий необходима ручная установка. Также для корректной работы нужно загрузить на компьютер Net Framework 4 и выше. Если все требования соблюдены, то переходите к подробному руководству:

Стоит отметить, что содержание команды следующее:

После успешного ввода на дисплее появится окошко, в которое нужно вписать имя пользователя и пароль от учётной записи. Перезагружать компьютер не требуется, так как достаточно сменить пользователя системы.

Отключение сетевого кабеля

Конечно, данный метод нельзя применять на постоянной основе, но в качестве временного решения проблемы он отлично подходит. Всё что нужно – отключить сетевой кабель от компьютера, а после выполнить авторизацию в учётной записи с использованием старого пароля.

Обратите внимание, что в большинстве случаев выполнить вход в систему невозможно.

После этого подключите сетевой кабель и выйдите из учётной записи. Затем попытайтесь заново выполнить процедуру авторизации. Если всё прошло успешно, то значит способ сработал. Применять его можно в случае, когда доверительные отношения нарушены или потеряны впервые. Если они отсутствуют постоянно, то не многим удается их восстановить с помощью этого способа.

Видеоинструкция

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

Заключение

Подводя итоги отметим, что исправить ошибку «Не удалось установить доверительные отношения между этой рабочей станцией и основным доменом» можно несколькими способами, каждый из которых имеет свои преимущества и недостатки. Лучше всего выполнить удаление компьютера из домена, при условии, что это возможно. Наша статья подошла к концу, но если у вас остались какие-либо вопросы, то обязательно напишите их в комментариях. Наша редакция даст на них ответы в кратчайшие сроки.

Источник