Frage Lange Pause beim Zugriff auf den DFS-Namespace


Wir haben kürzlich unser Windows-Netzwerk auf DFS für freigegebene Dateien umgestellt. DFS funktioniert gut, abgesehen von einem lästigen Problem: Benutzer erfahren eine erhebliche Verzögerung, wenn sie versuchen, auf einen DFS-Namespace zuzugreifen, auf den sie seit einiger Zeit nicht zugegriffen haben. Ich habe versucht, das Problem zu beheben, hatte aber bis jetzt keinen Erfolg, und ich hatte gehofft, dass jemand hier einige Hinweise haben könnte, um das Problem zu lösen.

Zunächst einige Hintergrundinformationen zu unserem Netzwerk:

Das Netzwerk verwendet eine Active Directory-Domäne mit Windows 2008-Funktionsebene mit zwei Windows 2008-Domänencontrollern und zwei DNS-Servern (jeweils einer auf jedem der Domänencontroller). Das Netzwerk ist nur DNS - kein WINS. Alle Computer befinden sich am selben Standort und sind über Gigabit-Ethernet miteinander verbunden. Wir haben etwa 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 Namespaceserver befinden sich im FQDN-Modus und alle Ordnerziele werden über ihren FQDN angegeben. Alle Computer sind mit Service Packs und Patches auf dem neuesten Stand.

Die eigentlichen Ordnerziele (dh die SMB-Dateien, auf die unsere DFS-Ordner verweisen) sind auf mehrere Datei- und Anwendungsserver verteilt, auf denen Windows 2008 zwei Anwendungsserver ausführt, auf denen Windows 2003 R2 ausgeführt wird (z. B. alle DFS-Ordner) habe nur ein Ordnerziel).

Etwas mehr Details zu dem Problem:

Die Namespacezugriffsverzögerung ist im Allgemeinen 1 bis 10 Sekunden lang und scheint aufzutreten, wenn ein bestimmter Computer für mindestens fünf Minuten oder länger nicht auf den angeforderten Namespace zugegriffen hat.

Wenn der Benutzer beispielsweise nicht mehr als fünf Minuten auf \\ domain.name \ namespace1 \ zugegriffen hat und versucht, über Windows Explorer auf \\ domänename \ namespace1 \ zuzugreifen, wird das Explorer-Fenster für 1 - 10 Sekunden eingefroren Fortsetzen und Anzeigen der Ordner, die in \\ domain.name \ namespace1 vorhanden sind. Schließen sie dann das Explorer-Fenster und versuchen innerhalb von fünf Minuten wieder auf \\ domain.name \ namespace1 \ zuzugreifen, wird der Inhalt fast sofort angezeigt - wenn sie länger als fünf Minuten warten, wird sie erneut die Pause von 1 - 10 Sekunden durchlaufen.

Sobald der Namespace "innerhalb" des Namensraums ist, ist alles schön und bissig, es ist nur die erste Verbindung zum Namespace, die langsam ist.

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

Der Zugriff auf die zugrundeliegenden Ordnerziele weist keinerlei Verzögerung auf - d. H. Wenn auf die SMB-Freigaben, auf die DFS verweist, direkt zugegriffen wird (unter Umgehung von DFS), gibt es keine Pause.

Bei der Fehlersuche ist mir aufgefallen, dass die "Cache-Dauer" für alle unsere DFS-Wurzeln auf 300 Sekunden - 5 Minuten eingestellt ist. Da dies die gleiche Zeit ist, die benötigt wird, um die Pause auszulösen, gehe ich davon aus, dass dieses Caching irgendwie zusammenhängt, obwohl ich nicht genau weiß, was auf dem Client zwischengespeichert wird und was nach 5 Minuten wieder gesucht werden muss.

Bei dem Versuch, das Problem zu lösen, habe ich folgendes bereits getestet (ohne Erfolg):

  • Führen Sie dcdiag auf beiden Domänencontrollern aus - keine Probleme gefunden
  • Habe einige grundlegende DNS-Server-Prüfungen durchgeführt, ohne irgendwelche Probleme zu finden - Ich weiß nicht, wie man die DNS-Server im Detail überprüft, aber ich würde hinzufügen, dass das Netzwerk kein anderes merkwürdiges Verhalten zeigt, das auf ein DNS-Problem hinweisen könnte
  • Disabled Antivirus auf Clients und Servern
  • Entfernen eines der Namespace-Server aus ein paar Namespaces - kein Unterschied

Das ist der Punkt, an dem ich vorhabe - und ich habe keine Ideen mehr. Kann jemand vorschlagen, was die Verzögerungen verursachen könnte und / oder was ich als nächstes versuchen sollte?


20
2017-08-06 06:42


Ursprung


Holen Sie sich Wireshark auf einem Client und schnüffeln Sie den Verkehr während der "Verzögerung". Mein Bauch sagt, dass er dir etwas sagen wird. Ansonsten starrt es nur in eine Blackbox. - Evan Anderson
Danke für den Vorschlag - Ich werde es morgen ausprobieren (ich bin in Australien - 23 Uhr) und sehe, ob es etwas offensichtlich zeigt. - Matt
Irgendein Update auf diesem Matt? - JJ01
Ich habe diese Frage völlig vergessen: -S Leider haben wir keine Fortschritte gemacht, haben nur damit gelebt. Wenn ich eine Chance bekomme, werde ich versuchen, einen WINS-Server in unserer Umgebung zu installieren, um zu sehen, ob das hilft, das Problem zu beheben. Wenn das nicht gelingt, muss ich mehr über Wireshark erfahren (und wie man seine Ausgabe analysiert), um die Ursache des Problems weiter zu verfolgen. - Matt


Antworten:


Also, wir endlich scheinen dieses Problem in unserer Umgebung gelöst zu haben. Für die Vorteile von anderen, hier ist, was wir entdeckt haben und wie wir das Problem behoben haben:

Um zu erfahren, was vor / während / nach den Verzögerungen passiert ist, haben wir Wireshark auf einem Client-Rechner verwendet, um den Netzwerkverkehr zu erfassen / analysieren, während der Client versuchte, auf eine DFS-Freigabe zuzugreifen.

Diese Captures zeigten etwas Seltsames: Wann immer die Verzögerung auftrat, während die DFS-Anforderung vom Client an einen Domänencontroller gesendet wurde und der Verweis auf einen DFS-Stammserver vom DC zum Client zurückkehrte, sendete der DC mehrere Broadcast-Namen Nachschlagevorgänge für das Netzwerk.

Erstens würde der Domänencontroller eine NetBIOS-Suche nach DOMAIN senden (wobei DOMAIN unser Active Directory-Domänenname vor Windows 2000 ist). Ein paar Sekunden später würde es eine Sendung senden LLMNR Suche nach DOMAIN. Dies würde gefolgt von einer weiteren Broadcast-NetBios-Suche nach DOMAIN. Nachdem diese drei Nachsichten gesendet worden waren (und ich vermute, dass die Zeit abgelaufen ist), würde der Domänencontroller dem Client mit einem (korrekten) Verweis auf einen DFS-Stammserver antworten.

Diese Broadcast-Namenssuchen für DOMAIN wurden nur gesendet, wenn die lange Verzögerung beim Öffnen einer DFS-Freigabe aufgetreten ist. Aus der Wireshark-Erfassung konnten wir klar erkennen, dass der Domänencontroller keine Empfehlung an einen DFS-Stammserver gesendet hat, bis alle drei Suchvorgänge gesendet wurden. und ~ 7 Sekunden verstrichen). Also, diese Broadcast-Namen-Lookups waren ziemlich offensichtlich die Ursache für unsere Verzögerungen.

Jetzt, wo wir wussten, was das Problem war, begannen wir herauszufinden, warum diese Broadcast-Namen-Lookups stattfanden. Nach ein bisschen mehr Googeln und etwas Trial-and-Error fanden wir unsere Antwort: Wir hatten den Registrierungsschlüssel DfsDnsConfig auf unseren Domänencontrollern nicht auf 1 gesetzt, wie es bei der Verwendung von DFS in einer Nur-DNS-Umgebung erforderlich ist.

Als wir DFS ursprünglich in unserer Umgebung eingerichtet haben, haben wir hat getan Lesen Sie die verschiedenen Artikel zum Konfigurieren von DFS für eine Nur-DNS-Umgebung (z. Microsoft KB244380 und andere) und waren sich dieses Registrierungsschlüssels bewusst, aber sie hatten die Anweisungen falsch gedeutet, wann / wie man sie benutzt.

KB244380 sagt:

Der Registrierungsschlüssel DFSDnsConfig muss sein   hinzugefügt zu jedem Server, der wird   Teilnahme am DFS-Namespace für   alle Computer vollständig zu verstehen   qualifizierte Namen.

Wir dachten, dass dies bedeutet, dass der Registrierungsschlüssel auf dem DFS gesetzt werden muss Namespaceserver nur, nicht zu erkennen, dass es auch auf den Domänencontrollern erforderlich war. Nachdem wir DfsDnsConfig auf unseren Domänencontrollern auf 1 gesetzt und den Dienst "DFS-Namespace" neu gestartet haben, verschwand das Problem.

Offensichtlich sind wir mit diesem Ergebnis zufrieden, aber ich bin noch immer nicht 100% überzeugt, dass dies unser einziges Problem ist - ich frage mich, ob das Hinzufügen von DfsDnsConfig = 1 zu unseren Domänencontrollern nur das Problem gelöst hat, anstatt es zu lösen . Ich kann nicht herausfinden, warum die Domänencontroller versuchen würden, DOMAIN (der Domänenname selbst und nicht ein Server in der Domäne) während des DFS-Verweisprozesses zu suchen, selbst in einer Nicht-DNS-Umgebung, und ich weiß auch, dass ich habe DfsDnsConfig = 1 auf Domänencontrollern in anderen (zugegebenermaßen viel kleineren / einfacheren) DNS-Only-Umgebungen nicht gesetzt und hatte nicht das gleiche Problem. Trotzdem haben wir unser Problem gelöst und sind glücklich.

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


26
2017-12-29 05:23





Dies kann durch die DNS-Server-Netzmaske-Bestellung verursacht werden. Das ist kürzlich in Server 2003 aufgetreten. Das 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 in Site 2 erstellt eine DNS-Abfrage für Ihren domänenbasierten Namespace und erhält standardmäßig den DFS-Server an Standort 1, da der DNS-Server die IP-Grenzen der Site nicht kennt. Sie müssen Ihren DNS-Servern mitteilen, welche Subnetzmaske verwendet werden muss, um zu ermitteln, auf welche IP-Adressen sie antworten sollen.

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


3
2017-08-13 11:20



Danke, aber wir haben es hier nur mit einer Seite zu tun - alle Workstations und Server sind sogar im selben Subnetz. - Matt


Der Active Directory-Team-Blog enthält einen dreiteiligen Artikel ALL ü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 behandelt die Grundlagen des Empfehlungsprozesses und zeigt dann, wie verschiedene Tools wie dfsUtil und dfsDiag verwendet werden, um die tatsächliche Ursache der Verzögerungen zu ermitteln.

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

HTH, Daniel


3
2017-12-07 20:49





Riecht wie ein DNS-Problem, aber alles geht. Ich habe den alten FRS viel bevorzugt, weil die Diagnosewerkzeuge wie Ultraschall so nützlich waren: 7

Erhalten Sie im Ereignisprotokoll der DFS-Replikation Informationen zu den Zielen? (Der DFS-Health-Bericht zeichnet seine Warnungen aus dem Ereignisprotokoll.)

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


2
2018-01-07 15:52



Wir verwenden nicht die DFS-Replikation, sondern nur DFS für die Abstraktion von Dateifreigaben. Ihre Kommentare zu DNS-Only-Umgebungen sind jedoch interessant - viele unserer Server sind Windows 2008, aber alle Workstations sind XP und wir haben auch einige Windows 2003-Server. Wenn ich die Möglichkeit habe, dies weiter zu verfolgen, denke ich, dass ich versuchen kann, WINS zu installieren und zu sehen, ob das hilft. - Matt


Der Client zwischenspeichert einen DFS-Verweis, d. H. Wenn Sie \ domain.name \ namespace eingeben, wird der tatsächliche Server, auf den sich domain.name bezieht, zwischengespeichert. Sobald der Verweis aus dem Cache abläuft, muss der Client seine DFS-Topologie im Grunde wieder "aufdecken", daher die Verzögerung.

Schau mal hier: 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, wie das funktioniert.

Mögliche Lösungen? Eine hackige Art, das zu tun, könnte sein, ein kleines Programm zu schreiben, das alle paar Minuten "am Leben hält"; z.B. ein C-Programm, das die erste gefundene Datei öffnet und sofort schließt. Ich habe das nicht ausprobiert oder getestet, und Sie müssten auf jeden Fall sorgfältig überlegen, ob Sie es tun würden.


1
2017-08-06 08:54



Der normale DFS-Verweis sollte nicht so lange dauern, wie das Poster anzeigt. - Evan Anderson
Danke, wir werden uns morgen einlesen, um den Empfehlungsprozess besser zu verstehen. Ich mag die "Lösung" jedoch nicht: -S Wenn ich das nur so umgehen möchte, könnte ich die Cache-Dauer zu einem großen Wert machen, aber ich möchte die "richtige" Lösung für das Problem finden. - Matt


Wir hatten ein ähnlich klingendes Problem, bei dem Benutzer Verzögerungen (bis zu einer Minute) zwischen dem Klicken auf ein Laufwerk, das einer DFS-Freigabe zugeordnet ist, und dem Anzeigen und Durchsuchen der Ordner in der Freigabe feststellen können.

Die Benutzer hatten auch Home-Laufwerke, die auf einem anderen DFS-Share auf demselben Volume zugeordnet sind, und hatten keine Verzögerung beim Zugriff auf Ordner dort.

Der Unterschied zwischen den beiden ist Access-Based Enumeration (ABE) - die Problemfreigabe hat dies aktiviert (es ist ein gemeinsames 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 die Benutzer dann alle Ordner sehen und sie verwirren. Ich habe die DFS-Freigabe als temporäre Maßnahme auf einen Server mit einer Ersatzfestplatte repliziert, und selbst wenn ABE für dieses neue Ziel aktiviert ist, ist die Verzögerung verschwunden.

Der Problemserver ist 2k3R2 und hat eine Betriebszeit von mehr als 150 Tagen (!), So dass er neu gestartet wird und CHKDSK über das problematische Laufwerk läuft. Ich werde hier zurück posten, wenn dies für das Problem einen Unterschied macht. Das neue Ziel ist auf einem 2k8-Server.


1
2017-09-10 22:33



Danke, aber wir benutzen ABE (noch) nicht, also ist das nicht das Problem. - Matt


dfsutil / spcflush und dfsutil / pktflush können auch in einem Netzwerk mit mehreren Standorten eine Lösung sein. Stellen Sie sicher, dass der DFS-Link der Home-Site vom lokalen Server kommt und nicht vom Cache.


1
2017-10-22 10:42



Danke für den Vorschlag - Single Site jedoch. - Matt


Ich weiß, dass das ursprüngliche Poster WINS nicht verwendet hat, aber ich poste für andere, da wir diesen Beitrag am häufigsten verwendeten, um ein sehr ähnliches Problem zu lösen. Für uns endete es damit, dass jemand beschloss, seine Workstation mit dem gleichen Namen wie die Domain zu benennen. Jedes Mal, wenn der Domänencontroller den Domainnamen nach dem DFS-Verweis durchforstete, wollte er auf diese Workstation auflösen und würde eine beträchtliche Verzögerung von mehreren zehn Sekunden verursachen. Ein statischer 20 Eintrag wurde in den WINS platziert, der auf einen DC zeigt, und das hat das Problem gelöst. Wenn Sie keinen WINS hätten, könnten Sie experimentieren, indem Sie den Domänennamen als Maschinennamen in die LMHOSTS-Datei auf einen Domänencontroller setzen, um die Suche zu starten, und LMHOSTS als erste Adresse für die Auflösung von NetBIOS-Namen festlegen.


1
2018-04-18 19:22





http://technet.microsoft.com/en-us/library/cc780950(v=ws.10).aspx   Diese Seite erwähnt tatsächlich beide Domänencontroller und DFSN, wenn das hilft.

DFS-Domänencontroller- und Stammserverregistrierungseinträge

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.


1
2017-10-30 20:05





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


1
2018-04-21 12:57