Доменные службы active directory не могут разрешить следующее dns имя исходного контроллера

Обновлено: 25.01.2025

Стоит отметить, что данная проблема может возникнуть и под подключением ОС Win 7 и Win Vista к домену на Win Server 2003.

Если же Вы уверены в правильности настройки сервера DNS, то попробуйте попеременно следующее:

Если настраиваете вручную, убедитесь, что правильно указана Маска и DNS (распространено при наличии подсетей и сложных доменных структур).

Бывает, что пробиться мешает включенный TCP/IPv6 (замечено в Windows Vista). Можно попробовать его отключить.

Иногда при подключении в домен с простой структурой под управлением Windows server 2003 standart, ПК с установленной Win7 x64, помогает шаманство с галками, относящимися к DNS-суффиксам в свойствах TCP/IPv4.

Проблема может возникнуть из-за неверно настроенного Брандмауэра.

Надеюсь, хоть один из пунктов Вам поможет.

Авторизация в Windows при помощи графического пароля

Размер файла подкачки Windows

Windows 7 64x домен win server 2008 r2 помогло шаманство с галками, относящимися к DNS-суффиксам в свойствах TCP/IPv4. а именно, нужно было убрать галку Зарегистрировать адреса этого подключения в DNS. Спасибо автору!

Вам за отзыв спасибо

нужно чтобы были прописан(ы), как минимум, предпочитаемый ДНС-сервер

Помогло снятие галочки использования IPv6

Помогло! Огромное спасибо автору.
Получилось после манипуляций со снятием галочек, относящимся к DNS-суффиксам в свойствах TCP/IP и в свойствах системы.

Не помогло ни одно из описанного. Кашмар какой то

Спасибо
Вот еще вариант
У меня dns и dhcp на линуксовом серваке
домен на 2008
win XP норм подключался к домену а 7рки не хотели
решил так:
на DС развернул второй dns сервер
на клиенте установил основной днс созданный на DC
заработало

Наверное проблема с первым DNS. Решение имеет место, но не панацея, лучше поковыряйся ещё, если конечно интересно и есть время.

win 7 в домен win serv 2008 помогло снятие галки использования ip ver 6 в свойствах сети и дописал в ip v 4 dns домена

Проверьте в диспетчере сервера, настройки DHCP а точнее параметры области, чтоб были настроены параметры 006 и 015, ну и заодно если не прописаны то и 003 и 004 тогда всё гуд, т к при авто выдаче IP адреса и прочих параметров DNS не задаётся думаю в вашем случае

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

В этой статье описываются симптомы, причины и действия по разрешению операций AD, которые не удается с ошибкой Win32 8524:

Операция DSA не может продолжиться из-за сбоя при просмотре DNS.

Применяется к: Windows 10 — все выпуски, Windows Server 2012 R2
Исходный номер КБ: 2021446

Домашние пользователи: Эта статья предназначена только для агентов технической поддержки и ИТ-специалистов. Если вы ищете помощь с проблемой, спросите microsoft Community.

Симптомы

DCDIAG сообщает, что тест репликации Active Directory не справился со статусом 8524:

Сервер тестирования: <sitename><destination DC>
Начальный тест: репликации
[Репликации Проверить, <destination DC> ] Недавняя попытка репликации не удалась. <source DC><destination DC>
Контекст именования:
CN= <DN path for failing directory partition> ,DC=Contoso,DC=Com
Репликация вызвала ошибку (8524):
Операция DSA не может продолжиться из-за сбоя при просмотре DNS.

REPADMIN сообщает, что попытка репликации не удалась со статусом 8524.

Команды REPADMIN, которые обычно ссылаются на состояние 8524, включают, но не ограничиваются:

REPADMIN /REPLSUM
REPADMIN /SHOWREPS
REPADMIN /SHOWREPL

Ниже показан пример из 8524 сбоев rePADMIN/SHOWREPL:

Default-First-Site-Name\CONTOSO-DC1
Параметры DSA: IS_GC
Параметры сайта: (нет)
GUID объекта DSA: вызов DSA:
DC=contoso,DC=com
Default-First-Site-Name\CONTOSO-DC2 через RPC
GUID объекта DSA:
Последняя попытка @ YYYY-MM-DD HH:MM:SS не удалась, результат 8524 (0x214c):
Операция DSA не может продолжиться из-за сбоя при просмотре DNS.
1 последовательный сбой(ы).
Последний успех @ YYYY-MM-DD HH:MM:SS.

Остальные выходные данные /showrepl усечены

Одно из следующих событий со статусом 8524 входит в журнал событий службы каталогов:

Проверка согласованности знаний NTDS (KCC)
NTDS General
Microsoft-Windows-ActiveDirectory_DomainService

События Active Directory, которые обычно ссылаются на состояние 8524, включают, но не ограничиваются:

Контроллеры домена регистрирует событие репликации NTDS 2087 и событие репликации NTDS 2088 в журнале событий службы каталогов:

Имя журнала: служба каталогов
Источник: Microsoft-Windows-ActiveDirectory_DomainService
Дата: <date> <time>
ID события: 2087
Категория задач: клиент RPC DS
Уровень: ошибка
Ключевые слова: Классический
Пользователь: АНОНИМНЫЙ LOGON
Компьютер: <dc name> .<domain name>
Описание:

Службы домена Active Directory не смогли разрешить следующее имя ведущего DNS контроллера домена источника на IP-адрес. Эта ошибка не позволяет добавлениям, удалениям и изменениям в службах домена Active Directory реплицировать между одним или более контроллерами домена в лесу. Группы безопасности, групповые политики, пользователи и компьютеры, а их пароли будут несовместимы между контроллерами домена до тех пор, пока эта ошибка не будет устранена. Потенциально это влияет на проверку подлинности и доступ к сетевым ресурсам.

Имя журнала: служба каталогов
Источник: Microsoft-Windows-ActiveDirectory_DomainService
Дата: <date> <time>
ID события: 2088
Категория задач: клиент RPC DS
Уровень: предупреждение
Ключевые слова: Классический
Пользователь: АНОНИМНЫЙ LOGON
Компьютер: <dc name> .<domain name>
Описание:
Службы домена Active Directory не могли использовать DNS для решения IP-адреса контроллера домена, приведенного ниже. Для обеспечения согласованности групп безопасности, групповой политики, пользователей и компьютеров и их паролей службы домена Active Directory успешно реплицировали с помощью NetBIOS или полностью квалифицированного имени компьютера контроллера домена источника.

Недействительная конфигурация DNS может влиять на другие важные операции на компьютерах членов, контроллерах доменов или серверах приложений в этом лесу служб домена Active Directory, включая проверку подлинности логотипов или доступ к сетевым ресурсам.

Вы должны немедленно устранить эту ошибку конфигурации DNS, чтобы этот контроллер домена может разрешить IP-адрес контроллера домена источника с помощью DNS.

Причина

Состояние ошибки 8524 имеет следующую строку ошибок:

Операция DSA не может продолжиться из-за сбоя при просмотре DNS.

Это ошибка для всех возможных отказов DNS, влияющих на Active Directory на контроллерах домена Windows Server 2003 SP1.

Microsoft-Windows-ActiveDirectory_DomainService событие 2087 является партнерским событием для других событий Active Directory, которые ссылаются на состояние 8524, если контроллер домена Active Directory не может разрешить удаленный DC с помощью полностью квалифицированной записи CNAME <object guid for source DCs NTDS Settings object> (._msdcs. ) с помощью <forest root domain> DNS.

Microsoft-Windows-ActiveDirectory_DomainService событие 2088 регистрируется, когда контроллер домена источника успешно разрешен с помощью имени NetBIOS, но такое разрешение имен возникает только при сбое разрешения имен DNS.

Наличие состояния 8524 и событий 2088 или 2087 microsoft-Windows-ActiveDirectory_DomainService 2088 или 2087 указывает на то, что разрешение имен DNS не удается active Directory.

Таким образом, состояние репликации 8524 регистрируется, когда dc назначения не может разрешить источник DC с помощью записей CNAME и Host "A" или Host "AAAA" с помощью DNS. Конкретные корневые причины:

Исходный dc находится в автономном режиме или больше не существует, но его объект Параметры NTDS по-прежнему существует в экземпляре active Directory для DCs назначения.

Источник DC не зарегистрировал записи CNAME или хост-серверов на одном или более DNS-серверах по следующим причинам:

Попытки регистрации не увенчались неудачей.
Параметры клиента DNS в источнике не указывают на DNS Servers, которые либо разодвигают, либо делегируют <forest root domain zone and (or) primary DNS suffix domain zones> _msdcs. .

Параметры клиентов DNS в пункте назначения DC не указывают на DNS Servers, которые либо содержат, либо перенаправлены, либо делегируют зоны DNS, содержащие CNAME или хост-записи для источника DC

Простая задержка репликации
Сбой репликации
Сбой передачи зоны

Недействительные forwarders или делегирования. Они препятствуют разрешению доменных записей CNAME или Host для DCs в других доменах в лесу.

DNS Servers, используемые для dc назначения, источника dc или промежуточных DNS Servers, не работают должным образом.

Решение

Проверьте, вызвана ли 8524 автономной dc или устаревшими метаданными DC

Если ошибка/событие 8524 относится к dc, который в настоящее время отключен, но по-прежнему действителен в лесу, сделайте его рабочим.

Если ошибка/событие 8524 относится к неактивному DC, удалите устаревшие метаданные для этого DC из копии active Directory для DCs назначения. Неактивный DC — это установка dc, которая больше не существует в сети, но ее объект Параметры NTDS по-прежнему существует в экземпляре active Directory для DCs назначения.

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

Удаление устаревших метаданных DC, если они присутствуют

Очистка метаданных GUI с помощью сайтов и служб Active Directory (DSSITE). MSC)

Запустите Windows Server 2008 или Windows Server 2008 R2 Active Directory Sites and Services snap-in (DSSITE). MSC).

Это также можно сделать путем запуска сайтов и служб Active Directory на компьютере Windows Vista или Windows 7, который был установлен в рамках пакета средств администрирования удаленного сервера (RSAT).

Сосредоточься на DSSITE. MSC snap-in on the destination DCs' copy of Active Directory.

После запуска DSSITE. MSC, щелкните правой кнопкой мыши "Сайты и службы Active Directory [ <DC Name> ]

Выберите пункт назначения, в который веется журнал ошибки 8524/event из списка DCs, видимого в "Изменение контроллера домена. ". список

Удалите исходный объект DCs NTDS Параметры, на который ссылается в 8524 ошибках и событиях. Пользователи и компьютеры Active Directory (DSA. MSC) оснастки и удаления либо источника DCs NTDS Параметры объекта.

Появляется объект DCs NTDS Параметры

Ниже контейнера Sites, Site Name, Servers и %server name%
Выше входящий объект подключения, отображаемого в правой области сайтов и служб Active Directory.

На красном снимке экрана ниже показан объект NTDS Параметры CONTOSO-DC2, расположенный ниже сайта Default-First-Site-Name.

Щелкните правой кнопкой мыши устаревший объект NTDS Параметры, который необходимо удалить, а затем выберите "Удалить".

Очистка метаданных также может быть сделана из оснастки W2K8 /W2K8 R2 Active Directory Users and Computers, как описано в TECHNET.

Очистка метаданных командной строки с помощью NTDSUTIL

Устаревший или командный метод удаления устаревших объектов NTDS Параметры с помощью команды очистки метаданных NTDSUTIL задокументирован в MSKB 216498.

Запуск DCDIAG /TEST:DNS на источнике DC + dc назначения

DCDIAG /TEST:DNS делает семь различных тестов для быстрого проверки состояния DNS контроллера домена. Этот тест не является частью выполнения DCDIAG по умолчанию.

Войдите с Enterprise учетными данными администратора на консоль контроллеров домена назначения, которые регистрют события 8524.

Откройте управленский привилегированный запрос CMD, а затем запустите в журнале DC состояние 8424 и исходный DC, из чего реплицируется dc DCDIAG /TEST:DNS /F назначения.

Чтобы запустить DCDIAG со всеми DCs в лесу, введите DCDIAG /TEST:DNS /V /E /F:<File name.txt> .

Чтобы запустить DCDIAG TEST:DNS для определенного DC, введите DCDIAG /TEST:DNS /V /S:<DC NAME> /F:<File name.txt> .

Найдите сводную таблицу в конце DCDIAG /TEST:DNS вывода. Определение и согласование условий предупреждения или сбоя в соответствующих DCs отчета.

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

Проверка разрешения имен Active Directory с помощью PING

DCS назначения устраняют исходные DCS в DNS с помощью полностью квалифицированных записей CNAME, полученных из объекта GUID удаленного объекта DCS NTDS Параметры (родительский объект для подключения объектов, видимых в оснастке Сайтов и служб Active Directory). С помощью команды PING можно протестировать способность данной DCS разрешить полностью квалифицированную запись CNAME источника DC.

Найдите объектGUID источника DCs NTDS Параметры в копии источника DCS Active Directory.

На консоли источника DC, в журнале 8524 ошибки/события, введите:

repadmin /showrepl <fully qualified hostname of source DC cited in the 8524 error (event)>

Поле GUID объекта DSA в заглавной части команды содержит объектGUID объекта текущих repadmin /SHOWREPl NTDS исходных DCs. Используйте представление исходных DCs о его объекте Параметры NTDS в случае медленной репликации или сбоя. Заглавная часть repadmin вывода будет выглядеть так:

Default-First-Site-Name\CONTOSO-DC1
Параметры DSA: IS_GC
Параметры сайта: (нет)
GUID объекта DSA: 8a7baee5-cd81-4c8c-9c0f-b10030574016 < правой кнопкой мыши + скопируйте эту строку в Windows
<-буфер обмена & вклеить в него команду PING в
< шаг 4

Найдите объектGUID источника постоянного тока в копии DCs назначения Active Directory.

На консоли конечного dc для ведения журнала ошибки/события 8524 введите:

repadmin /showrepl <fully qualified hostname of destination DC>

REPADMIN /SHOWREPL вывод показан ниже. Поле GUID объекта DSA перечислены для каждого источника DC, из которых реплицируется входящий dc назначения.

Если объект GUIDS одинаковый, то источник DC и dc назначения знают об одном и том же моментации (той же рекламе) источника DC. Если они отличаются, то рисуй, какой из них был создан позже. Объект настройки NTDS с более ранней датой создания, скорее всего, устарел и должен быть удален.

PING источник DC по его полностью квалифицированной CNAME.

На консоли конечной dc протестировать разрешение имен Active Directory с помощью PING-записи исходных компьютеров с полной квалификацией CNAME:

c:\>ping <ObjectGUID> from source DCs NTDS Settings object._msdcs.<DNS name for Active Directory forest root domain>

Если ping работает, повторно обнажь невыполнение операции в Active Directory. В случае сбоя PING перенаправляйся в "Устранение сбоя при проверке 8524 DNS", но повторно проверьте тест PING после каждого шага, пока он не разрешит.

Устранение сбоя в оккупате DNS 8524: долгий путь

Если ошибка/события 8524 не вызвана устаревшими метаданными DC, а тест CNAME PING сбой, проверьте состояние DNS:

Исходный DC
Пункт назначения DC
DNS Servers, используемые в DCS-источника и назначения

В общем, убедитесь, что:

Убедитесь, что исходный dc указывает на допустимые DNS Servers

Основной домен Суффикса DNS для компьютеров, если он отличается от доменного имени Active Directory (см. статью Technet Disjoint Namespace).

Параметры проверки того, что в DNS Server размещены, переадтрансаторы или делегаты (то есть "можно разрешить") такие зоны.

Запустите средство управления DNS для DNS и убедитесь, что DNS Servers, на которые указывает источник DC для разрешения имен, являются зонами, о которых идет речь.

Используйте NSLOOKUP, чтобы убедиться, что все DNS Servers, на которые указывает источник DC, могут решать запросы для зон DNS, о чем идет речь.

Запуск IPCONFIG /ALL на консоли источника DC

Запустите следующие запросы NSLOOKUP:

Убедитесь, что исходный dc зарегистрировал запись CNAME

Используйте шаг 1 из "Проверьте разрешение имен active Directory с помощью PING", чтобы найти текущий CNAME источника DC.

Запустите на консоли источника постоянного тока, чтобы определить, на какой ipconfig /all DNS Servers указывает источник dc для разрешения имен.

Используйте NSLOOKUP для запроса текущих DNS-серверов для записи CNAME источника DCS (найденной с помощью процедуры в "Проверьте разрешение имен Active Directory с помощью PING").

Если источник DC не зарегистрировал запись CNAME на DNS Servers, на что указывает для разрешения имен, запустите следующую команду из источника DC. Затем перепроверять регистрацию записи CNAME:

Убедитесь, что исходный dc зарегистрировал свои записи хост-кодов

На консоли источника постоянного тока запустите, чтобы определить, на какой ipconfig /all DNS Servers указывается источник разрешения имен.

Используйте NSLOOKUP для запроса текущих DNS Servers для хост-записи.

Повторите команду NSLOOKUP с исходным IP-адресом DNS Server.

Чтобы динамически зарегистрировать записи "A", введите следующую команду с консоли компьютера:

Windows 2000 через Windows Сервер 2008 R2 все зарегистрировать IPv4 хост "A" записей.
Windows На компьютерах Server 2008 и Windows Server 2008 R2 все регистрируются записи IPv6 хост "AAAA".
Записи хостов "A" и "AAAA" регистрируются в зоне первичного суффикса DNS на компьютерах.
Отключать ники, не подключенные к сетевым кабелям.
Отключение регистрации записей хост-записей в НИКАх, недоступных для компьютеров-членов и компьютеров-членов в сети.
Отключение протокола IPv6 не поддерживается путем отключки почтового ящика IPv6 в свойствах сетевых карт.

Убедитесь, что пункт dc назначения указывает на допустимые DNS Servers

Параметры проверки того, что DNS Server хостов, переадтрансаторов или делегатов (то есть "можно разрешить") такие зоны включают в себя:

Запустите IPCONFIG /ALL на консоли конечного DC:

Запустите следующие запросы NSLOOKUP с консоли dc назначения:

Убедитесь, что DNS Server, используемый центром назначения, может разрешить исходные записи ЦНС CNAME и HOST

На консоли конечной dc запустите, чтобы определить DNS Servers, в какую точку назначения dc указывает разрешение ipconfig /all имен:

На консоли конечной dc используйте для запроса DNS Servers, настроенных в пункте назначения DC для исходных NSLOOKUP DCs CNAME и записей хостов:

Просмотрите связь между DNS Servers, используемыми в исходных и пунктов назначения.

Если DNS Servers используются исходными и принимающими AD-интегрированными копиями _msdcs.<forest root> и <primary DNS suffix> зоны, проверьте:

Если зоны DNS, используемые источником и центром назначения, хранятся в первичных и вторичных копиях зон DNS, проверьте:

Почтовый ящик "Разрешить передачу зоны" не включен в DNS, в котором размещена основная копия зоны.
Включен почтовый ящик "Только следующие серверы", но IP-адрес вторичной DNS не был добавлен в список допуска в основной DNS.
Зона DNS на Windows 2008 DNS, где размещена вторичная копия зоны, пуста из-за KB953317.

Если DNS-серверы, используемые источником и центром назначения, имеют родительские и детские связи, проверьте:

Итак, я наконец то собрался с силами и, отбросив лень, сел плавненько переезжать на 2008 Server R2 с 2003 Server R2, где крутилась АД в режиме работы леса и домена 2003.

Выполнил adprep для леса и домена, все прошло успешно.

Взял один из этих двух КД и переставил на нем ОСь на Windows Server 2008 R2.

Добавил машинку в домен, поднял роль АД. ДНС добавился автоматически. Открываю AD, смотрю на данные - вроде бы все замечательно отреплицировалось, даные перенеслись, новый, только что установленный сервак отображается в списке Контроллеров Домена.

Однако, решил прочитать журнал DNS на всякий пожарный и хорошо, что прочитал:

Тогда я занервничал и решил, что надо бы выполнить dcdiag, netdiag на только что полнятом КД. Не успел запустить dcdiag, как ошибки посыпались, первая из которых:

Как же тогда я вижу данные в АД все? и в ДНС?

Брандмауэр на серваке отлючен, пользователь обладает правами администратора.

Может быть я неверно указал настройки для ДНСов? Сейчас схема такая.

КД1 (с которого надо все стянуть на 2008 R2):

И вообще все, что связано с АД. я поднимаю только после установки и настройки DNS.
Правда не понятен откуда взят адрес 172.17.1.3? И вообще все, что связано с АД. я поднимаю только после установки и настройки DNS.
Правда не понятен откуда взят адрес 172.17.1.3?

Хм. Как я только не пробовал выставлять айпишники, но так еще нет

Сделал так. Ошибки те же.

Отключил UAC, Брандмауэр отключил еще вчера. Антивирус/файрвол сторонний убил.

Проверил службу "Браузер Компьютеров" - была не запущена. Установил тип запуска - автоматом, саму службу запустил.

После всего этого ребутнул сервак. После ребута ошибки были те же. Открыл "AD - пользователи и компьютеры". Создал новую учетку. Кроме того изменил некоторые существующие записи - на КД1 изменения отобразились.

Запустил dcdiag на новом КД2, ниже привожу результат:

Дальше - больше. На КД1 dcdiag выплевывает исключительно ошибки репликации.

При этом оба сервака видят друг друга через nslookup.

Очень надеюсь на помощь.

А что у вас за сервер CORE это первое и второе на w2k3 все ли роли захвачены? Внимательнее просмотрите DNS, все записи, которые микрософтовские, т.е. зоны, начинающиеся с "_"и записи в них. ну и попробуйте снова зарегистрировать основной контроллер можно любым способом ipconfig /registersdns или перезапуском netlogon. snorlov писал(а): А что у вас за сервер CORE это первое и второе на w2k3 все ли роли захвачены? Внимательнее просмотрите DNS, все записи, которые микрософтовские, т.е. зоны, начинающиеся с "_"и записи в них. ну и попробуйте снова зарегистрировать основной контроллер можно любым способом ipconfig /registersdns или перезапуском netlogon.

До этого было 2 КД, оба на w2k3. Один из них я понизил, переставил ОСь на 2008 Server и снова поднял АД, введя его в домен.

CORE - это старый КД на w2k3, все 5 ролей принадлежат ему.

NetLogOn перезапускал, эффект тот же. Сейчас попробую перезарегистрировать КД.

Имеет ли смысл переустановить службы AD на новом КД (W2K8)?

Еще в доке читал, что необходимо поднимать DNS !ДО! установки AD, если поднимается дополнительный КД. Однако, dcpromo выполнил сам эту функцию и установил ДНС вместе АД.

DNS у меня интегрирован в AD.

Блин, а роли то у кого остались, похоже, что у CORE, которого сейчас физически нет. Вот и стоит ругань. Этот CORE у вас наверное и в DNS'е имеется, вы сказали, что вы его не обновили, а переставили, так что у вас появился новый кд snorlov писал(а): Блин, а роли то у кого остались, похоже, что у CORE, которого сейчас физически нет. Вот и стоит ругань.

Было два КД. Один Core с айпишником 192.168.0.1, второй URAN с айпишником 192.168.0.2.

Так вот, URAN я понизил до роли простого сервера. Все роли на себя принял CORE.
После этого URAN я вывел из домена и отключил физически.

Еще раз проверил роли на CORE - все ок. Запустил dcdiag и netdiag - все ок. Подготовил лес и домен для w2K8 через adprep.

Вычистил из АД всю информацию об URAN, - там еще сохранилась на тот момент запись типа А.

Взял старый КД - URAN - переустановил там ОС на СЕРВЕР 2008. Ввел в домен. Запустил DCPROMO. Все прошло успешно. Поставил галочку глобального каталога и вуаля! Получил два КД:

Первый кд - это старый CORE на w2k3
Новый кд - URAN на w2k8

Между ними не работает репликация.

Но, физически у меня ДВА КД.

проблемы в DNS'е, останавливайте dns на uran, убивайте все записи об uran на core, затем на uran прописывайте первым dns'ом dns на core, регистрируйте uran в dns'e на core через registersdns, снова винмательно смотрим записи об uran, гоняем тесты и лишь затем поднимаем dns на uran, можно сначала его поднять как slave. snorlov писал(а): проблемы в DNS'е, останавливайте dns на uran, убивайте все записи об uran на core.

В смысле удалить саму службу DNS? Тогда же и АД придется затирать.

На CORE затирать записи в DNS, я так понимаю.

Еще дополнительную инфу кидаю, которую только что сделал.

Привожу ipconfig. Сначала с w2k3 - старый КД:

PID 1304 соответствует службе DNS. Больше PID'ов, слушающих 53 порт я не вижу.

registerdns провел, через 15 минут будет результат.

snorlov писал(а): проблемы в DNS'е, останавливайте dns на uran, убивайте все записи об uran на core. В смысле удалить саму службу DNS? Тогда же и АД придется затирать.
На CORE затирать записи в DNS, я так понимаю. Кто тебе сказал такую ересь, что при удалении/остановке DNS удалиться АД, DNS для AD может быть и unix'совым, главное, что бы эта служба была доступна кд, ну и обладала некоторыми свойствами, одно из которых динамическое обновление зон. Большинство твоих проблем связано с тем, что ты понизил uran, а потом по существу его убил, но записи о нем в AD и DNS'е остались, и под тем же именем вы в AD втащили новый кд. Кстати обратная зона в DNS'е есть? Спрашиваю потому, что она нужна для работы, но автоматом она не создается.

Так, ДНС я удалил с URAN.

Теперь там есть только АД. На сетевых интерфейсах обоих КД указал в качестве праймари ДНС айпишник первого КД - CORE. Альтернативный ДНС сделал пустым.

При этом Active Directory сообщает о следующих ошибках:

1) Исходный КД функционирует
2) Через net view/ping/nslookup новый КД находит старый. URAN находит CORE и наоборот
3) dcdiag /test:dns на CORE выполняется с успехом
4) Аналогично.
5) С базой знаний знакомлюсь.

Вопрос. Что мне вычищать на CORE? Записи типа А и CNAME?

Все ссылки на uran и его ip, обратная зона (0.168.192.in.addr-arpa, на виндовом серваке через мастер вроде там надо писать 192.168.0. ) на core есть? если нет, добавить ручками, ОБЯЗАТЕЛЬНО snorlov писал(а): Все ссылки на uran и его ip, обратная зона (0.168.192.in.addr-arpa, на виндовом серваке через мастер вроде там надо писать 192.168.0. ) на core есть? если нет, добавить ручками, ОБЯЗАТЕЛЬНО

Имена в айпишники и айпишники в имена разрешаются.

Попробовал выполнить репликацию через Active Directory - сайты и службы - выполнилась без ошибок.

Попробовал выполнить репликацию из cmd, через repadmin - тут получил ошибку:

При этом dcdiag выполняется БЕЗ ошибок:
что делать дальше? мне не нравится выполнение repadmin. mr. brightside писал(а): Попробовал выполнить репликацию из cmd, через repadmin - тут получил ошибку:

Я не понимаю, откуда вы сделали такой вывод?

Когда я понижал URAN, то все записи я вычищал и из АД и из ДНС. Вычищал как через оснастки, так и через консоли.

Но старый DSA - 9119974d-4c8a-412a-a0ad-86b357a72fc1 (CORE) - не менялся. Он как был, так и остался. Более того, за все время его работы я его не трогал ни разу.

По всему выходит, что именно запись старого КД - 9119974d-4c8a-412a-a0ad-86b357a72fc1 - и невозможно определить. Может быть, имеет смысл перекинуть роли на новый КД, перекинуть ДНС, переставить ОСь на стором КД ввести в домен и снова сделать КД? Тогда все должно грамотно перерегистрироваться?

Если честно, 1000 страниц читать просто лень Тем более, что я не виндовый админ, а юниксовый

Скажите, пожалуйста, просто, куда капнуть, а то ведь время, время.

в первом случае она идет от кд, где запускается, к его партнерам, а во втором от партнеров к нему.
А все 1000 страниц и не надо читать, я просто в более доступном виде не видел описания утилит для работы с AD на русском языке. в первом случае она идет от кд, где запускается, к его партнерам, а во втором от партнеров к нему.
А все 1000 страниц и не надо читать, я просто в более доступном виде не видел описания утилит для работы с AD на русском языке.

Здесь запись 229137f9-6e82-4293-8ac-4e69d4a2c037, - она не встречается в DNS или AD у меня, а в логе есть.

Ошибка на НОВОМ КД - W2k8 в разделе "Служба каталогов":

Эта, вторая запись DSA - 9119974d-4c8a-412a-a0ad-86b357a72fc1 - записана в DNS и AD как имя CORE - старого КД.

По поводу repadmin сейчас отпишусь

P.S. большое спасибо за ответы!
P.P.S. Книжку уже скачал

Вроде бы, все замечательно.

Так, теперь, если я правильно понял, мне необходимо вычистить все записи на ДНСе относительно нового КД. Вопрос: какие именно записи? Абсолютно все?

- в зоне прямого просмотра "папку верхнего уровня" и запись А?
- в msdcs псевдоним?
- а также записи _kerberos, _kpasswd, _ldap и _gc в разделах dc/domains/gc/pdc?

И в зоне обратного просмотра айпишник/имя сервера?

Или достаточно удалить запись типа А и Псевдоним CNAME?

После удаление мне надо будет перерегистрироваться в ДНС и посмотреть, что будет, верно?

Я бы вычистил все записи и после этого дал команду регистрации в dns, ну а потом поднял бы DNS на новом кд.

Ну хорошо, проделал

Удалил все SRV-записи, установил ДНС, теперь мне ситуация еще более не понятна.

Ошибки остались все те же самые. В лог они валятся ИСКЛЮЧИТЕЛЬНО при загрузке ОСи на новом КД.

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

Repadmin:

Возможно, задержки в сети влияют на произведение репликации при загрузке? КД подключены в d-link des 3526. Он поддерживает STP, только он отключен:

Может, как-нибудь заставить запускаться DNS и AD с задержкой? Скажем, секунд в 30 или 60, пока все фоновые службы не стартанут.

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

DNS и AD пытаются начать работу сразу, как начинает грузиться ОСь, а сетевая карта ТОЛЬКО когда происходит ЛОГОН, т.е. на 2 с лишним минуты позже, чем вышеупомянутые службы уже пытаются начать работу.

Можно ли как-нибудь заставить сетевушку работать уже на этапе биоса?

Intel 82574L и 82578DM

Или, может, не в сетевушках дело, а в ОСи? Может, настройка какая?

А вот это странно, поскольку такого не может быть, старт сетевых сервисов должен происходить после поднятия карточек, посмотрите зависимость старта сервисов. Из вашей фразы можно предположить, что в сервере 2-е карты, может вся сложность именно из наличия 2-х карт? snorlov писал(а): А вот это странно, поскольку такого не может быть, старт сетевых сервисов должен происходить после поднятия карточек, посмотрите зависимость старта сервисов. Из вашей фразы можно предположить, что в сервере 2-е карты, может вся сложность именно из наличия 2-х карт?

В том то и дело, что такого не должно происходить.

Эти сетевые карточки идут вместе с какой то управляющей утилитой, которая загружается исключительно при логоне пользователя в систему/домен. До этого они мертвые и никакого коннекта по сети нет.

я проанализировал логи, сверял время запуска AD/DNS/RDP с моментом старта сетевушек.

Сеть поднималась только когда я залогинивался в домене. Это абсолютно неприемлемо даже с точки зрения возможного отключения электричества - вот вырубится свет, УПС продержит сервак, потом тот уйдет в офф. Boot on power есть, но если сервак загрузится, то еще необходимо залогиниться, чтобы он стал в сети доступен

Обидно, жалко и непонятно, но я просто вставил Realtek в сервак и все проблемы сразу решились. Те ошибки, которые постил ушли, остались предупреждения про сертификаты Kerberos (RDP) и SASL аутентификация (AD). Но, это меня уже почти не волнует.

Точно также не поленился и опробовал Acorp - грузится замечательно. Сетевая карта оживает сразу после загрузки биоса.

Описание проблемы с вводом в домен

По идее присоединение компьютера к Active Directory это простое действие, но как оказалось даже оно может принести сложности. У меня была старая виртуальная машина на Hyper-V, поступила задача ее переустановить для тестовых служб. По идее старая учетная запись этого компьютера лежала в нужно OU и к ней применялись нужные политики доступа, логично, что я воспользовался механизмом переустановки учетной записи, доступный через правый клик по ней. Это является правильной практикой, которую советует сама Microsoft

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

"Не удалось изменить DNS-имя основного контроллера домена на "" для этого компьютера. Будет использоваться прежнее имя: contoso.com. Убедитесь, что имя "" является допустимым для текущего домена. Ошибка: При изменении имени узла DNS для объекта невозможно синхронизировать значения имени субъекта службы"

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

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

Причины ошибки "Не удалось изменить DNS-имя основного контроллера домена"

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

Остались хвосты от предыдущей учетной записи с тем же именем
Проблема в отключенном NetBIOS в TCP/IP
Режет пакеты Firewall
На контроллере закрыт UDP-порт 137
Отсутствует PTR запись на dns имя этой учетной записи компьютера

Чистим старые хвосты в Active Directory

Сразу хочу отметить, что данный способ у меня отработал сразу. Я полностью удалил учетную запись компьютера, с которым были проблемы. После чего снова добавил нужный сервер в домен, и он уже не выдавал ошибку "Не удалось изменить DNS-имя основного контроллера домена на "" для этого компьютера". Учетная запись появилась в привычном контейнере "Computers"

Убедитесь, что включен NetBIOS через TCP/IP

Нажмите WIN+R и введите ncpa.cpl, у вас откроется окно "Панель управления\Все элементы панели управления\Сетевые подключения". Выберите ваш сетевой интерфейс, который смотрит в туже сеть, что и DC его аутентифицирующий. Перейдите в свойства сетевого интерфейса, выберите "Протокол Интернета версии 4 (TCP/IPv4)", далее кнопка "Дополнительно". На вкладке WINS, вам необходимо выбрать пункт "Включить NetBIOS" через TCP/IPv4 и сохранить настройки.

Так же на вкладке DNS, вы можете прописать дополнительные DNS суффиксы (полное имя домена), нажмите ок.

В принципе этого достаточно, чтобы избавится от ошибки ""Не удалось изменить DNS-имя основного контроллера домена на "" для этого компьютера. Будет использоваться прежнее имя: contoso.com. Убедитесь, что имя "" является допустимым для текущего домена. Ошибка: При изменении имени узла DNS для объекта невозможно синхронизировать значения имени субъекта службы""

Если вам не помогли манипуляции, то ставьте варшарк и смотрите трафик и доступность портов, не блокирует ли у вас то-то.

Computer Name: SERV
DNS Host Name: serv.stream.local
System info : Microsoft Windows Server 2003 (Build 3790)
Processor : x86 Family 15 Model 3 Stepping 4, GenuineIntel
List of installed hotfixes :
KB890046
KB893756
KB896358
KB896422
KB896424
KB896428
KB899587
KB899588
KB899589
KB899591
KB900725
KB901017
KB901214
KB902400
KB904706
KB904942
KB905414
KB908519
KB908531
KB910437
KB911280
KB911562
KB911564
KB911567
KB911897
KB911927
KB912919
KB914388
KB914389
KB914783
KB916281
KB917159
KB917344
KB917422
KB917734
KB917953
KB918439
KB918899
KB920213
KB920214
KB920670
KB920683
KB920685
KB921398
KB921883
KB922582
KB922616
KB922819
KB923191
KB923414
KB923689
KB923694
KB923980
KB924191
KB924496
KB925398_WMP64
KB925454
KB929969
Q147222

Per interface results:

Netcard queries test . . . : Passed

Host Name. . . . . . . . . : serv
IP Address . . . . . . . . : 192.168.7.1
Subnet Mask. . . . . . . . : 255.255.255.0
Default Gateway. . . . . . :
Dns Servers. . . . . . . . : 192.168.7.1
192.168.7.2

AutoConfiguration results. . . . . . : Passed

Default gateway test . . . : Skipped
[WARNING] No gateways defined for this adapter.

WINS service test. . . . . : Skipped
There are no WINS servers configured for this interface.

Adapter : Inet 192.168.100.155

Netcard queries test . . . : Passed

Host Name. . . . . . . . . : serv
IP Address . . . . . . . . : 192.168.100.155
Subnet Mask. . . . . . . . : 255.255.255.0
Default Gateway. . . . . . : 192.168.100.1
Dns Servers. . . . . . . . : 192.168.100.1

AutoConfiguration results. . . . . . : Passed

Default gateway test . . . : Passed

WINS service test. . . . . : Skipped
There are no WINS servers configured for this interface.

Domain membership test . . . . . . : Passed

NetBT transports test. . . . . . . : Passed
List of NetBt transports currently configured:
NetBT_Tcpip_
NetBT_Tcpip_
2 NetBt transports currently configured.

Autonet address test . . . . . . . : Passed

IP loopback ping test. . . . . . . : Passed

Default gateway test . . . . . . . : Passed

Winsock test . . . . . . . . . . . : Passed

Redir and Browser test . . . . . . : Passed
List of NetBt transports currently bound to the Redir
NetBT_Tcpip_
NetBT_Tcpip_
The redir is bound to 2 NetBt transports.

List of NetBt transports currently bound to the browser
NetBT_Tcpip_
NetBT_Tcpip_
The browser is bound to 2 NetBt transports.

DC discovery test. . . . . . . . . : Passed

DC list test . . . . . . . . . . . : Passed

Trust relationship test. . . . . . : Skipped

Kerberos test. . . . . . . . . . . : Passed

LDAP test. . . . . . . . . . . . . : Passed

Bindings test. . . . . . . . . . . : Passed

WAN configuration test . . . . . . : Skipped
No active remote access connections.

Modem diagnostics test . . . . . . : Passed

IP Security test . . . . . . . . . : Skipped

Note: run "netsh ipsec dynamic show /?" for more detailed information

Domain Controller Diagnosis

Performing initial setup:
Done gathering initial info.

Doing initial required tests

Doing primary tests

SYSVOL has been shared. Failing SYSVOL replication problems may cause

Group Policy problems.
. SERV failed test frsevent
Starting test: kccevent
. SERV passed test kccevent
Starting test: systemlog
. SERV passed test systemlog
Starting test: VerifyReferences
. SERV passed test VerifyReferences

Running partition tests on : TAPI3Directory
Starting test: CrossRefValidation
. TAPI3Directory passed test CrossRefValidation
Starting test: CheckSDRefDom
. TAPI3Directory passed test CheckSDRefDom

Running partition tests on : ForestDnsZones
Starting test: CrossRefValidation
. ForestDnsZones passed test CrossRefValidation
Starting test: CheckSDRefDom
. ForestDnsZones passed test CheckSDRefDom

Running partition tests on : DomainDnsZones
Starting test: CrossRefValidation
. DomainDnsZones passed test CrossRefValidation
Starting test: CheckSDRefDom
. DomainDnsZones passed test CheckSDRefDom

Running partition tests on : Schema
Starting test: CrossRefValidation
. Schema passed test CrossRefValidation
Starting test: CheckSDRefDom
. Schema passed test CheckSDRefDom

Running partition tests on : Configuration
Starting test: CrossRefValidation
. Configuration passed test CrossRefValidation
Starting test: CheckSDRefDom
. Configuration passed test CheckSDRefDom

Running partition tests on : stream
Starting test: CrossRefValidation
. stream passed test CrossRefValidation
Starting test: CheckSDRefDom
. stream passed test CheckSDRefDom

Читайте также: