8524 операция dsa не смогла быть выполнена т к произошла ошибка поиска в dns
Итак, я наконец то собрался с силами и, отбросив лень, сел плавненько переезжать на 2008 Server R2 с 2003 Server R2, где крутилась АД в режиме работы леса и домена 2003.
Выполнил adprep для леса и домена, все прошло успешно.
Взял один из этих двух КД и переставил на нем ОСь на Windows Server 2008 R2.
Добавил машинку в домен, поднял роль АД. ДНС добавился автоматически. Открываю AD, смотрю на данные - вроде бы все замечательно отреплицировалось, даные перенеслись, новый, только что установленный сервак отображается в списке Контроллеров Домена.
Однако, решил прочитать журнал DNS на всякий пожарный и хорошо, что прочитал:
Как же тогда я вижу данные в АД все? и в ДНС?
Брандмауэр на серваке отлючен, пользователь обладает правами администратора.
Может быть я неверно указал настройки для ДНСов? Сейчас схема такая.
КД1 (с которого надо все стянуть на 2008 R2):
Правда не понятен откуда взят адрес 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 - тут получил ошибку:
что делать дальше? мне не нравится выполнение 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:
Может, как-нибудь заставить запускаться 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 - грузится замечательно. Сетевая карта оживает сразу после загрузки биоса.
В этой статье описываются симптомы, причины и действия по разрешению операций 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 для компьютеров, если он отличается от доменного имени Active Directory (см. статью Technet Disjoint Namespace).
Параметры проверки того, что DNS Server хостов, переадтрансаторов или делегатов (то есть "можно разрешить") такие зоны включают в себя:
Запустите средство управления DNS для DNS и убедитесь, что DNS Servers, на которые указывает источник DC для разрешения имен, являются зонами, о которых идет речь.
Используйте NSLOOKUP, чтобы убедиться, что все DNS Servers, на которые указывает источник DC, могут решать запросы для зон DNS, о чем идет речь.
Запустите 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-серверы, используемые источником и центром назначения, имеют родительские и детские связи, проверьте:
Для отключения данного рекламного блока вам необходимо зарегистрироваться или войти с учетной записью социальной сети.
10.0.0.1 - щлюз.10.0.0.2 - DNS.
Оба на FreeBsd.
DNS на контроллере домена не поднимал. Вообще обязательно ли поднимать DNS на контроллере домена, либо можно обойтись другим? В планах запустить вторичный DNS на контроллере, но сначала хотелось бы, чтоб нормально работала репликация между контроллерами.
| Вообще обязательно ли поднимать DNS на контроллере домена, либо можно обойтись другим? » |
1. Обязательно.
2. Нельзя, если не хотите проблем.
3. среди DNS-серверов для всех ПК сети должны быть уазаны два DNS-сервера, находящиеся на контроллерах домена.
DNS-сервера на контроллерах домена могут иметь forward или корневые ссылки для разрешения имен за пределами домена.
PS: подняв DNS-сервера, на обоих серверах пропишите по 2 DNS: 127.0.0.1 и адрес другого контроллера.
Но DNS (он же DHCP) сервер 10.0.0.2 у нас основной и убрать его нет возможности.
Подскажите как поступить в таком случае. Может на PDC поднять вторичный DNS сервер, а на BDC реплицировать AD? И как все будет работать в таком случае при выходе из строя PDC?
| 1. Обязательно. 2. Нельзя, если не хотите проблем. 3. среди DNS-серверов для всех ПК сети должны быть уазаны два DNS-сервера, находящиеся на контроллерах домена. DNS-сервера на контроллерах домена могут иметь forward » |
Все ПК домена, особенно контроллеры должны иметь в DNS-серверах только DNS-сервера контроллеров домена.
А на DNS-ах контроллеров (на обоих, т.к. forward реплиицируется только на W2008) сделайте forward на Ваш бесценный 10.0.0.2
PS: forward хорош, когда тот сервер имеет корневые ссылки и сам занимается разрешением имен, а не пересылает запросы серверу провайдера. например, ***телеком (Домолинк) грешит тем, что в некоторых регионах его DNS-сервера часто ложатся или тупят. и получается, что Инет вроде есть, но без рабочего DNS на страницы не выйдешь! Т.о. если используете DNS провайдера через forward, убедитесь в его надежности, а лучше сами настройте у себя корневые ссылки.
ПОМОГИТЕ. КУДА РЫТЬ. Весь Инет сегодня перерыл :(
В журнале ошибок на основном контроллере:
Неудачная попытка установить связь репликации с параметрами
Раздел: CN=Schema,CN=Configuration,DC=aaelk82
DN исходного DSA: CN=NTDS Settings,CN=SERVER-K86,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=aaelk82
Адрес исходного DSA: 5418117d-9bb7-4564-b914-5421e179c690._msdcs.aaelk82
Межсайтовый транспорт (если есть):
прервана в следующем состоянии:
Операция DSA не смогла быть выполнена, т.к. произошла ошибка поиска в DNS.
dcdiag на дополнительном сообщает:
Doing initial non skippeable tests
Testing server: Default-First-Site-Name\SERVER-K86
Starting test: Connectivity
SERVER-K86's server GUID DNS name could not be resolved to an
IP address. Check the DNS server, DHCP, server name, etc
Although the Guid DNS name
(5418117d-9bb7-4564-b914-5421e179c690._msdcs.aaelk82) couldn't be
resolved, the server name (server-k86.aaelk82) resolved to the IP
address (192.168.2.4) and was pingable. Check that the IP address is
registered correctly with the DNS server.
. SERVER-K86 failed test Connectivity
Doing primary tests
Testing server: Default-First-Site-Name\SERVER-K86
Skipping all tests, because server SERVER-K86 is
not responding to directory service requests
Running enterprise tests on : aaelk82
Starting test: Intersite
. aaelk82 passed test Intersite
Starting test: FsmoCheck
. aaelk82 passed test FsmoCheck
repadmin с основного:
C:\Program Files\Support Tools>Repadmin /showreps
Default-First-Site-Name\SERVER-K82
DSA Options : IS_GC
objectGuid : 46980095-1384-4216-afa9-ffd08c7125c9
invocationID: 46980095-1384-4216-afa9-ffd08c7125c9
==== OUTBOUND NEIGHBORS FOR CHANGE NOTIFICATIONS ==========
CN=Schema,CN=Configuration,DC=aaelk82
Default-First-Site-Name\SERVER-K86 via RPC
objectGuid: 5418117d-9bb7-4564-b914-5421e179c690
CN=Configuration,DC=aaelk82
Default-First-Site-Name\SERVER-K86 via RPC
objectGuid: 5418117d-9bb7-4564-b914-5421e179c690
DC=aaelk82
Default-First-Site-Name\SERVER-K86 via RPC
objectGuid: 5418117d-9bb7-4564-b914-5421e179c690
с дополнительного
C:\>Repadmin /showreps
Default-First-Site-Name\SERVER-K86
DSA Options : (none)
objectGuid : 5418117d-9bb7-4564-b914-5421e179c690
invocationID: 5b4164c0-fb1e-43ac-a8ae-fda39fd54202
Читайте также: