Nslookup (name server lookup) это утилита командной строки, которую можно использовать для диагностики службы DNS, проверки DNS записей и серверов и обнаружения проблем, связанных с разрешением имен в системе DNS. Утилита nslookup изначально разработана в составе пакета BIND и в дальнейшем портирована на Windows. На данный момент утилита Nslookup входит в состав всех поддерживаемых версий Windows.
Утилита Nslookup умеет отправлять запросы на DNS сервер, который указан в настройках вашего сетевого подключения. Этот адрес считается DNS севером по умолчанию (default server). Пользователь может указать адрес любого другого доступного DNS сервера, в результате чего все следующие DNS запросы будут выполнятся уже на нем.
С помощью утилиты nslookup вы можете узнать IP адрес любого сервера по его DNS имени, выполнить обратное преобразование, получить информацию о различных DNS записях домена.
Вы можете использовать утилиту nslookup в интерактивном или не-интерактивном режиме.
Чтобы выполнить DNS запрос с помощью nslookup в неинтерактивном режиме, откройте командную строку и выполните команду:
Nslookup vmblog.ru
В данном примере мы запросили IP адрес сервера vmblog.ru. Утилита nslookup обратилась к DNS серверу (указан в строке Server) и он вернул, что этому имени соответствует IP адрес 37.252.2.22.
Такой ответ говорит о том, что ваш DNS сервер доступен и работает штатно, выполняя запросы на разрешение DNS имен.
Если же вы получит ответ вида:
Server: dns1.someserver.com
Address: хх.хх.хх.хх
*** dns1.contoso.com can't find vmblog.ru: Non-existent domain
Это означает, что для данного имени не найдено записей в DNS зоне.
В том случае, если ваш DNS сервер недоступен или не отвечает, вы получите ошибки DNS request timed out.
В этом случае проверьте, указан ли у вас правильный адрес DNS сервера и нет ли проблем с сетевым подключением у провайдера.
Строка Non-authoritative answer (Не заслуживающий доверия ответ)означает, что DNS сервер, который выполнил запрос не является владельцем зоны vmblog.ru (в его базе нет записей об этом домене), а для выполнения разрешения имени использовался рекурсивный запрос к другому DNS серверу.
Можно обратиться к авторитетному серверу, указав его адрес непосредственно в параметрах утилиты nslookup. Например, чтобы выполнить разрешение имени на DNS сервере, который содержит данный домен (authoritative server), используйте команду:nslookup vmblog.ru ns1.vmblog.ru
При запуске nslookup без параметров, утилита переходит в интерактивный режим. В этом режиме вы можете выполнять различные команды. Полный список доступных внутренних команд утилиты nslookup можно вывести, набрав знак вопроса.
Совет. Обратите внимание, что команды утилиты nslookup являются регистрозависимыми.
Для завершения работы с nslookup наберите команду exit
и нажмите Enter.
Чтобы найти DNS сервера, которые отвечают за конкретный домен (authoritative servers), выполните команды:
set query=ns
vmblog.ru
Вы можете выполнить и обратное преобразование (получить DNS имя по IP адресу), для этого просто наберите IP адрес в интерактивной строке nslookup и нажмите Enter.
Вы можете задать тип DNS записей, которые должна вернуть утилита nslookup. Например, чтобы перечислить все почтовые сервера, заданные для определенного домена, выполните команду:
nslookup -type=mx gosuslugi.ru
Не заслуживающий доверия ответ:
gosuslugi.ru MX preference = 20, mail exchanger = mx68.gosuslugi.ru
gosuslugi.ru MX preference = 10, mail exchanger = mx.gosuslugi.ru
mx68.gosuslugi.ru internet address = 109.207.8.100
mx.gosuslugi.ru internet address = 109.207.1.100
Как вы видите, у данного домене 2 MX записи с приоритетами 10 и 20 (Чем меньше число, тем выше приоритет адреса). Если запись MX не отображается, скорее всего они просто не настроены для данного домена.
Чтобы вывести все DNS записи в доменной зоне, выполните команду:
nslookup -type=any gosuslugi.ru
gosuslugi.ru nameserver = ns2.gosuslugi.ru
gosuslugi.ru nameserver = ns8-l2.nic.ru
gosuslugi.ru nameserver = ns1.gosuslugi.ru
gosuslugi.ru nameserver = ns4-l2.nic.ru
gosuslugi.ru MX preference = 10, mail exchanger = mx.gosuslugi.ru
gosuslugi.ru MX preference = 20, mail exchanger = mx68.gosuslugi.ru
ns2.gosuslugi.ru internet address = 213.59.255.175
ns8-l2.nic.ru internet address = 91.217.21.1
ns1.gosuslugi.ru internet address = 109.207.2.218
ns4-l2.nic.ru internet address = 91.217.20.1
mx.gosuslugi.ru internet address = 109.207.1.100
mx68.gosuslugi.ru internet address = 109.207.8.100
Использование опции отладки (debug) позволяет получить дополнительную информацию, содержащуюся в заголовках запросов клиента и ответов сервера (время жизни, флаги, типы записей и т.п.):
set debug
Active Directory это надежный, но в то же время крайне сложный и критичный сервис, от работоспособности которого зависит работа всей вашей сети. Системный администратор должен постоянно мониторить корректность работы Active Directory. В этой статье мы рассмотрим основные методики, позволяющие вам быстро проверить и диагностировать состояние вашего домена Active Directory, контроллеров домена и репликации.
Содержание:
- Проверка состояния контроллеров домена с помощью Dcdiag
- Проверка ошибок репликации между контроллерами домена Active Directory
Проверка состояния контроллеров домена с помощью Dcdiag
Базовая встроенная утилита для проверки состояния контролеров домена – dcdiag.
Чтобы быстро проверить состояние конкретного контроллера домена AD воспользуйтесь командой:
dcdiag /s:DC01
Данная команда выполняет различные тесты указанного контроллера домена и возвращает статус по каждому тесту (Passed| Failed).
Типовые тесты:
- Connectivity – проверяет регистрацию DC в DNS, выполняет тестовые LDAP и RPC подключения;
- Advertising – проверяет роли и сервисы, опубликованные на DC;
FRSEvent – проверяет наличие ошибок в службе репликации файлов (ошибки репликации SYSVOL); - FSMOCheck – проверяет, что DC может подключиться к KDC, PDC, серверу глобального каталога;
- MachineAccount — проверяет корректность регистрации учетной записи DC в AD, корректность доверительных отношения с доменом;
- NetLogons – проверка наличие прав на выполнение репликации;
- Replications – проверка статуса репликации между контроллерами домена и наличие ошибок;
- KnowsOfRoleHolders – проверяет доступность контроллеров домена с ролями FSMO;
- Services – проверяет, запущены ли на контроллере домена необходимые службы;
- Systemlog – проверяет наличие ошибок в журналах DC;
- И т.д.
Полное описание всех доступных тестов есть здесь.
Помимо стандартных тестов, которые выполняются по-умолчанию, можно выполнить дополнительные проверки контроллера домена:
- Topology – проверяет, что KCC сгенерировал полную топологию для всех DC;
- CheckSecurityError
- CutoffServers – находит DC, который не получает репликацию из-за того, что партнёр недоступен;
- DNS – доступны 6 проверок службы DNS (/DnsBasic, /DnsForwarders, /DnsDelegation, /DnsDymanicUpdate, /DnsRecordRegistration, /DnsResolveExtName)
- OutboundSecureChannels
- VerifyReplicas – проверяет корректность репликации разделов приложения
- VerifyEnterpriseReferences
Например, чтобы проверить корректность работы DNS на всех контроллерах домена, используйте команду:
dcdiag.exe /s:DC01 /test:dns /e /v
В результате должна появится сводная таблица по проверкам разрешения имен службой DNS на всех контроллерах (если все ОК, везде должно быть Pass). Если где-то будет указано Fail, нужно выполнить проверку этого теста на указанном DC:
dcdiag.exe /s:DC01 /test:dns /DnsForwarders /v
Чтобы получить расширенную информацию по результатам тестов контроллера домена и сохранить ее в текстовый файл, используйте команду:
dcdiag /s:DC01 /v >> c:\ps\dc01_dcdiag_test.log
Следующая команда PowerShell позволяет вывести только информацию о выполненных тестах:
Dcdiag /s:DC01 | select-string -pattern '\. (.*) \b(passed|failed)\b test (.*)'
Чтобы получить состояние всех контроллеров домена, используйте:
dcdiag.exe /s:winitpro.ru /a
Если нужно вывести только найденные ошибки, используйте параметр /q:
dcdiag.exe /s:dc01 /q
В моем примере утилита обнаружила ошибки репликации:
There are warning or error events within the last 24 hours after the SYSVOL has been shared. Failing SYSVOL replication problems may cause Group Policy problems. ......................... DC01 failed test DFSREvent
Чтобы утилита dcdiag попробовала автоматически исправить ошибки в Service Principal Names для данной учетной записи DC, используйте параметр /fix:
dcdiag.exe /s:dc01 /fix
Проверка ошибок репликации между контроллерами домена Active Directory
Для проверки репликации в домене используется встроенная утилита repadmin.
Базовая команда проверки репликации:
repadmin /replsum
Утилита вернула текущий статус репликации между всеми DC. В идеальном случае значение largest delta не должно превышать 1 час (зависит от топологии и настроек частоты межсайтовых репликаций), а количество ошибок = 0. В моем примере видно, что одна из последних репликаций заняла 14 дней, но сейчас все OK.
Чтобы выполнить проверку для всех DC в домене:
repadmin /replsum *
Проверку межсайтовой репликции можно выполнить так:
repadmin /showism
Для просмотра топологии репликации и найденных ошибках, выполните:
repadmin /showrepl
Данная команда проверит DC и вернет время последней успешной репликации для каждого раздела каталога (last attempt xxxx was successful).
Для вывода расширенной информации, используйте:
repadmin /showrepl *
Для запуска репликации паролей с обычного контроллера домена на контроллер домена на чтение (RODC) используется ключ /rodcpwdrepl.
Опция /replicate позволяет запустить немедленную репликацию указанного раздела каталога на определенный DC.
Для запуска синхронизации указанного DC со всеми партнерами по репликации, используйте команду
replmon /syncall <nameDC>
Для просмотра очереди репликации:
repadmin /queue
В идеальном случае очередь должна быть пуста:
Проверьте время создания последней резервной копии текущего контроллера домена:
Repadmin /showbackup *
Вы также можете проверить состояние репликации с помощью PowerShell. Например, следующая команда выведет все обнаруженные ошибки репликации в таблицу Out-GridView:
Get-ADReplicationPartnerMetadata -Target * -Partition * | Select-Object Server,Partition,Partner,ConsecutiveReplicationFailures,LastReplicationSuccess,LastRepicationResult | Out-GridView
Можете дополнительно с помощью Get-Service проверить состояние типовых служб на контроллере домена:
- Active Directory Domain Services (ntds)
- Active Directory Web Services (adws) – именно к этой службе подключаются все командлеты из модуля AD PowerShell
- DNS (dnscache и dns)
- Kerberos Key Distribution Center (kdc)
- Windows Time Service (w32time)
- NetLogon (netlogon)
Get-Service -name ntds,adws,dns,dnscache,kdc,w32time,netlogon -ComputerName dc03
Итак, в этой статье мы рассмотрели базовые команды и скрипты, которые можно использовать для диагностики состояния вашего домена Active Directory. Вы можете использовать их во всех поддерживаемых версия Windows Server, в том числе на контроллерах домена в режиме Server Core.
При неполадках в разрешении имен DNS в среде Microsoft Active Directory (AD) нередко возникают проблемы. DNS — краеугольный камень для среды AD, и без корректного разрешения имен операции могут прерваться или застопориться. Вероятно, проблема разрешения имен появилась со временем из-за постепенного отхода от надежной древовидной иерархической схемы. Ниже приводятся основные рекомендации и описываются средства диагностики, позволяющие предотвращать или решать проблемы DNS.
Рекомендация 1. Пространство имен DNS должно отражать смежную древовидную иерархию
Пространство имен DNS Интернета имеет древовидную иерархическую организацию, управление которой делегировано администраторам службы DNS, отвечающим за различные «ветви» пространства имен DNS (IETF RFC 1034, RFC 1032). Подобно своим собратьям по Интернету, администраторы DNS корпоративных сетей должны следовать иерархической древовидной концепции. Наличие фрагментарности или несвязностей в пространстве имен корпоративной сети порождает сложности в виде добавления серверов пересылки, зон-заглушек и/или дополнительных зон.
Рассмотрим случай, когда одна компания приобретает другую и каждая из них имеет независимое пространство имен. Эти пространства должны быть функционально объединены с использованием доверительных отношений Windows Server. Предлагаемый подход заключается в создании безопасной виртуальной частной сети (VPN) между средами двух компаний в корне каждого отдельного непрерывного пространства имен. Передача запросов об именах по сети VPN в пространство имен на противоположном конце «VPN-туннеля» осуществляется с использованием серверов пересылки, как показано на рисунке. Любые запросы, не удовлетворяющие критериям условий сервера пересылки, направляются на серверы DNS поставщика услуг Интернета (ISP). Серверы DNS, настроенные на пересылку по условию и расположенные на корневом уровне одного из двух непрерывных пространств имен, направляют запросы на конкретный сервер DNS, расположенный в другом непрерывном пространстве имен. На этом сервере DNS в кэше накапливается информация о пространстве имен, что снижает необходимость в рекурсии.
|
Рисунок. Использование пересылки по условию между раздельными пространствами имен DNS корпоративной сети |
Вместо использования серверов пересылки некоторые администраторы предпочитают создавать зоны-заглушки на серверах DNS в доменах верхнего уровня корпоративной сети, например domain1.local и domainA.local. Зоны-заглушки содержат только те записи, которые необходимы для определения доверительных серверов DNS для подчиненной зоны, и имеют значение скорее тогда, когда зоны не хранятся в AD. Зоны-заглушки имеют значение, когда необходимо поддерживать информированность сервера DNS в родительской зоне о доверительных серверах DNS в дочерней зоне. Зоны-заглушки повышают сложность, поскольку ответ службы DNS такой зоны на запрос об имени содержит информацию обо всех заслуживающих доверия серверах DNS в домене. Цель же состоит в организации работоспособной и простой для диагностики инфраструктуры DNS.
Рекомендация 2. Нужно знать, где хранится информация DNS
Данные зоны DNS могут размещаться в хранилище AD или в файловой системе в папке c:\%systemroot%\system32\dns. Настоятельно рекомендуется сохранять информацию зоны в AD, а затем выполнять ее репликацию на каждом сервере DNS в домене (DomainDNSZones) или в лесу (ForestDNSZones). Оптимальный вариант — сохранение данных DNS на каждом сервере DNS домена с последующей передачей этой информации в родительскую зону. Пересылка данных DNS настраивается так, чтобы серверы DNS доменов child1.domain1.local и child2.domain1.local направляли данные на серверы DNS домена domain1.local. В родительском домене осуществляется делегирование для каждого дочернего домена.
Рекомендация 3. Определить, относится ли проблема DNS к сфере регистрации или к сфере разрешения имен
Для разрешения имени необходимо, чтобы это имя было зарегистрировано в какой-либо зоне на сервере DNS. В среде Windows разные службы регистрируют различные записи. В Windows 7, Windows Vista, Windows Server 2008 R2 и Server 2008 записи A и PTR регистрирует служба клиента DNS. В Windows XP и Windows Server 2003 эти записи регистрирует служба клиента DHCP.
Интервал регистрации — 24 часа, за исключением случаев, когда регистрацию выполняет сервер DHCP; в таких случаях регистрация должна выполняться при обновлении аренды адреса клиента DHCP.
В случае Server 2008 R2, Server 2008 и 2003 за регистрацию некоторых дополнительных записей отвечает служба Netlogon. Журнал записей, регистрируемых службой Netlogon, хранится в папке %SystemRoot%\System32\Config\Netlogon.dns. В случае Server 2008 контроллеры домена (DC) динамически регистрируют от 15 до 30 записей SRV каждый час, а в случае 2003 служба Netlogon выполняет регистрацию каждые 24 часа.
В Server 2008 служба кластеров регистрирует ресурс «сетевое имя» кластера при включении этого ресурса в работу. Запись обновляется как минимум один раз каждые 24 часа. Чтобы определить, все ли IP-адреса ресурса «сетевое имя» зарегистрированы в DNS, можно использовать параметр RegisterAllProvidersIP. Более подробную информацию можно найти в статье Microsoft по адресу support.microsoft.com/kb/947048.
Проблема относится к сфере регистрации DNS. Если в DNS отсутствуют записи DNS, с помощью интерфейса редактора Active Directory (ADSI Edit) выясните, не связано ли это просто c отсутствием их отображения в графическом окне консоли DNS или AD. Убедитесь в существовании записей в AD, следуя шагам, описанным в статье по адресу support.microsoft.com/kb/867464. Если записи отсутствуют, установите сетевой монитор на системе, выполняющей регистрацию записей DNS, и выполните сетевую трассировку при попытке зарегистрировать записи A, PTR или SRV. Чтобы инициировать регистрацию записей A и PTR, введите команду
ipconfig/registerdns
Для регистрации записи SRV введите команду
c:\net stop netlogon && net start netlogon
Остановите сетевую трассировку и выполните фильтрацию трафика DNS. При отсутствии регистрационных данных сетевой трассировки проверьте, запущена ли служба, отвечающая за регистрацию (клиент DHCP, клиент DNS, Netlogon, Cluster), и проанализируйте журналы событий. Если это не поможет, обратитесь в группу технической поддержки Microsoft.
Проблема относится к сфере разрешения DNS. Если техническая проблема не относится к сфере регистрации записей DNS, смените метод диагностики и проанализируйте разрешение имен DNS. Выполните проверку связи с целевым объектом по полному доменному имени (FQDN) на предмет успеха или отказа. В случае отказа связи по имени, но не по IP-адресу, убедитесь в правильности настроек сервера DNS в свойствах протокола TCP/IP системы, инициирующей запрос. Затем запустите сетевую трассировку и очистите кэш распознавателя с помощью команды
c:\ipconfig/flushdns
Вновь проверьте связь с целевым объектом по FQDN (например, ping server.domain1.local), остановите сетевую трассировку и проверьте наличие исходящего запроса DNS и/или входящего ответа DNS. Задача состоит в том, чтобы определить, связана ли проблема с доставкой запроса на сервер DNS, либо, если сервер DNS получает запрос — c отсутствием ответа или же с его доставкой инициатору запроса DNS.
Рекомендация 4. Использование средств диагностики DNS
Для анализа проблем в DNS необходимо иметь следующие средства диагностики: DNSLint, DCDiag и NSlookup.
DNSLint. Утилита DNSLint реализует три функциональных теста с выдачей результатов в отчете в формате HTML. Тесты предназначены для выявления проблемы некорректного делегирования зон (lame delegation), проверки записей DNS, необходимых для успешного выполнения репликации AD, и контроля определяемого пользователем набора записей DNS на нескольких серверах DNS. Для тестирования доменных имен и получения результатов для диагностики проблемы некорректного делегирования в команде dnslint укажите параметр /d. Для задания IP-адреса сервера DNS, который является доверительным для данного домена, укажите /s. Для определения возможности разрешения записи DNS, для которой требуется репликация в лесу AD, укажите /ad. Более подробную информацию можно найти в статье «Description of the DNSLint utility» по адресу support.microsoft.com/kb/321045.
DCDiag. Команду dcdiag можно запустить с использованием параметра /test: DNS. Варианты теста включают основной тест DNS и тесты для серверов пересылки и корневых ссылок, делегирования, динамических обновлений DNS, регистрации записей DNS и имен Интернета.
Проверьте состояние работоспособности контроллера домена:
DCDIAG/TEST: DNS/v/s: /f:
Проверьте состояние работоспособности всех контроллеров домена в лесу:
DCDIAG/TEST: DNS/f/e/f:
Проверьте способность контроллера домена регистрировать записи DNS-локатора DC:
DCDIAG/TEST: RegisterInDNS /DnsDomain: /v/f:
В приведенных выше командах параметр /v задает вывод детальных данных, /s — локальное выполнение, /f — прямой вывод в файл, /e — тестирование всех серверов.
Для Windows Server 2003 SP2 следует пользоваться утилитой DCDiag, включенной в SP2, в соответствии с описанием (support.microsoft.com/kb/926027). Для Server 2008 и Server 2008 R2 выполните установку DCDiag: пройдя по пунктам меню Server Manager, Features, Add Features, Remote Server Administration Tools, Role Administration Tools, Select DNS Server Tools, Next, Install.
NSlookup. Хорошо известная команда диагностики DNS. Для просмотра вариантов синтаксиса NSlookup нужно запустить команду NSlookup из командной строки, а затем ввести help. Следует иметь в виду, что NSlookup имеет собственный встроенный разрешитель имен в исполняемом файле, поэтому не использует разрешитель операционной системы.
Рекомендация 5. Соответствие рекомендациям Microsoft относительно DNS
Контроль состояния работоспособности среды DNS для Server 2008 R2 следует осуществлять с использованием анализатора соответствия рекомендациям Microsoft Best Practices Analyzer (BPA) в составе пакета Server 2008 R2. Этот инструмент представлен в двух вариантах: один для проверки соответствия рекомендациям по конфигурации DNS, второй — для DNS. BPA представляет собой полезный инструмент сканирования среды DNS для Server 2008 R2 и анализа потенциальных проблем конфигурации DNS.
Чтобы открыть BPA, выполните следующие действия.
- В меню Start выберите Administrative Tools и далее Server Manager.
- На древовидном представлении откройте Roles и выберите роль, для которой нужно запустить BPA.
- На панели подробностей в разделе Summary откройте область анализатора соответствия рекомендациям Best Practices Analyzer.
Для Windows Server 2008 в анализаторе базовых настроек конфигурации Microsoft (MBCA) существует модель DNS. MBCA сравнивает настройки серверов DNS с рекомендациями для DNS, изложенными в модели DNS из MBCA 2.0.
Загрузку MBCA можно осуществить по ссылке http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=1b6e9026-f505-403e-84c3-a5dea704ec67.
Исправность DNS — работоспособное состояние AD
В случае неполадок в разрешении имен в среде Windows AD могут возникать различные проблемы. Определите источник проблемы: система, подсеть или сеть. Затем установите, относится ли данная проблема к сфере регистрации или к сфере разрешения имен DNS. При необходимости воспользуйтесь средствами Microsoft для диагностики и поддержания работоспособности среды DNS.
Бойд Гербер (boydg@microsoft.com) — инженер из отдела технической поддержки в Microsoft Networking Escalation. Специализируется на поддержке и настройке DNS
Время на прочтение
8 мин
Количество просмотров 169K
Авторское примечание: Статья в первую очередь написана для начинающих системных администраторов, опытные вряд ли почерпнут для себя здесь что-нибудь новое и полезное. Навеяно статьей про GPUPDATE /force (спасибо mrHobbY).
Active Directory – это большой и сложный организм (даже если он состоит и двух контроллеров домена и одного сайта), и для системного администратора очень важно в любой момент времени провести диагностику для анализа работы этого организма.
Ну, а так как по оснасткам ходить и смотреть малоэффективно, по логам системы тоже не всегда поймешь, что происходит, поэтому на помощь приходят различные утилиты. Одна из них – dcdiag от компании Microsoft.
Посмотрим на нее внимательно – ибо полезность данной утилиты трудно переоценить. Я не буду приводить многочисленные ключи данной команды – про них при желании можно и в справке прочитать — а остановлюсь только на тех, – которые использую сам при диагностике на практике.
Первое, что нужно сделать, чтобы работать с этой утилитой – это установить ее к себе на рабочую станцию или на сам сервер (тут каждый волен выбирать сам, но в последних версиях dcdiag – уже в помощи написано, что проверки необходимо запускать на самих серверах — контроллерах домена, за исключением тестов dcPromo и RegisterInDNS). Для Windows 2003 необходимо установить пакет Support Tools c дистрибутива операционной системы, для Windows 7 и 8 – необходимо установить пакет Remote System Administration Tools (они разные для win7, win7sp1, и win8 – будьте внимательны, когда будете скачивать). Кстати, RSAT — сам по себе полезный продукт – внутри много утилит, которые просто необходимы в повседневной жизни администратора домена.
После установки пакета команда уже доступна из командной строки.
Но не торопитесь запускать ее сразу, на рабочей станции ничего не получится без указания контроллера домена, к которому надо подключиться. Утилита выдаст соответствующее предупреждение:
Примечание: начиная с Windows 7 сообщения dcdiag переведены на русский. До этого – все только на английском. Может будет кому полезно. Хотя и в старых версиях очень простой и понятный английский язык.
Замечательно – мы выяснили – что желательно указать контроллер домена с помощью ключа /s: или контекст именования – /n:. Какой сервер указывать понятно – тот контроллер домена, который вы хотите проверить – а вот если указать контекст именования домена – (имя домена другими словами – можно указывать в форматах Netbios, DNS или DN.), то будет найден ближайший (в пределах сайта) контроллер домена (далее КД).
Проведем самую простую проверку: dcdiag /s:dc01-local
И опять беда, хотя кое-что уже видно:
Результат работы
dcdiag /s:dc01-local.local
Диагностика сервера каталогов
Выполнение начальной настройки:
* Идентифицирован лес AD.
Сбор начальных данных завершен.
Выполнение обязательных начальных проверок
Сервер проверки: Local\dc01-local
Запуск проверки: Connectivity
......................... DC01-LOCAL - пройдена проверка Connectivity
Выполнение основных проверок
Сервер проверки: Local\dc01-local
Запуск проверки: Advertising
......................... DC01-LOCAL - пройдена проверка Advertising
Запуск проверки: FrsEvent
Ошибка 5 при открытии File Replication Service журнала событий
\\DC01-LOCAL:File Replication Service:
Отказано в доступе.
......................... DC01-LOCAL - не пройдена проверка FrsEvent
Запуск проверки: DFSREvent
......................... DC01-LOCAL - пройдена проверка DFSREvent
Запуск проверки: SysVolCheck
......................... DC01-LOCAL - не пройдена проверка SysVolCheck
Запуск проверки: KccEvent
Ошибка 5 при открытии Directory Service журнала событий
\\DC01-LOCAL:Directory Service:
Отказано в доступе.
......................... DC01-LOCAL - не пройдена проверка KccEvent
Запуск проверки: KnowsOfRoleHolders
......................... DC01-LOCAL - пройдена проверка
KnowsOfRoleHolders
Запуск проверки: MachineAccount
......................... DC01-LOCAL - пройдена проверка MachineAccount
Запуск проверки: NCSecDesc
......................... DC01-LOCAL - пройдена проверка NCSecDesc
Запуск проверки: NetLogons
[DC01-LOCAL] В учетных данных пользователя отсутствует разрешение на
выполнение данной операции.
Учетная запись, используемая для этой проверки, должна иметь права на
вход в сеть
для домена данного компьютера.
......................... DC01-LOCAL - не пройдена проверка NetLogons
Запуск проверки: ObjectsReplicated
......................... DC01-LOCAL - пройдена проверка
ObjectsReplicated
Запуск проверки: Replications
[Проверка репликации,DC01-LOCAL] Сбой функции
DsReplicaGetInfo(PENDING_OPS, NULL), ошибка 0x2105
"Доступ к репликации отвергнут."
......................... DC01-LOCAL - не пройдена проверка Replications
Запуск проверки: RidManager
......................... DC01-LOCAL - пройдена проверка RidManager
Запуск проверки: Services
Не удалось открыть диспетчер управления службой в
dc01-local.local, ошибка 0x5 "Отказано в доступе."
......................... DC01-LOCAL - не пройдена проверка Services
Запуск проверки: SystemLog
Ошибка 5 при открытии System журнала событий \\DC01-LOCAL:System:
Отказано в доступе.
......................... DC01-LOCAL - не пройдена проверка SystemLog
Запуск проверки: VerifyReferences
......................... DC01-LOCAL - пройдена проверка VerifyReferences
Выполнение проверок разделов на: Schema
Запуск проверки: CheckSDRefDom
......................... Schema - пройдена проверка CheckSDRefDom
Запуск проверки: CrossRefValidation
......................... Schema - пройдена проверка
CrossRefValidation
Выполнение проверок разделов на: Configuration
Запуск проверки: CheckSDRefDom
......................... Configuration - пройдена проверка
CheckSDRefDom
Запуск проверки: CrossRefValidation
......................... Configuration - пройдена проверка
CrossRefValidation
Выполнение проверок разделов на: LOCAL
Запуск проверки: CheckSDRefDom
......................... LOCAL - пройдена проверка CheckSDRefDom
Запуск проверки: CrossRefValidation
......................... LOCAL - пройдена проверка
CrossRefValidation
Выполнение проверок предприятия на: LOCAL.local
Запуск проверки: LocatorCheck
......................... LOCAL.local - пройдена
проверка LocatorCheck
Запуск проверки: Intersite
......................... LOCAL.local - пройдена
проверка Intersite
Как мы видим, часть тестов пройдена – но части отказано в доступе. Это из-за того, что dcdiag я запускал из-под обычной учетной записи домена, без администраторских прав. Понятно – что часть проверок пройти под ней просто невозможно. Поэтому, что бы получить правильную диагностику, необходимо запускать утилиту с административными полномочиями – либо запустить командную строку от имени администратора, либо использовать ключи /u: имя домена\имя пользователя и /p: пароль. Попробуем:
dcdiag /s:dc01-local /u:local\user19 /p:Password
Результат работы
Диагностика сервера каталогов
Выполнение начальной настройки:
* Идентифицирован лес AD.
Сбор начальных данных завершен.
Выполнение обязательных начальных проверок
Сервер проверки: Magadan\DC01-LOCAL
Запуск проверки: Connectivity
......................... DC01-LOCAL - пройдена проверка Connectivity
Выполнение основных проверок
Сервер проверки: Magadan\DC01-LOCAL
Запуск проверки: Advertising
......................... DC01-LOCAL - пройдена проверка Advertising
Запуск проверки: FrsEvent
......................... DC01-LOCAL - пройдена проверка FrsEvent
Запуск проверки: DFSREvent
......................... DC01-LOCAL - пройдена проверка DFSREvent
Запуск проверки: SysVolCheck
......................... DC01-LOCAL - пройдена проверка SysVolCheck
Запуск проверки: KccEvent
......................... DC01-LOCAL - пройдена проверка KccEvent
Запуск проверки: KnowsOfRoleHolders
......................... DC01-LOCAL - пройдена проверка
KnowsOfRoleHolders
Запуск проверки: MachineAccount
......................... DC01-LOCAL - пройдена проверка MachineAccount
Запуск проверки: NCSecDesc
......................... DC01-LOCAL - пройдена проверка NCSecDesc
Запуск проверки: NetLogons
......................... DC01-LOCAL - пройдена проверка NetLogons
Запуск проверки: ObjectsReplicated
......................... DC01-LOCAL - пройдена проверка
ObjectsReplicated
Запуск проверки: Replications
......................... DC01-LOCAL - пройдена проверка Replications
Запуск проверки: RidManager
......................... DC01-LOCAL - пройдена проверка RidManager
Запуск проверки: Services
Недопустимый тип службы: RpcSs на DC01-LOCAL, текущее значение -
WIN32_OWN_PROCESS, ожидаемое значение - WIN32_SHARE_PROCESS
......................... DC01-LOCAL - не пройдена проверка Services
Запуск проверки: SystemLog
......................... DC01-LOCAL - пройдена проверка SystemLog
Запуск проверки: VerifyReferences
......................... DC01-LOCAL - пройдена проверка VerifyReferences
Выполнение проверок разделов на: Schema
Запуск проверки: CheckSDRefDom
......................... Schema - пройдена проверка CheckSDRefDom
Запуск проверки: CrossRefValidation
......................... Schema - пройдена проверка
CrossRefValidation
Выполнение проверок разделов на: Configuration
Запуск проверки: CheckSDRefDom
......................... Configuration - пройдена проверка
CheckSDRefDom
Запуск проверки: CrossRefValidation
......................... Configuration - пройдена проверка
CrossRefValidation
Выполнение проверок разделов на: LOCAL
Запуск проверки: CheckSDRefDom
......................... LOCAL - пройдена проверка CheckSDRefDom
Запуск проверки: CrossRefValidation
......................... LOCAL - пройдена проверка
CrossRefValidation
Выполнение проверок предприятия на: LOCAL.Local
Запуск проверки: LocatorCheck
......................... LOCAL.Local - пройдена
проверка LocatorCheck
Запуск проверки: Intersite
......................... LOCAL.Local - пройдена
проверка Intersite
ак видим, проверки пройдены почти все – кроме проверки Services. Но тут у меня есть вполне логичное объяснение – я с помощью новой утилиты (из пакета для windows 7) пытаюсь проверять контроллер домена на базе win2003 – и вполне возможно, название службы может отличаться.
Лирическое отступление №1. При подготовке статьи я столкнулся с
epic fail
забавным феноменом, может в комментариях обсудим? :). В общем, запуская dcdiag из-под обычной учетной записи другого домена (связанного доверительными отношениями с исследуемым доменом local) и задавая параметры /u и /p – (имя пользователя и пароль административной учетной записи домена local) – утилита выдавала ошибки в части проверок — например sysvolchek (в версии dcdiag 2003 – frssysvol). Если же на рабочую станцию зайти под учетной записью с административными полномочиями в домене local — проверки прекрасно проходятся. Так что – может быть, все-таки не лишним будет проводить проверку на самом сервере. Конец лирического отступления №1.
Полностью описывать результаты работы команды я не вижу смысла. Это прекрасно описано в помощи к утилите (dcdiag /h). Видно главное – с данным контроллером домена проблем нет и все тесты пройдены. Но из проверки одного сервера – не следует факт, что AD сейчас находится в
шоколаде
работоспособном состоянии. И вот здесь нам на помощь придет ключ для проверки всех серверов предприятия.
Это ключ /e. Данный ключ заставляет утилиту обойти все КД в домене с запуском всех тестов на каждом сервере. Полезно вместе с этим применить /v – вывод расширенной информации по каждому тесту. Ну и чтобы проанализировать все это – полезно данные вывести в файл – причем лог отдельно, сообщения об ошибках – отдельно. Помогут в этом ключи /f: имя_файла_лога и ferr:/имя_файла_лога_ошибок (в новых версиях ключ /ferr убран). Если вы хотите провести проверку не того домена, в котором находитесь сейчас – добавите ключ для указания наименования контекста /n:.
Полностью команда выглядит так:
dcdiag /n:local /e /v /f:c:\logs\adtest.log /ferr:c:\logs\aderrors.log /u:local\user19 /p:Password
Внимание! В версиях dcdiag, начиная с windows 2008 ключ /ferr: убран из поддерживаемых (специально повторился :)).
Если у вас сложная структура леса, да еще и с медленными каналами связи приготовьтесь подождать. Да даже и если несложная – скажем у меня в одном реальном лесе – 10 КД, 5 сайтов и каналы 256 кбит/сек. Выполнение данной команды занимает в среднем до 20 минут.
Результат исполнения очень рекомендуется внимательно просмотреть на наличие проблем. Ну и очень желательно запускать данную утилиту регулярно для диагностики здоровья AD.
Для хардкора можно еще добавить ключ /fix – внесение безопасных исправлений, но бездумно все-таки этого делать не стоит.
Вот собственно и все что я хотел сегодня рассказать. А как часто вам приходится пользоваться данной утилитой на производстве? Какие альтернативы вы знаете?
update 1: Что-то вспомнилось, опять же из личного опыта: если у вас большой домен, связанный небыстрыми (например, спутниковыми) каналами связи — утилита будет выдавать массу ошибок в случае ее отсутствия — чаще всего, что недоступен RPC. Это нормально, и про это надо знать. Если большинство тестов оканчивается подобным сообщением — значит нет связи, необходимо применять меры по устранению сбоя. Вторая часто распространенная проблема — ошибки в DNS — но это тема уже для отдельной статьи.
p.s. к update 1 -dcdiag /fix — в том числе регистрирует по новой записи в dns службы netlogon — это тоже бывает полезно знать!
I’ve received a few messages from users of my site that they can not access it from home.
They can access the server from the IP, but not by the domain name.
I think it has something to do with the way my DNS is configured. I setup my own DNS server about 4 years ago on my server, which I probably should not have done, and I’m not sure if everything is configured correctly. There are plenty of people who can access the site without any problems, but some users get ‘server can not be found’.
Server Details: Windows 2003 co-located server at a small local hosting company.
Are there good tools or sites that can test and provide configuration recommendations? How do I test this problem when it works fine for me and so many other users? What type of questions should I ask users that can’t access the site?
Can I provide / point to another DNS server that can be used if the first server isn’t working?
Thanks!
asked Apr 4, 2012 at 15:20
1
Nevertheless here some pointers:
Questions that you can ask the users:
-
Run the following command:
nslookup test.company.com
. The result should be the IP they could access by IP. If it’s a wrong IP or no IP, then this hostnameA
/CNAME
record isn’t propagated correctly to the outside world. -
It could be a ipv4/v6 problem. Maybe the DNS resolves to a ipv6 IP by
AAAA
record and your ISP (or any provider inbetween) doesn’t support ipv6 correctly yet. Under windows, you canping -6
orping -4
to see if it resolves to anything at all.
Possible workaround:
Tell your users to hardcode the IP of your server into their HOSTS file…
DNS problems are usually lying at the companies infrastructure though (e.g. not propagating the DNS notifications correctly, wrong DNS servers at your registrar, wrong DNS configuration on your DNS server…)
answered Apr 4, 2012 at 15:35
KhôiKhôi
2,14311 silver badges10 bronze badges
4
There’s an excellent on-line resource to verify your DNS settings: intoDNS.com
If you think the problem is in your DNS server and you don’t need it this way anyway, you can just turn your DNS to any DNS hosting — see my biased list. Setup your DNS records from scratch with any DNS provider and tell your domain registrar to use that provider nameservers. Often registrars themselves provide DNS servers as well.
As for questions to ask users, Khoi explained everything.
answered Apr 4, 2012 at 17:19
Sandman4Sandman4
2,6832 gold badges22 silver badges18 bronze badges