Lange Pause beim Zugriff auf den DFS-Namespace

Wir haben kürzlich unser Windows-Netzwerk migriert, um DFS für freigegebene Dateien zu verwenden. DFS funktioniert gut, mit Ausnahme eines ärgerlichen Problems: Benutzer stellen eine erhebliche Verzögerung fest, wenn sie versuchen, auf einen DFS-Namespace zuzugreifen, auf den sie seit einiger Zeit nicht mehr zugegriffen haben. Ich habe versucht, das Problem zu beheben, aber bisher keinen Erfolg gehabt, und ich hatte gehofft, dass jemand hier einige Hinweise zur Behebung des Problems hat.

Zunächst einige Hintergrundinformationen zu unserem Netzwerk:

Das Netzwerk verwendet eine Active Directory-Domäne auf Windows 2008-Funktionsebene mit zwei Windows 2008-Domänencontrollern und zwei DNS-Servern (auf jedem Domänencontroller einen). Das Netzwerk ist nur DNS - keine WINS. Alle Computer befinden sich am selben Standort und sind über Gigabit-Ethernet verbunden. Wir haben ungefähr 20 domänenbasierte DFS-Namespaces im Windows 2008-Modus und jeder DFS-Namespace verfügt über zwei Windows 2008-DFS-Namespace-Server (die gleichen zwei Server für alle Namespaces). Alle Namespace-Server befinden sich im FQDN-Modus und alle Ordnerziele werden mit ihrem FQDN angegeben. Alle Computer sind mit Service Packs und Patches auf dem neuesten Stand.

Die eigentlichen Ordnerziele (dh die SMB-Freigaben, auf die unsere DFS-Ordner verweisen) sind auf mehrere Datei- und Anwendungsserver verteilt, auf denen Windows 2008 ausgeführt wird, abgesehen von zwei Anwendungsservern, auf denen Windows 2003 R2 ausgeführt wird, ohne dass eine Replikation eingerichtet wurde (z. B. derzeit alle DFS-Ordner) nur ein Ordnerziel haben).

Weitere Details zum Problem:

Die Zugriffsverzögerung für Namespaces beträgt in der Regel 1 bis 10 Sekunden und tritt anscheinend auf, wenn ein bestimmter Computer mindestens fünf Minuten lang nicht auf den angeforderten Namespace zugegriffen hat.

Wenn der Benutzer beispielsweise länger als fünf Minuten nicht auf \\ Domänenname \ Namespace1 \ zugegriffen hat und versucht, über Windows Explorer auf \\ Domänenname \ Namespace1 \ zuzugreifen, friert das Explorer-Fenster für 1 bis 10 Sekunden ein Fortsetzen und Anzeigen der Ordner in \\ domain.name \ namespace1. Wenn sie dann das Explorer-Fenster schließen und versuchen, innerhalb von fünf Minuten erneut auf \\ domain.name \ namespace1 \ zuzugreifen, wird der Inhalt fast sofort angezeigt. Wenn sie länger als fünf Minuten warten, wird die Pause von 1 bis 10 Sekunden erneut durchlaufen.

Sobald "innerhalb" des Namespace alles schön und bissig ist, ist es nur die anfängliche Verbindung zum Namespace, die langsam ist.

Die Verzögerungen beim Durchsuchen scheinen sich auf alle von uns verwendeten Windows-Varianten auszuwirken (Windows 2008 x64 SP2, Windows 2003 R2 x86 SP2, Windows XP Pro x86 SP3) - möglicherweise ist es in Windows XP / 2003 etwas schlechter als in Windows 2008, aber ich bin nicht sicher, ob der Unterschied nicht nur psychologischer Natur ist.

Beim direkten Zugriff auf die zugrunde liegenden Ordnerziele tritt überhaupt keine Verzögerung auf. Wenn also direkt auf die SMB-Freigaben zugegriffen wird, auf die von DFS verwiesen wird (unter Umgehung von DFS), liegt keine Pause vor.

Während der Fehlersuche habe ich festgestellt, dass die "Cache-Dauer" für alle unsere DFS-Roots auf 300 Sekunden - 5 Minuten festgelegt ist. Da dies die gleiche Zeit ist, die zum Auslösen der Pause erforderlich ist, gehe ich davon aus, dass dieses Caching in irgendeiner Weise zusammenhängt, obwohl ich nicht sicher bin, was genau auf dem Client zwischengespeichert ist und daher nach Ablauf von 5 Minuten erneut nachgeschlagen werden muss.

Bei dem Versuch, das Problem zu lösen, habe ich bereits Folgendes versucht / überprüft (ohne Erfolg):

• Führen Sie dcdiag auf beiden Domänencontrollern aus - es wurden keine Probleme gefunden
• Einige grundlegende DNS-Serverprüfungen ohne Probleme durchgeführt. Ich kann die DNS-Server nicht im Detail überprüfen, möchte jedoch hinzufügen, dass das Netzwerk kein anderes seltsames Verhalten aufweist, das möglicherweise auf ein DNS-Problem hinweist
• Deaktiviert Antivirus auf Clients und Servern
• Entfernen eines Namespaceservers aus mehreren Namespaces - kein Unterschied

Das ist es, was ich vorhabe - und ich habe keine Ideen mehr. Kann jemand vorschlagen, was die Verzögerungen verursachen kann und / oder was ich als nächstes versuchen sollte?

Nun, wir scheinen dieses Problem in unserer Umgebung endlich gelöst zu haben. Im Interesse anderer haben wir Folgendes entdeckt und festgestellt, wie wir das Problem behoben haben:

Um einen tieferen Einblick in die Ereignisse vor, während und nach den Verzögerungen zu erhalten, haben wir Wireshark auf einem Client-Computer verwendet, um den Netzwerkverkehr zu erfassen und zu analysieren, während dieser Client versuchte, auf eine DFS-Freigabe zuzugreifen.

Diese Erfassungen zeigten etwas Seltsames: Wann immer die Verzögerung zwischen dem Senden der DFS-Anforderung vom Client an einen Domänencontroller und dem Verweisen auf einen DFS-Stammserver, der vom Domänencontroller zum Client zurückkehrte, auftrat, sendete der Domänencontroller mehrere Broadcastnamen Nachschlagen im Netzwerk.

Erstens würde der Domänencontroller eine NetBIOS-Suche für DOMAIN senden (wobei DOMAIN unser Active Directory-Domänenname vor Windows 2000 ist). Ein paar Sekunden später würde ein LLMNR- Lookup für DOMAIN gesendet. Diesem würde ein weiterer Broadcast-NetBios-Lookup für DOMAIN folgen. Nachdem diese drei Suchvorgänge gesendet worden waren (und ich nehme an, dass das Zeitlimit überschritten wurde), antwortete der Domänencontroller dem Client schließlich mit einer (korrekten) Verweisung auf einen DFS-Stammserver.

Diese Sendungsnamensuchen für DOMAIN wurden nur gesendet, als die lange Verzögerung beim Öffnen einer DFS-Freigabe auftrat. Aus der Wireshark-Erfassung ging eindeutig hervor, dass der Domänencontroller keine Verweisung an einen DFS-Stammserver zurückgab, bis alle drei Suchvorgänge gesendet wurden ( und ~ 7 Sekunden vergangen). Diese Sendungsnamensuche waren also offensichtlich die Ursache für unsere Verzögerungen.

Nachdem wir das Problem erkannt hatten, versuchten wir herauszufinden, warum diese Sendernamensuche stattfand. Nach ein wenig mehr Googeln und einigem Ausprobieren haben wir unsere Antwort gefunden: Wir haben den Registrierungsschlüssel DfsDnsConfig auf unseren Domänencontrollern nicht auf 1 gesetzt, wie dies bei Verwendung von DFS in einer reinen DNS-Umgebung erforderlich ist.

Wenn wir ursprünglich Setup DFS in unserer Umgebung wir haben die verschiedenen Artikel zu lesen , wie für eine DNS-Umgebung DFS konfigurieren (zB Microsoft KB244380 und andere) und waren von diesem Registrierungsschlüssel bewusst, aber hatte die Anweisungen auf wann / wie zu misintepreted benutze es.

KB244380 sagt:

Der Registrierungsschlüssel DFSDnsConfig muss jedem Server hinzugefügt werden, der am DFS-Namespace teilnimmt, damit alle Computer vollqualifizierte Namen verstehen.

Wir dachten, dies bedeutet, dass der Registrierungsschlüssel nur auf den DFS- Namespace-Servern festgelegt werden muss , ohne zu bemerken, dass er auch auf den Domänencontrollern erforderlich ist. Nachdem wir DfsDnsConfig auf unseren Domänencontrollern auf 1 festgelegt haben (und den Dienst "DFS-Namespace" neu gestartet haben), ist das Problem verschwunden.

Natürlich sind wir mit diesem Ergebnis zufrieden, aber ich möchte hinzufügen, dass ich immer noch nicht zu 100% davon überzeugt bin, dass dies unser einziges Problem ist. Ich frage mich, ob das Hinzufügen von DfsDnsConfig = 1 zu unseren Domänencontrollern nur das Problem umgangen hat, anstatt es zu lösen . Ich kann nicht herausfinden, warum die Domänencontroller versuchen würden, DOMAIN (den Domänennamen selbst, anstatt einen Server in der Domäne) während des DFS-Verweisprozesses zu suchen, selbst in einer Umgebung, die nicht nur DNS ist, und ich weiß es auch Ich habe DfsDnsConfig = 1 auf Domänencontrollern in anderen (zugegebenermaßen viel kleineren / einfacheren) reinen DNS-Umgebungen nicht festgelegt und hatte nicht dasselbe Problem. Trotzdem haben wir unser Problem gelöst und freuen uns.

Ich hoffe, dies ist hilfreich für die anderen, die ein ähnliches Problem haben - und nochmals vielen Dank für die Vorschläge, die auf dem Weg dorthin gemacht wurden.

Dies kann durch die Bestellung der DNS-Servernetzmaske verursacht werden. Wir haben dies kürzlich in Server 2003 festgestellt. Dies hängt von Ihrem aktuellen Subnetz ab.

Beispiel.

Standort 1: IP-Subnetz 10.0.0.0/24 Standort 2: IP-Subnetz 10.0.1.0/24

Der Client an Standort 2 führt eine DNS-Abfrage für Ihren domänenbasierten Namespace durch und erhält standardmäßig den DFS-Server an Standort 1, da der DNS-Server die IP-Grenzen des Standorts nicht kennt. Sie müssen Ihren DNS-Servern mitteilen, mit welcher Subnetzmaske ermittelt werden soll, mit welcher IP-Adresse geantwortet werden soll.

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

Der Active Directory-Teamblog enthält einen dreiteiligen Artikel ALLES über DFS-Verzögerungen.

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

Es werden die Grundlagen des Verweisprozesses erläutert und anschließend die Verwendung verschiedener Tools, einschließlich dfsUtil und dfsDiag, um die tatsächliche Ursache für die Verzögerungen zu ermitteln.

Es hat mir geholfen, mein Problem zu finden. Es stellte sich heraus, dass im Freigabeverzeichnis für Domänenbenutzer keine Leseberechtigungen vorhanden waren.

HTH, Daniel

Es riecht nach einem DNS-Problem, aber alles ist möglich. Ich habe den alten FRS sehr bevorzugt, weil die Diagnosetools wie Ultraschall so nützlich waren: 7

Enthält das DFS-Replikationsereignisprotokoll Informationen zu den Zielen? (Der DFS-Integritätsbericht bezieht seine Warnungen aus dem Ereignisprotokoll.)

Ohne WINS zu laufen ist ein schönes Ziel und bewundernswert, obwohl ich ziemlich dagegen bin, wenn es Windows-Systeme vor Vista / 2008 gibt, da die Dinge meiner Erfahrung nach nicht immer wie erwartet oder so schnell ohne WINS funktionieren - obwohl es wirklich so ist sollte keine Rolle spielen.

Der Client speichert einen DFS-Verweis zwischen, dh wenn Sie \ domain.name \ namespace eingeben, wird zwischengespeichert, auf welchen tatsächlichen Server domain.name verwiesen wird. Sobald der Verweis aus dem Cache abgelaufen ist, muss der Client Ihre DFS-Topologie im Grunde noch einmal "entdecken", daher die Verzögerung.

Schauen Sie hier nach: http://technet.microsoft.com/en-us/library/cc758234(WS.10).aspx und hier http://blogs.technet.com/filecab/archive/2006/01/20 /417832.aspx für weitere Informationen zur Funktionsweise.

Mögliche Lösungen? Eine abgedroschene Methode könnte darin bestehen, ein kleines Programm zu schreiben, das alle paar Minuten ein "Keep Alive" ausführt. zB ein C-Programm, das die erste gefundene Datei öffnet und sie sofort schließt. Ich habe dies nicht ausprobiert oder getestet, und Sie müssten auf jeden Fall einige sorgfältige Überlegungen anstellen, wenn Sie dies tun würden.

Wir hatten ein ähnlich klingendes Problem, bei dem es zu Verzögerungen (bis zu einer Minute) zwischen dem Klicken auf ein Laufwerk, das einer DFS-Freigabe zugeordnet ist, und dem Anzeigen und Navigieren zu den Ordnern in der Freigabe kam.

Die Benutzer hatten auch Heimlaufwerke, die einer anderen DFS-Freigabe auf demselben Volume zugeordnet waren, und hatten keine Verzögerung beim Zugriff auf Ordner.

Der Unterschied zwischen den beiden ist Access-Based Enumeration (ABE) - die Problemfreigabe hat dies aktiviert (es ist ein allgemeines Laufwerk für Benutzer mit Tausenden von Ordnern - ABE bedeutet, dass Benutzer nur die Ordner sehen, für die sie Berechtigungen haben).

Durch Deaktivieren von ABE wurde das Problem vollständig behoben. Offensichtlich ist dies keine Lösung, da Benutzer dann alle Ordner sehen und sie verwirren. Ich habe die DFS-Freigabe als vorübergehende Maßnahme auf einen Server mit einer Ersatzfestplatte repliziert, und selbst bei aktiviertem ABE auf diesem neuen Ziel ist die Verzögerung vergangen.

Der Problemserver ist 2k3R2 und hat eine Betriebszeit von über 150 Tagen (!). Daher wird er neu gestartet und CHKDSK wird über das fehlerhafte Volume ausgeführt. Ich werde hier zurück posten, wenn dies einen Unterschied zum Problem macht. Das neue Ziel befindet sich auf einem 2k8-Server.

dfsutil / spcflush und dfsutil / pktflush können auch in einem Netzwerk mit mehreren Standorten eine Lösung sein. Stellen Sie sicher, dass die DFS-Verbindung des Heimstandorts vom lokalen Server und nicht aus dem Cache stammt.

Ich weiß, dass das ursprüngliche Poster kein WINS verwendet hat, aber ich poste für andere, da wir diesen Beitrag am häufigsten verwendet haben, um ein sehr ähnliches Problem zu lösen. Für uns war es schließlich jemand, der sich entschied, seine Arbeitsstation mit demselben Namen wie die Domäne zu benennen. Jedes Mal, wenn der Domänencontroller nach dem Domänennamen für die DFS-Überweisung suchte, wollte er auf diese Arbeitsstation aufgelöst werden und verursachte eine erhebliche Verzögerung von mehreren 10 Sekunden. In dem WINS, das auf ein DC verweist, wurde ein statischer Eintrag 20 platziert und das Problem hat das behoben. Wenn Sie keine WINS hatten, können Sie mit dem Platzieren des Domänennamens als Computername in der LMHOSTS-Datei, die auf einen Domänencontroller zeigt, experimentieren, um die 20-Suche zu erhalten, und die Priorität festlegen, damit LMHOSTS der erste Ort ist, an dem nach Lösungen für NetBIOS-Namen gesucht wird.

http://technet.microsoft.com/en-us/library/cc780950(v=ws.10).aspx Auf dieser Seite werden sowohl Domänencontroller als auch DFSN erwähnt, sofern dies hilfreich ist.

Registrierungseinträge für DFS-Domänencontroller und Stammserver

Die folgenden Registrierungseinträge befinden sich unter

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs 

auf Stammservern und Domänencontrollern. Alle Einträge sind REG_DWORD.

Also habe ich diesen Artikel bei meiner Suche verwendet. Ich habe alles eingerichtet und hatte immer noch Probleme. Nachdem ich einige Tage damit verbracht hatte, das Problem zu untersuchen und alles "Microsoft" auszuschließen, vermutete ich, dass es mit dem Netzwerk zusammenhängt. Es stellte sich heraus, dass unser WAN-Beschleuniger das Problem war. Ich hatte unsere Networking-Jungs Beschleunigung für unsere Domain-Controller ausschalten und alles wurde besser.

Hatte viele Controller, so tat ein Skript (dnsdfs.cmd servername ):

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

Sie erwähnen, dass Sie über 20 DFS-Server verfügen, können jedoch nicht angeben, ob sich alle Server in derselben Einrichtung befinden.

Wenn sich diese Server nicht in derselben Einrichtung befinden und jeder andere Standort über eine eigene Domäne verfügt, möchten Sie möglicherweise sicherstellen, dass das Clientfailback aktiviert ist.

Für diejenigen, die hier über eine Google-Suche landen und das gleiche Problem haben ...

Überprüfen Sie zunächst, ob alle Links in Ihrem Namespace verfügbar und in Ordnung sind. Das ist, was in meinem Fall passiert ist, es gab immer noch einen Link im Namespace zu einem Server, der nicht verfügbar war. Die lange Pause beim Öffnen von DNS lag also daran, dass nach diesem Server gesucht wurde und ein Fehler auftrat. Nachdem ich diesen Link in DFS deaktiviert hatte, verschwand die lange Pause.

Stellen Sie sicher, dass die Gruppe Authentifizierte Benutzer Zugriff hat, um den Inhalt des Stammverzeichnisses aufzulisten, dem Sie zugeordnet sind. Wenn das Laufwerk x: beispielsweise \ domain.local \ departents \ Marketing zugeordnet ist, benötigt der Benutzer eine Listenberechtigung für \ domain.local \ department. In 2008/2012 können Sie unter "Erweiterte Berechtigungen" angeben, dass nur dieser Ordner verwendet werden soll, damit der Inhalt von Unterordnern, die möglicherweise Berechtigungen erben, nicht aufgelistet werden darf.