Como você descobre como uma máquina Windows está resolvendo um nome de compartilhamento?

Question

Temos tido alguns problemas estranhos ao migrar domínios de uma floresta para outra. Tentamos desativar os controladores de domínio do domínio antigo e, de repente, um compartilhamento ao qual costumávamos ter acesso, em outro domínio, em sua própria floresta desapareceu.

Estou tendo problemas para entender como os clientes do Windows resolvem compartilhamentos. Ou seja, quando eu digito \ XXXXXX \ yyy \ zzzz, o que exatamente o Windows faz para descobrir com qual servidor se conectar? Note que nós costumávamos ter um compartilhamento DFS no domínio antigo também, então isso faz parte.

Existe alguma ferramenta que o ajude a rastrear o que o Windows está fazendo? ou seja, algo que registra algo assim se eu der o caminho \ XXXXXX \ yyy \ zzzz Verificando o nome no NETBIOS local. Não encontrou nome no netbios. Verificando o cache do DFS ... Encontrado no cache do DFS, usando \ computer.domain.com \ share para \ XXXXX \ yyy \ zzzz

Aqui está toda a história. Estamos migrando de um domínio D1.xxxx.com para D2.yyyy.com em uma floresta diferente. Temos uma confiança de domínio cruzado e tudo foi movido, exceto o DFS. Decidimos parar de usar o DFS no domínio 2 por causa de todas as dores de cabeça que tivemos. Em vez disso, teremos um host no D2 chamado D1 que servirá o DFS inteiro. Nós configuramos e copiamos todos os arquivos. Em seguida, desligamos todos os controladores de domínio para D1 e removemos a confiança. Agora, eu esperaria que as máquinas no domínio D2 fossem para o compartilhamento chamado root em D1.yyyy.com quando eu digitar \ D1 \ root \ things. Por alguma razão, isso não parece acontecer e não consigo entender por quê. Eu tento usar dfsutil / pkflush em uma máquina cliente e ainda não há acordo.

O que eu gostaria de fazer agora é ver exatamente o que minha máquina cliente está fazendo ao tentar se conectar a \ D1 \ root \ things. Ver o que acontece na rede não ajuda. Eu sei (ou tenho quase certeza) que ainda está tentando ir para o antigo compartilhamento DFS.

    

Answer 1

A pergunta que você deve fazer é como o Windows resolve nomes de computador ou DFS.

Ok, um exemplo

Nome do servidor = servidor

nome do domínio = dom.local

FQDN do servidor = server.dom.local

Sufixo DNS de SEU pc = dom.local

existem duas partes no caminho de compartilhamento. O servidor ou hostname "\ servername" e o próprio compartilhamento "share1" Primeiro, vamos ver o que acontece quando o windows resolve o nome para IP usando ping como exemplo.

você executa ping server para obter o IP. Neste ponto, seu PC analisa sua configuração TCP / IP e obtém o IP do servidor DNS. Em seguida, ele consulta esse servidor DNS para resolver o nome ... ou pode usar o WINS (explicado abaixo).

muita gente agora pensa "oh sim, é fácil perguntar ao servidor DNS, eu sabia que era óbvio". Não tão! Nem sempre consulta o servidor DNS e é aqui que as pessoas ficam confusas. aqui está o que realmente acontece:

seu PC SEMPRE tentará resolver este nome para um nome DNS primeiro. Caso contrário, ele tentará consultar um servidor WINS (se o PC local tiver sido configurado com um), se isso falhar, ele fará uma transmissão de NetBIOS. é sempre nesta ordem.

Agora, preste atenção ao sufixo DNS mencionado acima. se isso fosse outra coisa senão dom.local, esse ping falharia. Isso ocorre porque quando eu pingado, eu não digite o FQDN de server.dom.local, mas em vez disso, usei parte dele apenas 'servidor'. O que o Windows faz no fundo é APPEND-lo com o sufixo DNS (isto é o que é para). Portanto, quando você digitar ping server, verá que o windows diz "pinging server.dom.local", observe que é o FQDN. Espero que você possa ver onde estou indo aqui com consultas DNS. Como você tem dois domínios separados, os sufixos DNS podem ser diferentes. Se, por exemplo, meu sufixo dns fosse dom2.local quando eu pingasse o servidor, ele o acrescentaria com esse sufixo e tentaria pingar server.dom2.local. Novamente, a confusão vem do fato de que ele não diz na tela (porque falha), então as pessoas PENSAM que está consultando server.dom.local quando na verdade não está. Uma vez que isso falhar via DNS, ele passa para o WINS e, em seguida, para o NetBIOS. O que é realmente exibido é "servidor de ping", uma vez resolvido por outros meios. Observe a diferença sutil entre os dois? Quando uma consulta funciona com o DNS, ele dirá "ping server.dom.local", quando falhar e resolver usando WINS ou NetBIOS, em vez disso, ele dirá "servidor de ping". Isso é algo que você deve testar para ver se está resolvendo o nome pelo DNS corretamente. a maioria das pessoas faz o ping do nome e recebe uma resposta e acha que o DNS está funcionando porque resolve o nome. Eles nunca prestam atenção ao fato de não resolver o FQDN, o que significa que o DNS realmente falhou. COM DOIS DOMÍNIOS EM JOGO, É MUITO IMPORTANTE e pode facilmente causar estragos de uma perspectiva de resolução de nomes, se você não estiver vigilante. A maioria das pessoas não tem consciência disso porque elas possuem apenas um domínio. Eles nunca precisam saber para que serve o sufixo DNS.

Neste ponto, agora você deve saber em qual IP sua participação está. Exatamente o mesmo se aplica à árvore DFS. Efetue ping no nome do DFS e o IP retornado informará onde a raiz do DFS está. Esqueça o DFS no momento. voltando ao PC ... se a sua consulta DNS resolve o nome de uma máquina, então é aí que o seu compartilhamento é simples e simples.

Se a consulta for para um espaço de nome DFS, localize o servidor e carregue o console de gerenciamento do DFS. vamos dizer que foi \ dom.local \ share1. Neste exemplo você pingado dom.local e encontrou resolvido para 192.168.5.4. Você RDP para isso e carregar o gerenciador de DFS e agora localte "share1". O gerenciador do DFS informará se ele está no servidor local ou redireciona para outro servidor. A partir daí, basta seguir as migalhas de pão até chegar ao servidor real e compartilhar subsequentemente.

Faz sentido agora?

Ok, em resposta aos seus detalhes adicionais adicionais ... Eu não acho que você leu o meu post corretamente e suspeita do que está acontecendo..aqui vai.

Lembre-se de que eu disse sobre sufixos de domínio DNS acima e por que eles são tão importantes na transferência de domínios ??? Digamos que este PC que você está tentando conectar aos compartilhamentos ainda tenha o sufixo dns do domínio antigo que é xxxx.com. Quando você digita ou executa ping no D1, ele anexa esse sufixo DNS no final. Então, o que realmente está se conectando é d1.xxxx.com ... isso não existe mais quando você descarta seu domínio xxxx.com. Tente conectar-se a \ d1. yyyy.com \ root \ things e não apenas \ d1 \ root \ things. Deixe-me saber se isso funciona, então podemos continuar

    

Answer 2

Eu acredito nesta situação particular, algo como o Wireshark pode vir a calhar. Na verdade, ele mostra consultas DNS também.