20.04.2016, aktualisiert um 20:06:55 Uhr

11726

DFS und Netzwerkprobleme

Hallo zusammen,

ich habe bei uns ein Problem, bei dem ich zurzeit nicht weiter komme.

Bei jedem User wird bei Anmeldung am Windows Rechner 2 Netzlaufwerke verbunden.
Der dazugehörige Fileserver steht an diesem Standort und repliziert die Daten mittels DFS an den Fileserver in den anderen 2 Standorten.

Das Problem ist, dass in diesem neuen Standort bei allen Usern sporadisch die Netzlaufwerke nicht mehr funktionieren (..konnte keine Verbindung herstellen)
Der DFS Namespace liegt auf dem Fileserver im anderen Standort.
Gebe ich im Explorer aber die Netzwerkadresse des Fileservers ein und greife dort auf die Freigabe zu, funktioniert das.

Was kurzfristig hilft, ist die IP Adresse per ipconfig /release und /renew zu erneuern.
Danach funktioniert der Zugriff wieder, bis es wieder sporadisch auftritt.

Das es ein neuer Standort ist, woran könnte es liegen?

Möglichkeiten, die ich in Betracht ziehe:
- Netzwerk
- DC (darauf läuft auch der DNS)
- DFS
- Firewall (VPN Verbindung)

Habt Ihr eine Idee?

LG Herbi

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 302389

Url: https://administrator.de/forum/dfs-und-netzwerkprobleme-302389.html

Ausgedruckt am: 23.12.2024 um 07:12 Uhr

42 Kommentare

Neuester Kommentar

Hi,
habe ich das richtig verstanden:
Du hast einen neuen Standort. Dort gibt es einen Fileserver. Der Fileserver hat ein Share, welches im DFS als DFS-Ordner verlinkt ist. Die Daten des Shares werden per DFS-R mit den anderen Standorten repliziert. Der DFS-Stamm hat jedoch kein Ziel am neuen Standort?
Falls zutreffend:
Ich würde zuerst auf dem Fileserver des neuen Standorts eine Freigabe für den DFS-Stamm einrichten und diese dann auch als Stamm-Ziel eintragen.
Weiterhin: Ist am neuen Standort auch ein DC? Egal, ob ja oder nein, solltest Du für diesen Standort in jedem Fall auch ein Standort-Objekt im AD anlegen. Dabei natürlich auch die die IP-Subnetze des Standorts im AD anlegen. Nur so können die Clients an diesem Standort ermitteln, dass es für die DFS-Ziele einen Fileserver am gleichen Standort gibt und dieses dann auswählen. Sonst arbeiten sie u.U. über WAN.
Ein DC vor Ort würde dabei helfen, dass die Ermittlung des DFS-Stamms nicht über die Leitung mit einem DC am anderen Standort erfolgen muss.

Was kurzfristig hilft, ist die IP Adresse per ipconfig /release und /renew zu erneuern.

Das könnte nun auf verschiedenes hindeuten. Z.B. das dabei der DNS-Cache geleert wird (weiß ich nicht genau) und es deshalb hinterher wieder geht. Oder dass Du ein Problem in der Adressierung hast. Bekommt der Rechner nach dem /renew die selbe IP-Adresse oder eine andere? Falls eine andere, könnte es sein, dass die vorherige möglicherweise (inzwischen) doppelt vergeben war?

Wenn z.Z. kein DC vor Ort und auch kein Ziel für den DFS-Stamm, dann können kleine Störungen (z.B. Leitungsaussetzer) dafür sorgen, dass die Clients entweder den DFS-Stamm gar nicht ermitteln können (kein Zugriff auf einen DC) oder dessen Freigaben nicht erreichenm (kein Zugriff auf die Fileserver am anderen Standort.)

E.

Ja jeder Standort hat einen DC als replikation.

Was meinst du mit: jeden Standort im AD hinterlegen?
Im DNS sind die hinterlegt.

Zitat von @opc123:
Ja jeder Standort hat einen DC als replikation.

DC ist hier irrelevant.
Es geht ums DFS. Hat der DFS-Ordner mehrere Ziele? Und wenn ja,

sind diese repliziert?
stehen die betreffenden Fileserver an den Standorten?

Was meinst du mit: jeden Standort im AD hinterlegen?

Sie MMC "Active Directory Standorte und Dienste".
Dort sollte man für jeden geografischen WAN-Standort (Anbindung < 100 Mbit) auch einen logischen AD Standort erstellen. Für jedes IP-Subnet an diesem geografischen Standort dann ein IP-Subnet-Objekt im AD erstellen und dem logischen AD-Standort zu ordnen. Dann Replikationsverknüpfungen einrichten bzw. konfigurieren. Replikation abwarten.
Dann erkennen Windows Clients, welche AD Member sind, selbständig, zu welchem AD-Standort sie gehören und suchen sich beim Zugriff auf AD (DC) und/oder DFS-Ordnern vorzugsweise einen Server, welcher zum selben AD Standort gehört.

Jeder Dfs Ordner hat nur ein Ziel.

Auch die AD Subnetze sind richtig hinterlegt.

Komischerweise wird über domain/ordner immer die dfs gegenstelle aufgerufen statt der Server am Standort.
Das sehe ich durch tests mit großen Daten.

Desweiteren verlieren sich berechtigungen im Dfs Aufruf?
Ich habe mit Usern im Dfs Pfad keinen zugriff auf Unterordner obwohl dieser vorhanden ist.
ÜberServer/Pfad ist der Zugriff aber möglich.

Welche Ports nutzt das DFS? Nicht das hier das VPN schuld hat...
VG

Wenn jeder DFS-Ordner nur genau ein Ziel hat, beim Zugriff darauf aber immer der "falsche" Server angesprochen wird (nicht am gleichen Standort wie der Client), dann würde das doch bedeuten, dass der Ordner am "falschen" Standort (Server) gespeichert ist.

Das sehe ich durch tests mit großen Daten.

Das kannst Du ganz einfach im Windows Explorer sehen.

Gehe in einen DFS-Ordner (\\domäne\stamm\dfs-ordner).
Wähle dort drin einen Unterordner aus --> Eigenschaften --> DFS
Dort siehst Du, welches das für diesen Client aktive Ziel ist.

Welche Ports nutzt das DFS? Nicht das hier das VPN schuld hat...

Warum? Wenn das VPN- und/oder die Firewall-Regeln die Ursache wären, dann könntest Du entweder dauerhauft nicht zugreifen oder doch. Und dann würdest Du auch nicht "Zugriff verweigert" gemeldet bekommen.

Da steht bei Aktive der falsche Server?

Wie ändere ich das um?

Ich bekomme auch einen Fehler im Ereignislog:

Automatic registration failed at join phase.

AD Configuration Test : FAIL [0x80070002]

Zitat von @opc123:
Da steht bei Aktive der falsche Server?

Ist das eine Frage oder eine Feststellung?
Falls das eine Frage ist: Das hast Du so geschrieben.
Falls nicht: Woher sollen wir das wissen?

Wie ändere ich das um?

Wenn jeder DFS-Ordner nur ein Ziel hat - wie Du ja angegeben hast - dann kann Ändern hier nur bedeuten, dass Du die Daten auf den "richtigen" Server transferierst und dort freigibst und den DFS-Ordner dann auf diese Freigabe umstellst.
Oder - falls der "richtige" Server je Standort anders ist und es an mehreren Standorten Clients gibt, für welche der "richtige" Server immer der standortlokale sein soll - Du richtest eine Datenreplikation mittels DFS-R ein. Gibst dann alle Replikate auf allen betreffenden Servern frei und trägst alle Replikat-Freigaben als weitere Ziele in die Konfiguration des betreffenden DFS-Ordners ein.

Ich bekomme auch einen Fehler im Ereignislog:
Automatic registration failed at join phase.
AD Configuration Test : FAIL [0x80070002]

In wessen Ereignislog? Und wann kommt der Fehler? Beim Mittagessen? Beim Kaffee?

Im DFS habe ich 2 ziele so gesehen.
Server a zu Server b
Server b zu Server a

Server a sollen Clienten Standort a bevorzugt zugreifen
Server b nur wenn diese am Standort b sind oder den Terminal Server im Standort b nutzen.

Bei Client x am Standort a steht der server b als aktiv drin.

Ist das richtig oder falsch?

Der Fehler kommt beim Client nach jedem Neustart.

Zitat von @opc123:
Im DFS habe ich 2 ziele so gesehen.
Server a zu Server b
Server b zu Server a

Was soll das sein? Verwechselst Du jetzt DFS-Namespace und DFS-Replikation?
Ein Ziel eines DFS-Ordners ist ein UNC-Pfad.

Server a sollen Clienten Standort a bevorzugt zugreifen
Server b nur wenn diese am Standort b sind oder den Terminal Server im Standort b nutzen.

Ja, so ist das i.A. erwünscht.

Bei Client x am Standort a steht der server b als aktiv drin.

Und Server a wird da aber auch angezeigt? Oder gar nicht?

Server a wird dort auch angezeigt, aber nur Server b als aktiv?
Aber es müsste doch Server a als aktiv sein oder nicht?
Server a steht ja mit im Standort.

wo sehe ich einen UNC Pfad?

in der Replication habe ich 2 Sendende Mitglieder.

Zitat von @opc123:
Server a wird dort auch angezeigt, aber nur Server b als aktiv?
Aber es müsste doch Server a als aktiv sein oder nicht?
Server a steht ja mit im Standort.

Und an welchem Standort ist der Client, an welchem Du da gerade arbeitest?
Tip:
Ein "gpresult /r" verrät Dir ganz nebenbei, zu welchem Standort sich ein Client gehörig fühlt. Oben im Kopf der Ausgabe "Standortname:".
CMD "als Administrator ausführen" --> gpresult /r

Zitat von @opc123:
wo sehe ich einen UNC Pfad?

In der Konfiguration des DFS-Ordners natürlich.

in der Replication habe ich 2 Sendende Mitglieder.

Prima.

Da weis ich nicht wo.
Meist du im Namespaces unter Ordnerziele?
Dort sind natürlich beide Ordner je Fileserver drin.

Zitat von @opc123:
Da weis ich nicht wo.
Meist du im Namespaces unter Ordnerziele?

Ja.

Dort sind natürlich beide Ordner je Fileserver drin.

Gut, das hätten wir jetzt geklärt.

Und meine andere Frage?

Du meinst das gpresult?

Ja da ist was eigenartig:

Standort ist korrekt.
Computerrichtlinie wird vom richtigen DC angefragt
Benutzerrichtlinie aber von dem anderen Standort???

Zitat von @opc123:
Standort ist korrekt.

Ob es der gleiche ist wie der des "richtigen" Servers, war die Frage!

Benutzerrichtlinie aber von dem anderen Standort???

Das schlussfolgerst Du über den verwendeten DC?
Sind denn Benutzer und Computer in der selben Domäne?

Aber das ist eh für DFS-N irrelevant. Interessant ist nur, was unter "Standortname" gemeldet wird.

Ja der Standort ist der selbe wie der richtige Server.

Ja sind in der selben Domäne.

Aber ich habe auch gerade das Problem, dass Benutzer die Sicherheitsgruppen nicht anwenden trotz neuem Login.

Zitat von @opc123:
Aber ich habe auch gerade das Problem, dass Benutzer die Sicherheitsgruppen nicht anwenden trotz neuem Login.

Was heißt nicht anwenden? Funktioniert etwas nicht wie erwartet oder hast Du eine Auswertung gefahren und siehst dort nicht alle Gruppen? z.B. in der Ausgabe des gpresult?

Beides.
Es fehlen Gruppen und auch funktioniert dadurch nicht alles wie gewollt.

Grund ist das teilweise der DC am anderen Standort genutzt wird, wieso auch immer....

Zitat von @opc123:
Grund ist das teilweise der DC am anderen Standort genutzt wird, wieso auch immer....

Grund nur, wenn dieser andere DC nicht richtig repliziert. Sonst wäre das vollkommen egal. Weil Du ja nur eine Domäne hast, wie Du sagst.
Also überprüfe die Replikation der DC's.

Die ist okay.

Aber folgendes Problem ist aufgefallen:

Erstelle ich im Ad ein neuen Benutzer oder füge einen Benutzer die Gruppe zu welche die Berechtigung hat um auf den DFS Ordner zu zu greifen, bekommt er diw Berechtigung nicht.
Auch nach Neustart nicht.
Erst wenn ich auf die Dfs Freigabe die Gruppe neu hinzu füge?

Kanns an der Gruppe liegen?
Je Server Freigabe auf dem Server wurde die selbe Lokale Gruppe genutzt.
Ist bei DFS nicht Global besser?

Und was passiert bei Lokaler in Lokaler Gruppe?
Viel Speicherplatz soweit ich weiß.

@opc123
Nimm es mir bitte nicht übel. Aber all diese Frage suggerieren mir, dass Du da nicht wirklich Ahnung hast, was Du da eigentlich machst. Hole Dir doch bitte externe Hilfe ins Haus, wenn es denn wichtig ist.

Da Du nur eine Domäne hast, ist es für NTFS vollkommen egal, welchen Gruppentyp Du verwendest. Hauptsache, es sind "Sicherheitsgruppen", keine "Verteilergruppen".

Alles andere ist mir jetzt zu vage.

Ja ich weiß nur: Lokale nur direkt auf Freigaben und danach mit Globalen verteilen, wobei mir gelehrt wurde: nimm nur noch Globale. Lokale fressen zu viel Speicher.

Egal. Das Problem bleibt bei der Replikation und Zugriff.

Die Daten am Standort A werden am Standort B DC sowie Fileserver abgefragt.

Standort Subnetze passen.
Die Verknüpfung IP ist doch nur für die Replikation zuständig?l

Zitat von @opc123:
Ja ich weiß nur: Lokale nur direkt auf Freigaben und danach mit Globalen verteilen,

Das wäre der klassiche, empfohlene Weg. Nennt sich A-G-DL-P.
Bei nur einer Domäne kann man aber auch A-G-P gehen.

wobei mir gelehrt wurde: nimm nur noch Globale. Lokale fressen zu viel Speicher.

Das ist dann natürlich Unsinn. Wer lehrt sowas?
Wenn man sehr komplexe NTFS-Berechtigungsstrukturen hat, welche in sehr vielen DL-Gruppen resultieren würden, und man gleichzeitig Benutzer hat, welche in vielen Rollen sind (G-Gruppen), welche dann ihrerseits wieder in vielen DL-Gruppen sind, dann kann das dazu führen, dass das Benutzertoken sehr groß wird und u.U. den technischen Rahmen sprengt. Allerdings wird man durch die inzwischen angewendete Tokenkompression bei nur einer Domäne mit Windows Servern nur in sehr großen Umgebungen Probleme bekommen.

Die Verknüpfung IP ist doch nur für die Replikation zuständig?l

Nein. Sie steuert u.a. auch die Auswahl des verwendeten DFS-Ziels. Wenn Du z.B. 5 Standorte hast, aber nur 3 mit Servern vor Ort. Dann kann man damit steuern, welchen DC's und DFS-Ziel-Server die Clients aus den Standorten ohne Server vorzugsweise nutzen. "Vorzugsweise" betont, weil man das schlussendlich nicht 100% sicher steuern kann. Wenn der Client "der Meinung ist", das etwas nicht passt, dann versucht er einen anderen Standort zu verwenden.

Okay danke!

Meine letzte Firma hat mir das so beigebracht.

Die Verknüpfungs IP wurde automatisch angelegt.
Dort sind nur die DC´s drin. Ebenso unter "Servern"

Zitat von @opc123:
Dort sind nur die DC´s drin. Ebenso unter "Servern"

Das ist so richtig. Da kommen auch keine Nicht-DC rein.

Dann passt das.
Dann ja kann ich mir das derzeit nicht erklären.
Gibt es Tools zum Testen von Dc und dfs auser Dcdiag?

Zitat von @opc123:
Gibt es Tools zum Testen von Dc und dfs auser Dcdiag?

DFSDIAG

Das ist auch i.o.

Kann es sein das der Server einfach "überlastet" ist durch Offline Daten?

Es kann auch sein, dass heute Donnerstag ist. Ich weiß es nicht.
Wo würdest Du ansetzen, wenn Dein Auto mit Dir am Steuer immer wieder durch die Mittagstraße fährt, anstatt - wie gewünscht - durch die Morgenstraße?

Ja ich werde es mal prüfen.

Fakt ist das Zugriffe oft verweigert werden weil der Client oder User die Berechtigung verliert.

Folgendes habe ich raus gefunden:

Nutzer haben mit einen Moment keinen Zugrif mehr auf den DFS Pfad.

Lokal über //Server ist der Aufruf möglich.

Fehlermeldung: keine Berechtigung.

Startet man auf dem Client irgend eine Anwendung als Admin funktioniert es danach wieder??

Was könnte da noch faul sein?

Zitat von @opc123:
Startet man auf dem Client irgend eine Anwendung als Admin funktioniert es danach wieder??

Wird dabei ein anderes Benutzerkonto "als Admin" angegeben oder hat dieser betreffende Benutzer selbst Admin-Rechte auf diesem Client?
Und funktioniert es dann in dieser einen "als Admin" gestarteten Anwendung oder dann auch in anderen, nicht "als Admin" gestarteten?

es wird mit einem anderen Benutzerkonto als Admin gestartet.
Danach hat der Benutzer selbst wieder seine "rechte"
Das ganze happert nur beim dfs zugriff über die Domain

Hallo,

kann es sein, dass der Vorbesitzer eventuell doppelte SID´s durch Clonen verursacht hat und es daher zu Problemem führt mit Zugriffen auf \\domaine\ordner?

Sowas kann sein. Es müsste aber sehr speziell sein.
Die lokalen SID's des Computers sind kein Problem mehr, da die Computerkonten in der Domäne eh ne andere, eindeutige SID bekommen.
Was aber sein könnte wäre folgendes Szenario:

Man hat z.B. VMware oder Hyper-V.
Dort hat man für neue VM's ein nicht generalisiertes Template.
Von diesem Template erstellt man einen neuen Server.
Diesen promotet man zu einem DC für eine neue Domäne. Dabei übernimmt die Domäne die lokale System-SID des Servers.
Von diesem Template erstellt man einen weiteren neuen Server.
Diesen weiteren Server tritt man als Member der Domäne bei. Dieser Server soll Fileserver sein.
Jetzt haben die Domäne und das lokale Systemkonto des Memberservers die selbe SID. Das führt dazu, dass Konten aus dieser Domäne nicht auf Freigaben dieses Fileservers zugreifen können.

Nach o.g. Szenario wäre das dann aber ein dauerhafter Zustand, und nicht nur sporadisch auftretend.