Windows не удалось получить имя контроллера домена возможная причина ошибка разрешения имен

Обновлено: 03.07.2024

Итак, я наконец то собрался с силами и, отбросив лень, сел плавненько переезжать на 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 - грузится замечательно. Сетевая карта оживает сразу после загрузки биоса.

Вот как более детально выглядит ошибка при обработке групповой политики. Событие с кодом ID 1054: Windows не удалось получить имя контроллера домена. Возможная причина: ошибка разрешения имен. Проверьте, что служба DNS настроена и работает правильно.

Ошибка при обработке групповой политики. Windows не удалось получить имя контроллера домена

Проверка разрешения имен

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

dc1 это мой контроллер домена. Как видите у меня локальные DNS имена разрешал, внешний DNS сервер, так как на сервере стоит два сетевых интерфейса и один со внешним ip адресом.

причину мы выяснили, из за чего выскакивает ошибка.

Приоритетность контроллеров домена

Давайте теперь посмотрим, какой из контроллеров домена является для вашего сервера самым авторитетным, ранее я уже рассказывал как определить какой domain controller вас авторизовал, но нам нужен авторитет в вашем домене и возможность обращение к нему по LDAP. Делается это командой

Я вижу что у меня это dc2, его ip адрес мне и понадобится.

Ошибка при обработке групповой политики. Windows не удалось получить имя контроллера домена

Так же нужно проверить доступность DC по протоколу RPC, с помощью команды

доступность DC по протоколу RPC

В данном случае проблем я не обнаружил. Пилим дальше.

Настройка DNS на внешнем сетевом интерфейсе

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

настройка dns сервера

Теперь снова выполним команду nslookup и видим, что теперь внутренние имена разрешаются внутренним DNS сервером.

Видим, что все обновилось корректно и проблема при обработке групповой политики, об этом сообщает событие с кодом ID 1502. Windows не удалось получить имя контроллера домена. Возможная причина: ошибка разрешения имен. Проверьте, что служба DNS настроена и работает правильно в Windows Server 2012 R2 ушла.

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

Настройка протокола IP для Windows

Ethernet adapter Подключение по локальной сети:

DNS-суффикс подключения . . . . . :
Описание. . . . . . . . . . . . . : Qualcomm Atheros AR8161/8165 PCI-E Gigabit Ethernet Controller (NDIS 6.20)
Физический адрес. . . . . . . . . : 94-DE-80-21-B2-1B
DHCP включен. . . . . . . . . . . : Нет
Автонастройка включена. . . . . . : Да
IPv4-адрес. . . . . . . . . . . . : 10.1.51.5(Основной)
Маска подсети . . . . . . . . . . : 255.255.255.0
Основной шлюз. . . . . . . . . : 10.1.51.1
DNS-серверы. . . . . . . . . . . : 10.1.65.51
10.1.51.5
NetBios через TCP/IP. . . . . . . . : Включен

Состояние среды. . . . . . . . : Среда передачи недоступна.
DNS-суффикс подключения . . . . . :
Описание. . . . . . . . . . . . . : Адаптер Microsoft ISATAP
Физический адрес. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP включен. . . . . . . . . . . : Нет
Автонастройка включена. . . . . . : Да

Туннельный адаптер Teredo Tunneling Pseudo-Interface:

Состояние среды. . . . . . . . : Среда передачи недоступна.
DNS-суффикс подключения . . . . . :
Описание. . . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
Физический адрес. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP включен. . . . . . . . . . . : Нет
Автонастройка включена. . . . . . : Да

ipconfig /all с клиента

Подключение по локальной сети - Ethernet адаптер:
DNS-суффикс этого подключения . . :
Описание . . . . . . . . . . . . : Realtek PCIe GBE Family Controller
Физический адрес. . . . . . . . . : F0-79-59-5C-01-8B
Dhcp включен. . . . . . . . . . . : нет
IP-адрес . . . . . . . . . . . . : 10.1.51.251
Маска подсети . . . . . . . . . . : 255.255.255.0
Основной шлюз . . . . . . . . . . : 10.1.51.1
DNS-серверы . . . . . . . . . . . : 10.1.51.5
10.1.65.51

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

Применяется к: Windows Server 2012 R2, Windows Server 2016
Исходный номер КБ: 292822

Симптомы

Компьютер под управлением Microsoft Windows 2000 Server или Microsoft Windows Server 2003 может иметь проблемы с подключением, если сервер настроен следующим образом:

Служба маршрутного и удаленного доступа настроена для разрешения входящих подключений.
На сервере, на который запущен маршрут и удаленный доступ, установлена и настроена служба Windows доменного имени (DNS) или Windows Сервер имени Интернета (WINS).

После подключения удаленного компьютера к серверу маршрутов и удаленного доступа с помощью подключения к виртуальной частной сети (VPN) может возникать один или несколько следующих симптомов:

Сервер не отвечает, когда клиент запрашивает обновление.
Возможные причины:
-Сервер не является сервером ISA.
-Сервер не съехался.

При попытке с помощью сервера маршрутизов и удаленного доступа с локального компьютера с помощью имени NetBIOS сервера или полностью квалифицированного доменного имени (FQDN) компьютер пытается цитировать неправильный IP-адрес.

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

Нет серверов Logon, доступных для обслуживания вашего запроса logon

Эта проблема обычно затрагивает компьютеры с сервером малого бизнеса, так как эта версия Windows Server часто является единственным сервером в сети. Однако эта проблема может затронуть Windows 2000-сервер или любой сервер на Windows Server 2003 и сервер удаленного доступа, работающий с DNS или службой WINS.

Причина

Когда удаленный компьютер подключается к серверу маршрутного и удаленного доступа с помощью набора или VPN-подключения, сервер создает адаптер протокола точки к точке для связи с удаленным компьютером. Затем сервер может зарегистрировать IP-адрес этого адаптера PPP в DNS или базе данных WINS.

Когда сервер маршрутивки и удаленного доступа регистрирует IP-адрес своего адаптера PPP в DNS или WINS, при попытке подключения к серверу на локальных компьютерах могут возникнуть ошибки. Вы получаете эти ошибки, так как серверы DNS или WINS могут возвращать IP-адрес адаптеров PPP на компьютеры, запрашивающий DNS или WINS для IP-адреса сервера. Затем компьютеры пытаются подключиться к IP-адресу адаптеров PPP. Из-за того, что локальные компьютеры не могут достичь адаптеров PPP, подключение не удается.

Решение

В этот раздел, описание метода или задачи включены действия, содержащие указания по изменению параметров реестра. Однако неправильное изменение параметров реестра может привести к возникновению серьезных проблем. Поэтому следует в точности выполнять приведенные инструкции. Для дополнительной защиты создайте резервную копию реестра, прежде чем редактировать его. Так вы сможете восстановить реестр, если возникнет проблема. Дополнительные сведения см. в дополнительных сведениях о том, как создать и восстановить реестр в Windows

Чтобы устранить эту проблему, настройте сервер маршрутов и удаленного доступа, чтобы он не зарегистрировал IP-адрес адаптеров PPP в DNS или базе данных WINS. Для этого выполните следующие действия:

Настройка сервера маршрутов и удаленного доступа для публикации только IP-адреса локального сетевого адаптера в DNS

Выполните действия в этом разделе только в том случае, если на сервере маршрутики и удаленного доступа работает служба DNS. Если на сервере не работает служба DNS, перейдите к серверу Настройка маршрутного и удаленного доступа, чтобы зарегистрировать только IP-адрес локального сетевого адаптера в разделе WINS.

Добавление значений реестра PublishAddresses и RegisterDnsARecords для служб DNS и Netlogon

Выберите Начните, выберите Выполнить, введите regedit, а затем выберите ОК.

Найдите и выберите следующий подкай реестра: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters

В меню Редактирование указать значение New, а затем выберите строковую ценность, чтобы добавить следующее значение реестра:

Имя значения: PublishAddresses
Тип данных: REG_SZ
Данные о значении: IP-адрес локального сетевого адаптера сервера. Если необходимо указать несколько IP-адресов, разделять адреса с пробелами.

Найдите и выберите следующий подкай реестра: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

В меню Редактирование указать значение New, а затем выберите значение DWORD, чтобы добавить следующее значение реестра:

Имя значения: RegisterDnsARecords
Тип данных: REG_DWORD
Данные значения: 0

Закрой редактор реестра, а затем перезапустите службы DNS и Netlogon. Чтобы перезапустить службу, выберите Пуск, указать на программы или все программы, указать на административные средства, а затем выбрать службы. В консоли Services щелкните правой кнопкой мыши службу и выберите перезапуск.

Добавление записей A в DNS

Выполните эти действия только в том случае, если сервер маршрутивки и удаленного доступа является контроллером домена.

Выберите Начните, указать на программы или все программы, указать на административные средства, а затем выберите DNS.

В консоли DNS раздвигаем объект сервера, расширяем папку Зоны смотра вперед, а затем выберите папку для локального домена.

В меню Действия выберите Новый хост.

В текстовом поле IP-адреса введите IP-адрес локального сетевого адаптера сервера.

Оставьте поле Имя пустым, выберите Создать связанную запись PTR, а затем выберите Add Host.

Если сервер является глобальным сервером каталогов, перейдите к шагу 7. Если сервер не является глобальным сервером каталогов, вам не нужно выполнить действия с 7 по 11. Чтобы определить, является ли сервер глобальным сервером каталогов, выполните следующие действия:

Выберите Начните, указать на программы или все программы, указать на административные средства, а затем выберите сайты и службы Active Directory.
В консоли Active Directory Sites and Services разложите папку Sites, расширьте сайт, содержащий сервер, а затем расширите объект сервера.
Щелкните правой кнопкой мыши NTDS Параметры, а затем выберите Свойства.
На вкладке General найдите поле "Глобальный каталог". Если этот контрольный ящик проверяется, сервер — это сервер глобального каталога.

В папке Зоны forward Lookup в консоли DNS разложите папку для локального домена, разложите папку MSDCS и выберите папку GC.

В меню Действия выберите Новый хост.

В поле IP-адрес введите IP-адрес локального сетевого адаптера сервера.

Оставьте поле Имя пустым, выберите Создать связанную запись PTR, а затем выберите Add Host.

Настройка сервера маршрутов и удаленного доступа для регистрации только IP-адреса локального сетевого адаптера в WINS

Выполните действия в этом разделе только в том случае, если на сервере маршрутов и удаленного доступа работает служба WINS. Кроме того, если на сервере работает сервер малого бизнеса 2000 SP1, сервер малого бизнеса 2000 SP1a или Windows Small Business Server 2003, вам не нужно завершать действия в этом разделе. По умолчанию эти версии сервера Windows настраиваются, чтобы предотвратить регистрацию IP-адреса адаптеров PPP в базе данных WINS.

Добавление значения реестра DisableNetbiosOverTcpip для службы маршрутизации и удаленного доступа

Значение реестра DisableNetbiosOverTcpip отключает протокол NetBIOS по TCP/IP (NetBT) для подключений к удаленному доступу. Таким образом, сервер не будет регистрировать адаптер PPP в базе данных WINS. Знайте, что при добавлении этого значения клиенты удаленного доступа не могут просматривать локализованную сеть через "Мои сетевые места" или "Сетевое соседство". Иногда это также может привести к неудаче подключения к удаленному доступу на компьютерах с более старыми версиями Windows. Например, подключение к удаленному доступу может быть неудачным на 98 компьютерах Microsoft Windows и на компьютерах microsoft Windows NT 4.0 Workstation. Альтернативу использованию реестра DisableNetbiosOverTcpip см. в разделе Обходное решение.

Если сервер работает Windows 2000 Server SP2 или более ранней версии, необходимо обновить сервер с помощью SP3 или SP4, чтобы значение реестра DisableNetbiosOverTcpip работало. Если не обновить сервер, служба маршрутинга и удаленного доступа не будет использовать это значение реестра, и проблема не будет устранена.

Выберите Начните, выберите Выполнить, введите regedit, а затем выберите ОК.

Найдите и выберите следующий подкай реестра: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RemoteAccess\Parameters\IP

Имя значения: DisableNetbiosOverTcpip
Тип данных: REG_DWORD
Данные значения: 1

Закрой редактор реестра, а затем перезапустите службу маршрутов и удаленного доступа. Чтобы перезапустить службу, выберите Пуск, указать на программы или все программы, указать на административные средства, а затем выбрать службы. В консоли Services щелкните правой кнопкой мыши службу и выберите перезапуск.

Очистка базы данных WINS

Выберите Начните, указать на программы или все программы, указать на административные средства, а затем выбрать WINS.
Развяжите объект сервера, щелкните правой кнопкой мыши Активные регистрации, а затем выберите Удалить владельца.
В диалоговом окне Удалить владельца выберите IP-адрес сервера.
Если на сервере WINS нет партнеров репликации, выберите Удалить только с этого сервера, а затем выберите ОК. Если на сервере WINS имеется один или несколько партнеров репликации, выберите удаление Replicate на другие серверы (надгробие) и выберите ОК.

Сервер WINS будет автоматически восстанавливать базу данных, так как компьютеры в сети регистрируют свои имена NetBIOS. Вы можете Windows компьютеры в сети, чтобы зарегистрировать их имена NetBIOS немедленно, запуская nbtstat -RR команду.

Обходной путь

В качестве обхода этой проблемы можно настроить подключения удаленного доступа к статическому пулу IP-адресов, который находится на другой подсети IP, чем на локальных компьютерах. В этом случае локальные компьютеры не будут пытаться подключиться к адаптеру PPP, если он регистрируется в DNS или WINS, так как адаптер PPP находится на другой подсети IP.

Чтобы указать статичный пул адресов в консоли маршрутизировать и удаленный доступ, щелкните правой кнопкой мыши ServerName, выберите Свойства, выберите вкладку IP, выберите пул статических адресов, а затем выберите Добавить. Добавьте диапазон, который не использует ту же подсеть IP, что и локальные компьютеры. Например, если локальные компьютеры используют подсеть 10.0.0.0, добавьте статический пул, использующий подсеть 172.168.0.0. Если на сервере маршрутизации и удаленного доступа работает ISA Server 2000, необходимо добавить эту подсеть в локализованную адресную таблицу. Этот сценарий наиболее распространен в small Business Server 2000.

Ошибка при обработке групповой политики. Windows не удалось получить имя контроллера домена. Возможная причина: ошибка разрешения имен. Проверьте, что служба DNS настроена и работает правильно в Windows Server 2012 R2

Ошибка при обработке групповой политики. Windows не удалось получить имя контроллера домена

Проверка разрешения имен

причину мы выяснили, из за чего выскакивает ошибка.

Приоритетность контроллеров домена

Я вижу что у меня это dc2, его ip адрес мне и понадобится.

Ошибка при обработке групповой политики. Windows не удалось получить имя контроллера домена

Так же нужно проверить доступность DC по протоколу RPC, с помощью команды

доступность DC по протоколу RPC

В данном случае проблем я не обнаружил. Пилим дальше.

Настройка DNS на внешнем сетевом интерфейсе

настройка dns сервера

Теперь снова выполним команду nslookup и видим, что теперь внутренние имена разрешаются внутренним DNS сервером.

четверг, 23 октября 2014 г.

Ошибка в системном логе "Сбой обработки групповой политики из-за отсутствия сетевого подключения к контроллеру домена" с кодом 1129

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

Зашел на DC, запустил dcdiag и увидел следующую картину

В журнале событий DFS Replication на контроллерах домена были обнаружены следующие события:

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

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

1. Логинимся на PDC

2. Останавливаем службу DFS Replication

2.1. Открывает оснастку Службы (services.msc)

2.2. Останавливаем службу DFS Replication

3. Открываем оснастку ADSI Edit (adsiedit.msc)

4. Открываем Контекст именования по умолчанию (Default naming context)

5. Переходим к свойству CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN= сервер с которого будем реплицировать >,OU=Domain Controllers,DC= ваш домен >

6. Изменяем следующие значения аттрибутов
6.1. msDFSR-Enabled=FALSE
6.2. msDFSR-options=1

7. На всех остальных контроллерах домена изменяем значение аттрибута msDFSR-Enabled на False

8. Производим принудительную репликацию в домене (необходимо убедиться, что нет ошибок)

9. Запускаем службу DFS Replcation на PDC
10. Возвращаемся в оснастку ADSI Edit (adsiedit.msc) и изменяем значение аттрибута msDFSR-Enabled на True
11. Выполняем комманду DFSRDIAG POLLAD (можно не выполнять, однако Microsoft рекомендует)

12. Принудительно производим репликацию на всех остальных контроллерах

13. На всех остальных контроллерах домена изменяем значение аттрибута msDFSR-Enabled на True
14. Выполняем комманду DFSRDIAG POLLAD на всех остальных контроллерах домена (можно не выполнять, однако Microsoft рекомендует)

Если все прошло успешно, то количество папок SYSVOL на ваших контроллерах домена будет содержать одинаковое количество политик и они будут успешно применяться

3 Responses

Также еще один неочевидный момент, если у вас несколько доменов и не все контроллеры являются глобальными каталогами не размещайте хозяина инфрастурктуры на контроллере с глобальным каталогом . Это равносильно его отсутствию.

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