У нас были странные проблемы при переносе доменов из одного леса в другой. Мы попытались отключить контроллеры домена для старого домена, и внезапно общий ресурс, к которому у нас был доступ, в еще одном домене, в его собственном лесу, исчез.
У меня проблемы с пониманием того, как клиенты Windows разрешают общие ресурсы. т.е. когда я набираю \ XXXXXX \ yyy \ zzzz, что именно делает Windows, чтобы определить, к какому серверу подключиться? Обратите внимание, что раньше у нас был общий ресурс DFS в старом домене, так что это играет роль.
Есть ли инструменты, которые помогут вам отследить, что делает Windows? то есть что-то, что регистрирует что-то вроде этого, если я дал ему путь \ XXXXXX \ yyy \ zzzz Проверка имени в локальной NETBIOS. Не нашел имени в нетбиосе. Проверка кеша DFS ... Найдено в кеше DFS, используя \ computer.domain.com \ share для \ XXXXX \ yyy \ zzzz
Вот и вся история. Мы выполняем миграцию с одного домена D1.xxxx.com на D2.yyyy.com в другом лесу. У нас есть междоменное доверие, и все было перемещено, кроме DFS. Мы решили прекратить использование DFS в домене 2 из-за всех головных болей, которые у нас были. Вместо этого у нас будет хост в D2 с именем D1, который будет обслуживать всю DFS. Настроили и скопировали все файлы. Затем мы отключаем все контроллеры домена для D1 и удаляем доверие. Теперь я ожидаю, что машины в домене D2 перейдут к общему ресурсу с именем root на D1.yyyy.com, когда я наберу \ D1 \ root \ things. По какой-то причине этого не происходит, и я не могу понять почему. Я пытаюсь использовать dfsutil / pkflush на клиентской машине, но все равно ничего не получается.
Теперь я хотел бы увидеть, что именно делает моя клиентская машина при попытке подключиться к \ D1 \ root \ things. Наблюдение за тем, что происходит в сети, не помогает. Я знаю (или почти уверен), что он все еще пытается перейти на старую общую папку DFS.
Вы должны задать вопрос, как Windows разрешает имена компьютеров или DFS.
Хорошо, пример
Servername = server
доменное имя = dom.local
FQDN сервера = server.dom.local
DNS-суффикс ВАШЕГО компьютера = dom.local
Путь к общему ресурсу состоит из двух частей. Сервер или имя хоста «\ servername» и сам общий ресурс «share1» Сначала давайте посмотрим, что происходит, когда Windows разрешает имя в IP, используя в качестве примера команду ping.
ты бежишь ping server чтобы получить IP. На этом этапе ваш компьютер просматривает свою конфигурацию TCP / IP и получает IP-адрес DNS-сервера. Затем он запрашивает этот DNS-сервер для разрешения имени ... или он может использовать WINS (объяснено ниже).
Многие люди теперь думают: «О да, это легко, он будет запрашивать DNS-сервер, я знал, что это было очевидно». Не так! Он не всегда запрашивает DNS-сервер, и здесь люди запутываются. вот что происходит на самом деле:
Ваш компьютер ВСЕГДА будет сначала пытаться преобразовать это имя в DNS-имя. в противном случае он попытается запросить WINS-сервер (если локальный ПК был настроен с таким), если это не удастся, он выполнит широковещательную рассылку NetBIOS. ВСЕГДА в таком порядке.
Теперь обратите внимание на DNS-суффикс, о котором я упоминал выше. если бы это было что-то другое, кроме dom.local, этот пинг завершился бы ошибкой. Это связано с тем, что при пинге я не набирал полное доменное имя server.dom.local, а вместо этого использовал его часть просто «сервер». Что Windows делает в фоновом режиме, так это ДОБАВЛЯЕТ его с суффиксом DNS (для этого он и нужен). Поэтому, когда вы набираете ping server, вы фактически увидите, что Windows затем говорит «pinging server.dom.local», обратите внимание, что это полное доменное имя. Надеюсь, вы понимаете, куда я иду с DNS-запросами. Поскольку у вас есть два отдельных домена, суффиксы DNS могут быть разными. Если, например, мой суффикс dns был dom2.local, когда я проверял сервер, он добавлял бы его с этим суффиксом и ПЫТАЛСЯ на ping server.dom2.local. Опять же, путаница возникает из-за того, что он на самом деле не говорит об этом на экране (потому что он не работает), поэтому люди ДУМАЮТ, что он запрашивает server.dom.local, хотя на самом деле это не так. Если это не удается через DNS, он переходит на WINS, а затем на NetBIOS. На самом деле отображается «сервер проверки связи», если он разрешен другими способами. Заметили тонкую разницу между ними? Когда запрос работает с DNS, он говорит «pinging server.dom.local», когда он терпит неудачу и разрешается с помощью WINS или NetBIOS, вместо этого он говорит «pinging server». Это то, что вы должны проверить, чтобы увидеть, правильно ли он разрешает имя через DNS. большинство людей пингуют имя и получают ответ и думают, что DNS работает, потому что он разрешает имя. Они никогда не обращают внимания на тот факт, что он не разрешает полное доменное имя, хотя это означает, что DNS на самом деле не работает. С ДВУМЯ ДОМЕНАМИ В ИГРЕ ЭТО ОЧЕНЬ ВАЖНО и может легко вызвать хаос с точки зрения разрешения имен, если вы не будете бдительны. Большинство людей блаженно не осознают этого, потому что у них есть только один домен. Им никогда не нужно знать, для чего нужен DNS-суффикс.
На этом этапе вы должны знать, на каком IP-адресе находится ваш общий ресурс. То же самое и с деревом DFS. Ping имя DFS и возвращаемый IP-адрес сообщают вам, где находится корень DFS. Забудьте пока о DFS. возвращаясь к ПК ... если ваш DNS-запрос разрешает имя машины, то именно там и находится ваш общий ресурс, простой и понятный.
Если запрос относится к пространству имен DFS, найдите сервер и загрузите консоль управления DFS. допустим, это был \ dom.local \ share1. В этом примере вы выполнили ping-запрос dom.local и обнаружили, что он разрешен до 192.168.5.4. Вы RDP к этому и загружаете диспетчер DFS и теперь localte "share1". Диспетчер DFS сообщит вам, находится ли он на локальном сервере или перенаправляет на другой сервер. Оттуда вы просто следуете за хлебными крошками, пока не дойдете до фактического сервера, а затем поделитесь им.
Теперь имеет смысл?
Хорошо, отвечая на ваши дополнительные подробности ... Я не думаю, что вы читаете мой пост должным образом и подозреваете, что происходит ... вот и все.
Помните, я говорил выше о суффиксах домена DNS и почему они так важны при переносе доменов ??? Допустим, на этом компьютере, на котором вы пытаетесь подключиться к общим ресурсам, все еще есть суффикс dns старого домена, то есть xxxx.com. Когда вы вводите или проверяете D1, он добавляет этот DNS-суффикс в конце. так что на самом деле он подключается к d1.xxxx.com ... он больше не существует, когда вы удаляете свой домен xxxx.com. Попробуйте подключиться к \ d1.yyyy.com\ root \ things, а не только \ d1 \ root \ things. Дайте мне знать, если это сработает, мы можем продолжить
Я верю, что в этой конкретной ситуации может пригодиться что-то вроде Wireshark. Он также показывает запросы DNS.