У меня есть рабочая станция XP в удаленной подсети, которая не может загружать групповые политики. Записи журнала событий довольно четкие. После устранения неполадок становится ясно, что рабочая станция не может преобразовать DNS доменов во что-то, к чему она может подключиться.
\\ our.ad.dns.domain \ SysVol \ our.ad.dns.domain \ Policies {5310CCFF-43F3-4424-A7AC-96942D065331} \
Не рассосется. "net view \\ our.ad.dns.domain" возвращает "сетевой путь не найден".
Тем не менее, nslookup на our.ad.dns.domain возвращает IP-адреса всех контроллеров домена. Более того, они работают:
Так что он может нормально разговаривать с DC, как только выяснит, как туда добраться.
Первоначально проблема представлялась как невозможность входа в систему, которая была отслежена из-за невозможности разрешить одно из имен контроллера домена, «addc3». Ошибка "net view \\ addc3": "сетевой путь не найден". После того, как мы добавили запись ADDC3 в WINS (да, она все еще есть), разрешение начало работать.
Таким образом, разрешение WINS работает нормально, но по какой-то причине поиск DNS не выполняется при разрешении адресов Windows.
К сожалению для всех участников, эта подсеть обслуживается DHCP-сервером ISC, к которому у меня нет доступа. Все остальные подсети, кроме двух, обслуживаются серверами Microsoft DHCP, к которым у меня ДЕЙСТВИТЕЛЬНО есть доступ. Так что это может быть плохой вариант DHCP, но я не могу войти и не знаю, какие вопросы нужно задать сетевым специалистам.
Вероятно, они забыли установить суффикс поиска DNS. Обратите внимание, что вы получаете только 1 (вариант 15), поэтому, если вы хотите больше, вы должны удаленно отредактировать реестр или запустить сценарий, подобный этому ..
SET WSHShell = CreateObject("WScript.Shell")
WSHShell.RegWrite "HKLM\System\CurrentControlSet\Services\TCPIP\Parameters\SearchList", "testdom.com,test2dom.com,test3dom.com", "REG_SZ"
Также убедитесь, что netbios через tcp / ip включен, а вспомогательная служба TCP / IP NetBIOS включена и работает.