Pausa longa ao acessar o namespace DFS

Question

Recentemente, migramos nossa rede do Windows para usar o DFS em arquivos compartilhados. O DFS está funcionando bem, exceto por um problema irritante: os usuários experimentam um atraso significativo quando tentam acessar um namespace DFS que não acessam há algum tempo. Eu tentei solucionar o problema, mas não tive sucesso até agora, e esperava que alguém aqui tivesse algumas dicas para ajudar a resolver o problema.

Em primeiro lugar, alguns antecedentes da nossa rede:

A rede usa um domínio do Active Directory de nível funcional do Windows 2008 com dois DCs do Windows 2008 e dois servidores DNS (um em cada um dos DCs). A rede é apenas DNS - sem WINS. Todos os computadores estão localizados no mesmo site e conectados por Gigabit Ethernet. Temos aproximadamente 20 namespaces DFS baseados em domínio no modo Windows 2008 e cada namespace DFS tem dois servidores de namespace DFS do Windows 2008 (os mesmos dois servidores para todos os namespaces). Todos os servidores de espaço para nome estão no modo FQDN e todos os destinos de pasta são especificados usando seu FQDN. Todos os computadores estão atualizados com Service Packs e patches.

Os destinos de pastas reais (ou seja, os compartilhamentos SMB apontados pelas pastas DFS) estão espalhados em vários servidores de arquivos e aplicativos, todos executando o Windows 2008 bar dois servidores de aplicativos que executam o Windows 2003 R2, sem nenhuma configuração de replicação (por exemplo, Atualmente, as pastas DFS só têm um destino de pasta).

Mais alguns detalhes sobre o problema:

O atraso de acesso ao namespace geralmente dura de 1 a 10 segundos e parece ocorrer quando um determinado computador não acessa o namespace solicitado por aproximadamente cinco minutos ou mais.

Por exemplo, se o usuário não tiver acessado \\ domain.name \ namespace1 \ por mais de cinco minutos e tentar acessar \\ domain.name \ namespace1 \ por meio do Windows Explorer, a janela do Explorer congelará por 1 a 10 segundos antes de finalmente retomar e exibir as pastas que existem em \\ domain.name \ namespace1. Se eles fecharem a janela do Explorer e tentarem acessar \\ domain.name \ namespace1 \ novamente dentro de cinco minutos, o conteúdo será exibido quase instantaneamente - se eles esperarem por mais de cinco minutos, ele passará pela pausa de 1 a 10 segundos novamente.

Uma vez que "dentro" do namespace, tudo é agradável e rápido, é apenas a conexão inicial com o namespace que é lenta.

Os atrasos de navegação parecem afetar todas as variantes do Windows que usamos (Windows 2008 x64 SP2, Windows 2003 R2 x86 SP2, Windows XP Pro x86 SP3) - possivelmente é um pouco pior no Windows XP / 2003 do que no Windows 2008 , mas não tenho certeza se a diferença não é apenas psicológica.

Acessar os destinos de pasta subjacentes diretamente não exibe nenhum atraso - ou seja, se os compartilhamentos SMB apontados pelo DFS forem acessados diretamente (ignorando o DFS), não haverá pausa.

Durante a pesquisa de problemas, notei que a "Duração do cache" para todas as nossas raízes DFS está definida para 300 segundos - 5 minutos. Como essa é a mesma quantidade de tempo necessária para acionar a pausa, presumo que esse cache esteja de alguma forma relacionado, embora não tenha certeza do que é armazenado em cache no cliente e, portanto, que precisa ser pesquisado novamente após 5 minutos. / p>

Ao tentar resolver o problema, eu já tentei / verifiquei o seguinte (sem sucesso):

• Execute o dcdiag em ambos os controladores de domínio - sem problemas encontrados
• Realizou algumas verificações básicas do servidor DNS sem encontrar nenhum problema - não sei como verificar os servidores DNS detalhadamente, mas gostaria de acrescentar que a rede não está exibindo nenhum outro comportamento estranho que possa apontar para um problema de DNS
• Antivírus desativado em clientes e servidores
• Removendo um dos servidores de espaço para nome de alguns namespaces - sem diferença

Então é aí que estou fazendo - e estou sem ideias. Alguém pode sugerir o que pode estar causando os atrasos e / ou o que eu deveria estar tentando em seguida?

    

Answer 1

Bem, finalmente parece ter resolvido este problema no nosso ambiente. Para os benefícios de outras pessoas, aqui está o que descobrimos e como resolvemos o problema:

Para tentar obter mais informações sobre o que estava ocorrendo antes / durante / após os atrasos, usamos o Wireshark em uma máquina cliente para capturar / analisar o tráfego de rede enquanto esse cliente tentava acessar um compartilhamento DFS.

Essas capturas mostraram algo estranho: sempre que ocorria o atraso, entre a solicitação DFS sendo enviada do cliente para um controlador de domínio e a referência a um servidor raiz DFS voltando do DC para o cliente, o DC estava enviando várias pesquisas de nomes de transmissão para a rede.

Em primeiro lugar, o DC iria transmitir uma pesquisa de NetBIOS para DOMAIN (onde DOMAIN é o nome de domínio do Active Directory anterior ao Windows 2000). Alguns segundos depois, ele transmitia uma pesquisa de LLMNR para DOMAIN. Isso seria seguido por outra pesquisa do NetBios para DOMAIN. Depois que essas três pesquisas foram transmitidas (e eu suponho que o tempo limite expirou), o controlador de domínio finalmente responderia ao cliente com uma referência (correta) a um servidor raiz DFS.

Essas pesquisas de nome de difusão para DOMAIN só estavam sendo enviadas quando ocorria o longo atraso ao abrir um compartilhamento DFS e podíamos ver claramente da captura do Wireshark que o DC não estava retornando uma referência a um servidor raiz DFS até que todas as três pesquisas foi enviado (e ~ 7 segundos passados). Então, essas pesquisas de nomes de broadcast foram obviamente a causa de nossos atrasos.

Agora que sabíamos qual era o problema, começamos a tentar descobrir por que essas pesquisas de nomes de transmissão estavam ocorrendo. Depois de pesquisar um pouco mais e fazer algumas tentativas e erros, encontramos nossa resposta: não definimos a chave do Registro DfsDnsConfig em nossos controladores de domínio como 1, como é exigido ao usar o DFS em um ambiente somente DNS.

Quando originalmente configuramos o DFS em nosso ambiente, fizemos ler os vários artigos sobre como configurar o DFS para um ambiente somente DNS (por exemplo, Microsoft KB244380 e outros) e estavam cientes dessa chave de registro, mas tinham interpretado incorretamente as instruções sobre quando / como usá-la.

KB244380 diz:

The DFSDnsConfig registry key must be added to each server that will participate in the DFS namespace for all computers to understand fully qualified names.

Achamos que isso significava que a chave de registro só precisa ser definida nos servidores de namespace do DFS , sem perceber que ela também era necessária nos controladores de domínio. Depois de definir o DfsDnsConfig como 1 em nossos controladores de domínio (e reiniciar o serviço "DFS Namespace"), o problema desapareceu.

Obviamente, estamos felizes com este resultado, mas eu acrescentaria que ainda não estou 100% convencido de que este é o nosso único problema - gostaria de saber se adicionar DfsDnsConfig = 1 aos nossos DCs apenas resolveu o problema. do que resolvê-lo. Não consigo descobrir por que os controladores de domínio tentariam pesquisar DOMAIN (o nome de domínio em si, em vez de um servidor no domínio) durante o processo de referência do DFS, mesmo em um ambiente que não seja DNS, e também sei que Não defini o DfsDnsConfig = 1 em controladores de domínio em outros ambientes (reconhecidamente muito menores / mais simples) somente de DNS e não tive o mesmo problema. Ainda assim, resolvemos nosso problema e ficamos felizes.

Espero que isso seja útil para os outros que estão enfrentando um problema semelhante - e obrigado novamente àqueles que ofereceram sugestões ao longo do caminho.

    

Answer 2

Isso pode ser causado pela ordem da máscara de rede do servidor DNS. Nós nos deparamos com isso recentemente no Server 2003. Isso depende da sua sub-rede atual.

Exemplo.

Site 1: sub-rede IP 10.0.0.0/24 Site 2: sub-rede IP 10.0.1.0/24

O cliente no site 2 faz uma consulta DNS ao seu namespace baseado em domínio e receberá o servidor DFS no site 1 por padrão, pois o servidor DNS não está ciente dos limites de IP do site. Você precisa informar aos servidores DNS qual máscara de sub-rede usar para identificar com quais endereços IP responder.

Consulte o link

    

Answer 3

O Blog da equipe do Active Directory tem um artigo de três partes sobre os atrasos do DFS.

link

Ele aborda o básico sobre o processo de referência e mostra como usar várias ferramentas, incluindo o dfsUtil e o dfsDiag, para descobrir a causa real dos atrasos.

Isso me ajudou a encontrar meu problema. O que acabou por ser não permissões de leitura no diretório de compartilhamento para usuários do domínio.

HTH, Daniel

    

Answer 4

Cheira como um problema de DNS, mas vale tudo. Eu preferia muito o antigo FRS porque as ferramentas de diagnóstico como o Ultrasound eram tão úteis: 7

Você recebe alguma coisa no log de eventos de replicação DFS nos destinos? (o relatório de integridade do DFS extrairá seus avisos do log de eventos)

Correr sem o WINS é uma meta bacana e admirável, embora eu seja bem contra isso se houver algum sistema Windows anterior ao Vista / 2008, pois as coisas nem sempre estão funcionando como esperado ou tão rápido sem o WINS na minha experiência. embora realmente não deva importar.

    

Answer 5

O cliente armazena em cache uma referência DFS, ou seja, quando você insere \ domain.name \ namespace, ele armazenará em cache o servidor real cujo domínio se refere. Depois que a referência expira do cache, o cliente basicamente tem que "descobrir" sua topologia DFS novamente, daí o atraso.

Dê uma olhada aqui: link e aqui link para mais informações sobre como isso funciona.

Possíveis soluções? Uma maneira hacky de fazer isso pode ser escrever um pequeno programa que "mantenha-se vivo" a cada poucos minutos; por exemplo. um programa em C que fopen o primeiro arquivo encontrado e imediatamente o identifica. Eu não tentei ou testei isso, e você definitivamente precisaria dar uma cuidadosa consideração se você fosse fazer isso.

    

Answer 6

Tivemos um problema semelhante, em que os usuários experimentavam atrasos (até um minuto) entre clicar em uma unidade mapeada para um compartilhamento DFS e poder ver e navegar até as pastas dentro do compartilhamento.

Os usuários também tinham unidades iniciais mapeadas para um compartilhamento DFS diferente no mesmo volume e não tiveram nenhum atraso ao acessar pastas lá.

A diferença entre os dois é Enumeração Baseada em Acesso (ABE) - o compartilhamento de problema está ativado (é uma unidade comum para usuários, com milhares de pastas - ABE significa que os usuários só verão as pastas às quais têm permissões).

A desativação da ABE removeu completamente o problema. Obviamente, isso não é uma solução, pois os usuários veem todas as pastas, confundindo-as. Eu repliquei o compartilhamento DFS para um servidor com algum disco reserva como uma medida temporária e, mesmo com o ABE habilitado neste novo destino, o atraso passou.

O servidor do problema é 2k3R2 e tem um tempo de atividade de mais de 150 dias (!), portanto, ele será reinicializado e o CHKDSK será executado sobre o volume ofensivo. Vou postar de volta aqui se isso fizer alguma diferença para o problema. O novo alvo está em um servidor 2k8.

    

Answer 7

dfsutil / spcflush e dfsutil / pktflush podem ser uma solução também em uma rede multi-site, certifique-se de que o link DFS do site inicial esteja vindo do servidor local e não do cache.

    

Answer 8

Eu sei que o pôster original não estava usando o WINS, mas estou postando para o benefício de outras pessoas, já que usamos esse post para ajudar a resolver um problema muito semelhante. Para nós, acabou sendo alguém que decidiu nomear sua estação de trabalho com o mesmo nome do domínio. Assim, toda vez que o DC fez uma pesquisa no nome de domínio para a referência do DFS, estava querendo resolver para essa estação de trabalho e causaria um considerável atraso de vários 10 segundos. Uma entrada estática 20 foi colocada no WINS apontando para um controlador de domínio e isso resolveu o problema. Se você não tinha WINS, você poderia experimentar colocar o nome de domínio como um nome de máquina no arquivo LMHOSTS apontado para um controlador de domínio para obter 20 lookup e definir prioridade para ter LMHOSTS ser o primeiro lugar para resolver nomes de netbios de resolução.

    

Answer 9

link Esta página menciona realmente os controladores de domínio e o DFSN , se isso ajuda.

Entradas de registro do controlador de domínio DFS e do servidor raiz

As seguintes entradas do registro estão localizadas em

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs 

em servidores raiz e controladores de domínio. Todas as entradas são REG_DWORD.

    

Answer 10

Então eu usei este artigo na minha pesquisa. Eu configurei tudo e ainda tive problemas. Depois de passar vários dias olhando para o problema e excluindo tudo 'Microsoft' eu acho que era relacionado à rede. Acontece que o nosso Acelerador WAN foi o problema. Eu fiz nossos caras do Networking desligarem a aceleração para nossos controladores de domínio e tudo ficou melhor.

    

Answer 11

Você menciona que 20 servidores DFS ainda não mencionaram se todos os servidores estão no mesmo local.

Se esses servidores não estiverem no mesmo local e cada outro site tiver seu próprio domínio, convém garantir que o failback do cliente esteja ativado.

    

Answer 12

Para aqueles que acabam aqui por meio de uma pesquisa no google e que têm o mesmo problema ...

Primeiro, verifique se todos os links em seu namespace estão disponíveis e são bons. Foi o que aconteceu no meu caso, ainda havia um link no namespace para um servidor que estava inativo, então a longa pausa ao abrir o DNS foi porque ele estava procurando por esse servidor e falhando. Depois que eu desativei esse link no DFS, a longa pausa desapareceu.

    

Answer 13

Tinha muitos controladores, assim como um script ( dnsdfs.cmd servername ):

dfsutil server registry dfsdnsconfig set %1
sc \%1 stop dfs
sc \%1 start dfs

    

Answer 14

Verifique se o grupo Usuários Autenticados tem acesso para listar o conteúdo do diretório raiz para o qual você está mapeado. Por exemplo, se a unidade x: estiver mapeada para \ domain.local \ departents \ Marketing, o usuário precisará de permissão de lista para \ domain.local \ departments. Em 2008/2012, você pode especificar sob as permissões avançadas que se aplica a "Somente esta pasta", para que elas não tenham permissão para listar o conteúdo de quaisquer subpastas que possam estar herdando permissões.