Pause longue lors de l'accès à l'espace de noms DFS

Nous avons récemment migré notre réseau Windows pour utiliser DFS pour les fichiers partagés. DFS fonctionne bien, à l'exception d'un problème ennuyeux: les utilisateurs connaissent un retard important lorsqu'ils tentent d'accéder à un espace de noms DFS auquel ils n'ont pas accédé depuis un certain temps. J'ai essayé de résoudre le problème, mais je n'ai pas réussi jusqu'à présent, et j'espérais que quelqu'un ici pourrait avoir des conseils pour aider à résoudre le problème.

Tout d'abord, quelques informations sur notre réseau:

Le réseau utilise un domaine Active Directory de niveau fonctionnel Windows 2008 avec deux contrôleurs de domaine Windows 2008 et deux serveurs DNS (un sur chacun des contrôleurs de domaine). Le réseau est uniquement DNS - pas de WINS. Tous les ordinateurs sont situés sur le même site et connectés par Gigabit Ethernet. Nous avons environ 20 espaces de noms DFS basés sur le domaine en mode Windows 2008, et chaque espace de noms DFS possède deux serveurs d'espaces de noms Windows 2008 DFS (les deux mêmes serveurs pour tous les espaces de noms). Tous les serveurs d'espace de noms sont en mode FQDN et toutes les cibles de dossier sont spécifiées à l'aide de leur FQDN. Tous les ordinateurs sont à jour avec les Service Packs et les correctifs.

Les cibles réelles des dossiers (c.-à-d. Le SMB partage vers lequel nos dossiers DFS pointent) sont dispersées sur plusieurs serveurs de fichiers et d'applications, tous exécutant Windows 2008 sauf deux serveurs d'applications qui exécutent Windows 2003 R2, sans aucune configuration de réplication (par exemple, tous les dossiers DFS actuellement avoir qu'un seul dossier cible).

Quelques détails supplémentaires sur le problème:

Le délai d'accès à l'espace de noms est généralement de 1 à 10 secondes et semble se produire lorsqu'un ordinateur particulier n'a pas accédé à l'espace de noms demandé pendant environ cinq minutes ou plus.

Par exemple, si l'utilisateur n'a pas accédé à \\ domain.name \ namespace1 \ pendant plus de cinq minutes et tente d'accéder à \\ domain.name \ namespace1 \ via l'Explorateur Windows, la fenêtre de l'Explorateur se fige pendant 1 à 10 secondes avant de finalement reprendre et afficher les dossiers qui existent dans \\ domain.name \ namespace1. S'ils ferment alors la fenêtre de l'Explorateur et tentent d'accéder à nouveau à \\ domain.name \ namespace1 \ dans les cinq minutes, le contenu sera affiché presque instantanément - s'ils attendent plus de cinq minutes, la pause de 1 à 10 secondes recommencera.

Une fois "à l'intérieur" de l'espace de noms, tout est agréable et accrocheur, c'est juste la connexion initiale à l'espace de noms qui est lente.

Les retards de navigation semblent affecter toutes les variantes de Windows que nous utilisons (Windows 2008 x64 SP2, Windows 2003 R2 x86 SP2, Windows XP Pro x86 SP3) - c'est peut-être un peu pire dans Windows XP / 2003 que dans Windows 2008, mais je Je ne sais pas si la différence n'est pas seulement psychologique.

L'accès direct aux cibles de dossiers sous-jacentes ne présente aucun délai - c'est-à-dire que si les partages SMB pointés par DFS sont directement accessibles (en contournant DFS), il n'y a pas de pause.

Lors du dépannage, j'ai remarqué que la «durée du cache» pour toutes nos racines DFS est définie sur 300 secondes - 5 minutes. Étant donné qu'il s'agit du même temps nécessaire pour déclencher la pause, je suppose que cette mise en cache est en quelque sorte liée, bien que je ne sois pas exactement ce qui est mis en cache sur le client et donc ce qui doit être recherché à nouveau après que 5 minutes se soient écoulées.

En essayant de résoudre le problème, j'ai déjà essayé / vérifié les éléments suivants (sans succès):

• Exécutez dcdiag sur les deux contrôleurs de domaine - aucun problème trouvé
• Fait quelques vérifications de base du serveur DNS sans trouver de problèmes - je ne sais pas comment vérifier les serveurs DNS en détail, mais j'ajouterais que le réseau ne présente aucun autre comportement étrange qui pourrait indiquer un problème DNS
• Anti-virus désactivé sur les clients et les serveurs
• Suppression de l'un des serveurs d'espaces de noms de quelques espaces de noms - aucune différence

C'est donc là que j'en suis - et je suis à court d'idées. Quelqu'un peut-il suggérer la cause des retards et / ou ce que je devrais essayer ensuite?

Eh bien, nous semblons enfin avoir résolu ce problème dans notre environnement. Pour le bénéfice des autres, voici ce que nous avons découvert et comment nous avons résolu le problème:

Pour essayer de mieux comprendre ce qui se passait avant / pendant / après les retards, nous avons utilisé Wireshark sur une machine cliente pour capturer / analyser le trafic réseau pendant que ce client tentait d'accéder à un partage DFS.

Ces captures montraient quelque chose d'étrange: chaque fois que le retard se produisait, entre la demande DFS envoyée du client à un contrôleur de domaine et la référence à un serveur racine DFS revenant du contrôleur de domaine au client, le contrôleur de domaine envoyait plusieurs noms de diffusion recherches sur le réseau.

Premièrement, le contrôleur de domaine diffuserait une recherche NetBIOS pour DOMAIN (où DOMAIN est notre nom de domaine Active Directory antérieur à Windows 2000). Quelques secondes plus tard, il diffusait une recherche LLMNR pour DOMAIN. Cela serait suivi par une autre recherche NetBios de diffusion pour DOMAIN. Après la diffusion de ces trois recherches (et je suppose que le délai a expiré), le contrôleur de domaine répondrait finalement au client avec une référence (correcte) à un serveur racine DFS.

Ces recherches de nom de diffusion pour DOMAIN n'étaient envoyées que lorsque le long délai d'ouverture d'un partage DFS s'est produit, et nous avons pu clairement voir à partir de la capture Wireshark que le contrôleur de domaine ne renvoyait pas une référence à un serveur racine DFS jusqu'à ce que les trois recherches aient été envoyées ( et ~ 7 secondes se sont écoulées). Donc, ces recherches de nom de diffusion ont été à l'évidence la cause de nos retards.

Maintenant que nous savions quel était le problème, nous avons commencé à essayer de comprendre pourquoi ces recherches de nom de diffusion se produisaient. Après un peu plus de recherches sur Google et quelques essais et erreurs, nous avons trouvé notre réponse: nous n'avions pas défini la clé de registre DfsDnsConfig sur nos contrôleurs de domaine sur 1, comme cela est requis lors de l'utilisation de DFS dans un environnement DNS uniquement.

Lorsque nous DFS de configuration à l' origine dans notre environnement , nous avons lu les différents articles sur la façon de configurer DFS pour un environnement uniquement DNS (par exemple Microsoft KB244380 et d' autres) et étaient au courant de cette clé de Registre, mais avait misintepreted les instructions quand / comment utilise le.

KB244380 dit:

La clé de registre DFSDnsConfig doit être ajoutée à chaque serveur qui participera à l'espace de noms DFS pour que tous les ordinateurs comprennent les noms pleinement qualifiés.

Nous pensions que cela signifiait que la clé de registre devait être définie uniquement sur les serveurs d'espace de noms DFS , sans se rendre compte qu'elle était également requise sur les contrôleurs de domaine. Après avoir défini DfsDnsConfig à 1 sur nos contrôleurs de domaine (et redémarré le service "DFS Namespace"), le problème a disparu.

De toute évidence, nous sommes satisfaits de ce résultat, mais j'ajouterais que je ne suis toujours pas convaincu à 100% que c'est notre seul problème - je me demande si l'ajout de DfsDnsConfig = 1 à nos contrôleurs de domaine a uniquement contourné le problème, plutôt que de le résoudre . Je ne peux pas comprendre pourquoi les contrôleurs de domaine essaieraient de rechercher DOMAIN (le nom de domaine lui-même, plutôt qu'un serveur dans le domaine) pendant le processus de référence DFS, même dans un environnement non DNS uniquement, et je sais aussi que je n'ont pas défini DfsDnsConfig = 1 sur les contrôleurs de domaine dans d'autres environnements DNS (certes beaucoup plus petits / plus simples) et n'ont pas eu le même problème. Pourtant, nous avons résolu notre problème, nous sommes donc heureux.

J'espère que cela sera utile aux autres qui connaissent un problème similaire - et merci encore à ceux qui ont fait des suggestions en cours de route.

Cela peut être dû à la commande du masque de réseau du serveur DNS. Nous l'avons rencontré récemment dans Server 2003. Cela dépend de votre sous-réseau actuel.

Exemple.

Site 1: sous-réseau IP 10.0.0.0/24 Site 2: sous-réseau IP 10.0.1.0/24

Le client du site 2 effectue une requête DNS pour votre espace de noms basé sur le domaine et recevra par défaut le serveur DFS du site 1 car le serveur DNS n'a pas connaissance des limites IP du site. Vous devez indiquer à vos serveurs DNS quel masque de sous-réseau utiliser pour identifier les adresses IP auxquelles répondre.

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

Le blog de l'équipe Active Directory contient un article en trois parties sur les délais DFS.

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

Il couvre les bases du processus de référence, puis montre comment utiliser divers outils, notamment dfsUtil et dfsDiag pour découvrir la cause réelle des retards.

Cela m'a aidé à trouver mon problème. Ce qui s'est avéré être aucune autorisation de lecture sur le répertoire de partage pour les utilisateurs du domaine.

HTH, Daniel

Ça sent comme un problème DNS mais tout se passe. J'ai beaucoup préféré l'ancien FRS car les outils de diagnostic comme Ultrasound étaient si utiles: 7

Obtenez-vous quelque chose dans le journal des événements de réplication DFS sur les cibles? (le rapport d'intégrité DFS tirera ses avertissements du journal des événements)

Courir sans WINS est un bel objectif et admirable, bien que je sois à peu près contre s'il existe des systèmes Windows antérieurs à Vista / 2008 car les choses ne fonctionnent pas toujours comme prévu ou aussi rapidement sans WINS dans mon expérience - bien que ce soit vraiment ne devrait pas avoir d'importance.

Le client met en cache une référence DFS, c'est-à-dire que lorsque vous saisissez \ domain.name \ namespace, il mettra en cache le serveur auquel domain.name fait référence. Une fois la référence expirée du cache, le client doit fondamentalement "découvrir" à nouveau votre topologie DFS, d'où le retard.

Jetez un œil ici: http://technet.microsoft.com/en-us/library/cc758234(WS.10).aspx et ici http://blogs.technet.com/filecab/archive/2006/01/20 /417832.aspx pour plus d'informations sur la façon dont cela fonctionne.

Solutions possibles? Une façon bizarre de s'y prendre pourrait être d'écrire un petit programme qui fait un "maintien en vie" toutes les quelques minutes; Par exemple, un programme C qui ouvre le premier fichier qu'il trouve et le ferme immédiatement. Je n'ai pas essayé ou testé cela, et vous auriez certainement besoin de réfléchir attentivement si vous vouliez le faire.

Nous avons eu un problème similaire, où les utilisateurs subiraient des retards (jusqu'à une minute) entre cliquer sur un lecteur mappé sur un partage DFS et pouvoir voir et parcourir les dossiers dans le partage.

Les utilisateurs avaient également des disques personnels mappés sur un partage DFS différent sur le même volume et n'avaient aucun délai lors de l'accès aux dossiers.

La différence entre les deux est l'énumération basée sur l'accès (ABE) - le partage de problèmes a cette fonction activée (c'est un lecteur commun pour les utilisateurs, avec des milliers de dossiers - ABE signifie que les utilisateurs ne voient que les dossiers auxquels ils ont des autorisations).

La désactivation d'ABE a entièrement supprimé le problème. Évidemment, ce n'est pas une solution car les utilisateurs voient alors tous les dossiers, les confondant. J'ai répliqué le partage DFS sur un serveur avec un disque de rechange comme mesure temporaire, et même avec ABE activé sur cette nouvelle cible, le retard a disparu.

Le serveur à problème est 2k3R2 et a un temps de disponibilité de plus de 150 jours (!), Donc il va être redémarré et CHKDSK fonctionnera sur le volume incriminé. Je reviendrai ici si cela fait une différence dans le problème. La nouvelle cible est sur un serveur 2k8.

dfsutil / spcflush et dfsutil / pktflush peuvent également être une solution dans un réseau multisite. Assurez-vous que le lien DFS du site d'accueil provient du serveur local et non du cache.

Je sais que l'affiche originale n'utilisait pas WINS, mais je poste pour le bénéfice des autres car nous avons le plus utilisé ce message pour aider à résoudre un problème très similaire. Pour nous, cela a fini par être une personne qui a décidé de nommer son poste de travail avec le même nom que le domaine. Ainsi, chaque fois que le contrôleur de domaine effectuait une recherche sur le nom de domaine pour la référence DFS, il souhaitait se résoudre sur ce poste de travail et entraînerait un retard considérable de plusieurs dizaines de secondes. Une entrée statique 20 a été placée dans le WINS pointant vers un DC et cela a résolu le problème. Si vous n'aviez pas de WINS, vous pouvez essayer de placer le nom de domaine en tant que nom d'ordinateur dans le fichier LMHOSTS pointé vers un DC pour obtenir la recherche 20, et définir la priorité pour que LMHOSTS soit le premier endroit à rechercher pour résoudre les noms de netbios.

http://technet.microsoft.com/en-us/library/cc780950(v=ws.10).aspx Cette page mentionne en fait les contrôleurs de domaine et DFSN, si cela vous aide.

Contrôleur de domaine DFS et entrées de registre du serveur racine

Les entrées de registre suivantes se trouvent sous

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs 

sur les serveurs racine et les contrôleurs de domaine. Toutes les entrées sont REG_DWORD.

J'ai donc utilisé cet article dans ma recherche. J'ai tout installé et j'ai toujours eu des problèmes. Après avoir passé plusieurs jours à étudier le problème et à exclure tout «Microsoft», j'ai deviné que c'était lié au réseau. Il s'avère que notre accélérateur WAN était le problème. Nos gars en réseau ont désactivé l'accélération pour nos contrôleurs de domaine et tout s'est amélioré.

Avait beaucoup de contrôleurs, tout comme un script ( dnsdfs.cmd servername):

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

Vous mentionnez que vous avez 20 serveurs DFS mais que vous ne parlez pas si tous les serveurs se trouvent dans la même installation.

Si ces serveurs ne sont pas dans la même installation et que chaque autre site a son propre domaine, vous pouvez vous assurer que la restauration automatique du client est activée.

Pour ceux qui se retrouvent ici grâce à une recherche google et qui ont le même problème ...

Vérifiez d'abord que tous les liens de votre espace de noms sont disponibles et corrects. C'est ce qui s'est passé dans mon cas, il y avait toujours un lien dans l'espace de noms vers un serveur qui était en panne, donc la longue pause lors de l'ouverture du DNS était parce qu'il cherchait ce serveur et échouait. Une fois que j'ai désactivé ce lien dans DFS, la longue pause a disparu.

Vérifiez que le groupe Utilisateurs authentifiés a accès pour répertorier le contenu du répertoire racine auquel vous êtes mappé. Par exemple, si le lecteur x: est mappé sur \ domain.local \ departents \ Marketing, l'utilisateur aura besoin d'une autorisation de liste pour \ domain.local \ départements. En 2008/2012, vous pouvez spécifier sous des autorisations avancées qu'il s'applique à «Ce dossier uniquement» afin qu'ils ne soient pas autorisés à répertorier le contenu des sous-dossiers qui peuvent hériter des autorisations.