Pausa longa ao acessar o namespace do DFS

Recentemente, migramos nossa rede do Windows para usar o DFS para arquivos compartilhados. O DFS está funcionando bem, exceto por um problema irritante: os usuários experimentam um atraso significativo ao tentar acessar um namespace DFS que não acessam há algum tempo. Tentei solucionar o problema, mas até agora não obtive sucesso e esperava que alguém aqui tivesse alguns indicadores para ajudar a resolver o problema.

Em primeiro lugar, alguns antecedentes em nossa rede:

A rede usa um domínio do Active Directory em nível funcional do Windows 2008 com dois controladores de domínio do Windows 2008 e dois servidores DNS (um em cada um dos controladores de domínio). A rede é apenas DNS - sem WINS. Todos os computadores estão localizados no mesmo site e conectados por Gigabit Ethernet. Temos aproximadamente 20 espaços para nome DFS baseados em domínio no modo Windows 2008 e cada espaço para nome DFS possui dois servidores de espaço para nome Windows 2008 DFS (os mesmos dois servidores para todos os espaços para nome). Todos os servidores de namespace 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 pasta reais (ou seja, o SMB compartilha nossas pastas DFS apontadas) estão espalhados por vários servidores de arquivos e aplicativos, todos executando o Windows 2008 com exceção de dois servidores de aplicativos que executam o Windows 2003 R2, sem nenhuma configuração de replicação (por exemplo, todas as pastas DFS atualmente tem apenas um destino de pasta).

Mais alguns detalhes sobre o problema:

O atraso de acesso ao espaço para nome geralmente dura de 1 a 10 segundos e parece ocorrer quando um computador específico não acessa o espaço para nome solicitado por aproximadamente cinco minutos ou mais.

Por exemplo, se o usuário não acessar \\ domain.name \ namespace1 \ por mais de cinco minutos e tentar acessar \\ domain.name \ namespace1 \ via Windows Explorer, a janela do Explorer será congelada por 1 a 10 segundos antes de finalmente retomando e exibindo as pastas existentes 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 mais de cinco minutos, a pausa de 1 a 10 segundos será realizada novamente.

Depois de "dentro" do espaço para nome, tudo fica agradável e rápido, é apenas a conexão inicial ao espaço para nome que é lenta.

Os atrasos na 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 eu não tenho certeza se a diferença não é apenas psicológica.

O acesso direto aos destinos da pasta subjacente 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 solução de problemas, notei que a "Duração do cache" para todas as nossas raízes do DFS está definida para 300 segundos - 5 minutos. Dado que esse é o mesmo período de tempo necessário para acionar a pausa, presumo que esse cache esteja de alguma forma relacionado, embora não tenha certeza do que está armazenado em cache no cliente e, portanto, o que precisa ser consultado novamente após 5 minutos.

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

• Execute o dcdiag nos dois controladores de domínio - não foram encontrados problemas
• Realizei algumas verificações básicas de servidor DNS sem encontrar problemas - não sei como verificar os servidores DNS em detalhes, mas acrescentaria 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 namespace de alguns namespaces - não há diferença

Então é aí que estou fazendo - e estou sem idéias. Alguém pode sugerir o que pode estar causando os atrasos e / ou o que devo tentar em seguida?

Bem, finalmente parecemos ter resolvido esse problema em nosso ambiente. Para os benefícios de outras pessoas, veja o que descobrimos e como solucionamos 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 mostravam algo estranho: sempre que o atraso ocorria, entre a solicitação do DFS sendo enviada do cliente para um controlador de domínio e a referência a um servidor raiz do DFS voltando do controlador de domínio para o cliente, o controlador de domínio estava enviando vários nomes de broadcast pesquisas na rede.

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

Essas pesquisas de nome de transmissão para DOMAIN estavam sendo enviadas apenas quando ocorreu o longo atraso na abertura de um compartilhamento DFS, e pudemos ver claramente na captura do Wireshark que o controlador de domínio não retornava uma referência a um servidor raiz DFS até que as três pesquisas fossem enviadas ( e ~ 7 segundos se passaram). Portanto, essas pesquisas de nome de transmissão 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 nome de transmissão estavam ocorrendo. Após um pouco mais de pesquisa no Google e algumas tentativas e erros, encontramos nossa resposta: não tínhamos definido a chave de registro DfsDnsConfig em nossos controladores de domínio como 1, conforme é necessário ao usar o DFS em um ambiente somente DNS.

Quando originalmente DFS configuração em nosso meio que tinha ler os vários artigos sobre como configurar o DFS para um ambiente somente DNS (por exemplo, Microsoft KB244380 e outros) e estavam cientes desta chave de registo, mas tinha misintepreted as instruções sobre quando / como use-o.

KB244380 diz:

A chave do Registro DFSDnsConfig deve ser adicionada a cada servidor que participe do espaço para nome do DFS para que todos os computadores entendam nomes totalmente qualificados.

Achamos que isso significava que a chave do registro deveria ser definida apenas nos servidores de espaço para nome do DFS , sem perceber que também era necessária nos controladores de domínio. Depois de definirmos DfsDnsConfig como 1 em nossos controladores de domínio (e reiniciar o serviço "DFS Namespace"), o problema desapareceu.

Obviamente, estamos felizes com esse resultado, mas gostaria de acrescentar que ainda não estou 100% convencido de que esse é o nosso único problema - será que a adição de DfsDnsConfig = 1 aos nossos CDs apenas funcionou em torno do problema, em vez de resolvê-lo? . Não consigo entender por que os controladores de domínio tentariam pesquisar DOMAIN (o próprio nome de domínio, em vez de um servidor no domínio) durante o processo de referência do DFS, mesmo em um ambiente não somente DNS, e também sei que não definiu DfsDnsConfig = 1 em controladores de domínio em outros ambientes (reconhecidamente muito menores / mais simples) somente DNS e não tiveram 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.

Isso pode ser causado pelo pedido da máscara de rede do servidor DNS. 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 10.0.1.0/24

O cliente no site 2 faz uma consulta DNS para 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 com qual máscara de sub-rede usar para identificar com quais endereços IP responder.

Consulte http://support.microsoft.com/kb/842197

O Blog da equipe do Active Directory possui um artigo de três partes, tudo sobre atrasos no DFS.

http://blogs.technet.com/b/askds/archive/2009/09/29/o-dfs-shares-where-art-thou-part-1-3.aspx

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

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

HTH, Daniel

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

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

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

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

Dê uma olhada aqui: http://technet.microsoft.com/en-us/library/cc758234(WS.10).aspx e aqui http://blogs.technet.com/filecab/archive/2006/01/20 /417832.aspx para obter mais informações sobre como isso funciona.

Soluções possíveis? Uma maneira hacky de fazer isso pode ser escrever um pequeno programa que "mantenha vivo" a cada poucos minutos; por exemplo, um programa em C que abre o primeiro arquivo encontrado e o fecha imediatamente. Eu não tentei ou testei isso, e você definitivamente precisaria considerar cuidadosamente se o faria.

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 pelas pastas dentro do compartilhamento.

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

A diferença entre os dois é a ABE (enumeração baseada em acesso) - o compartilhamento de problemas está ativado (é uma unidade comum para usuários, com milhares de pastas) - ABE significa que os usuários veem apenas as pastas às quais têm permissão).

Desativar o ABE removeu o problema completamente. Obviamente, essa não é uma solução, pois os usuários veem todas as pastas, confundindo-as. Eu repliquei o compartilhamento DFS em um servidor com algum disco sobressalente como medida temporária e, mesmo com o ABE ativado nesse novo destino, o atraso se foi.

O servidor com problema é 2k3R2 e tem um tempo de atividade de mais de 150 dias (!), Portanto, ele será reinicializado e o CHKDSK será executado no volume incorreto. Vou postar aqui se isso fizer alguma diferença para o problema. O novo destino está em um servidor 2k8.

O dfsutil / spcflush e o dfsutil / pktflush também podem ser uma solução em uma rede de vários sites. Verifique se o link DFS do site inicial está vindo do servidor local e não do cache.

Sei que o pôster original não estava usando o WINS, mas estou postando para o benefício de outras pessoas, pois usamos este 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 que o domínio. Portanto, toda vez que o controlador de domínio fazia uma pesquisa no nome de domínio para referência do DFS, queria resolver a estação de trabalho e causava um atraso considerável de vários 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 tivesse WINS, 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 a consulta 20 e definir a prioridade para que LMHOSTS seja o primeiro local a procurar nomes de netbios para resolver.

http://technet.microsoft.com/en-us/library/cc780950(v=ws.10).aspx Na verdade, esta página menciona os controladores de domínio e o DFSN, se isso ajudar.

Controlador de domínio DFS e entradas de registro 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.

Então, eu usei este artigo na minha pesquisa. Eu configurei tudo e ainda tinha problemas. Depois de passar vários dias analisando o problema e excluindo tudo o que era 'Microsoft', imaginei que estivesse relacionado à rede. Acontece que o nosso acelerador de WAN foi o problema. Eu pedi aos nossos funcionários de rede que desligassem a aceleração para nossos controladores de domínio e tudo ficou melhor.

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

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

Você mencionou que possui 20 servidores DFS e ainda não mencionou se todos os servidores estão no mesmo recurso.

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

Para aqueles que acabam aqui através de uma pesquisa no google e que têm o mesmo problema ...

Primeiro verifique se todos os links no seu Namespace estão disponíveis e estão corretos. Foi o que aconteceu no meu caso, ainda havia um link no namespace para um servidor que estava inativo; portanto, a longa pausa ao abrir o DNS ocorreu porque ele estava procurando por esse servidor e falhou. Depois que desabilitei o link no DFS, a longa pausa foi embora.

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: for mapeada para \ domain.local \ departents \ Marketing, o usuário precisará de permissão de lista para \ domain.local \ departamentos. Em 2008/2012, você pode especificar sob permissões avançadas que ele se aplica a "Somente esta pasta" para que eles não tenham permissão para listar o conteúdo de nenhuma subpasta que possa estar herdando permissões.