DFS - Der Pfad ist nicht verfügbar

[Vinc211 1]

Guten Tag,

 

3 Fileserver an 3 Standorten Windows 2016 und 2019

5 Namespaces unter \\domain.loc\domain mit 3 NamespaceServern

 

Ich habe ein kleines Problem mit DFS. Ein paar User aus einem unserer 3 Standorte bekommen die Fehlermeldung: "Der pfad ist nicht verfügbar." "Auf X:\Allgemein kann nicht zugegriffen werden." "das netzwerkadresse ist nicht erreichbar."

Wenn ich in die Einstellungen des Ordners (egal welcher der 5) unter DFS mit das Ziel/Referenzliste ansehe steht dort: \\fileserver1\Allgemein - Aktiv ja - Status ok

Gebe ich den Pfad in den Explorer ein habe ich kein Problem damit den Ordner zu erreichen.

Wenn ich dann in den explorer gehe auf \\domain.loc sehe ich den Ordner domain gehe dort hinein und kann auch alle Ordner erreichen.

Ob Servername, FQDN oder IP Adresse ich kann den Ordner erreichen. Es betrifft ebenfalls nicht alle Kollegen aus dem Standort. Es scheint hauptsächlich Personen im VPN daran zu leiden. nslookup, tracert und ping auf domain.loc etc zeigen allerdings keine Fehler.

Das gemappte Laufwerk wird korrekt angezeigt. Alle 3 Namespace Server haben den Status okay und man kann diese ohne Probleme wechseln.

 

Das einzige was also nicht geht ist der Click auf die Namespaces. Wie kann es sein das der Pfad der dort angezeigt wird per Explorer erreichbar ist, aber nicht per Click?

 

Ich hoffe jemand hat eine Idee.

 

Vielen dank.

[Weingeist 159]

Wieso tut man sich bei sowas kritischem wie ein DFS-Root verschiedene Server-Versionen/Stände an? Auch wenn die Chance eher klein ist, dass hier das OS der Schuldige ist weil an DFS nicht so wirklich entwickelt wurde, es ist halt unnötig ;)

 

Da bleibt wie so oft nur Mühsam alles mögliche durchchecken

- Kannst Du denn auf den Clients jedes der verschiedenen Ziele erreichen wenn Du direkt die FQDN eingibst? Also nicht nur von Deinem PC aus oder von jenen die gut sind?

- Teste mal eine Firewallfreigaben In/Out mit vollen Berechtigungen zu den AD-Servern. Wenn es dann geht, blockt irgendwas.

- Dann kann noch eine nicht gute Replikation zwischen den AD-Servern und somit dem DFS-Root ein Problem sein (Replikation prüfen), sprich Daten sind nicht gut bei einem AD

- Dann kann sich ein Client per VPN evtl. einen "falsches" Fileserver anlachen, welcher gar nicht für seinen Standort ist und somit evtl. nicht erreichbar ist (oben eigentlich ausgeschlossen)

- Zu guter letzt, wenn DNS nicht perfekt ist, dann läuft auch DFS nicht wirklich sauber (evtl. als erstes einfach mal DNS cache löschen im client)

[Dukel 454]

19 hours ago, Vinc211 said:

Es scheint hauptsächlich Personen im VPN daran zu leiden. nslookup, tracert und ping auf domain.loc etc zeigen allerdings keine Fehler.

Hauptsächlich oder nur?

Gibt es auch Anwender im LAN, die das Problem haben?

Gibt es auch Anwender im VPN, die dieses Problem nicht haben?

 

Hier gab es letztens einen Thread wegen VPN und Netzlaufwerken.

[Vinc211 1]

Am 2.2.2021 um 09:30 schrieb Weingeist:

Wieso tut man sich bei sowas kritischem wie ein DFS-Root verschiedene Server-Versionen/Stände an? Auch wenn die Chance eher klein ist, dass hier das OS der Schuldige ist weil an DFS nicht so wirklich entwickelt wurde, es ist halt unnötig ;)

 

Da bleibt wie so oft nur Mühsam alles mögliche durchchecken

- Kannst Du denn auf den Clients jedes der verschiedenen Ziele erreichen wenn Du direkt die FQDN eingibst? Also nicht nur von Deinem PC aus oder von jenen die gut sind?

- Teste mal eine Firewallfreigaben In/Out mit vollen Berechtigungen zu den AD-Servern. Wenn es dann geht, blockt irgendwas.

- Dann kann noch eine nicht gute Replikation zwischen den AD-Servern und somit dem DFS-Root ein Problem sein (Replikation prüfen), sprich Daten sind nicht gut bei einem AD

- Dann kann sich ein Client per VPN evtl. einen "falsches" Fileserver anlachen, welcher gar nicht für seinen Standort ist und somit evtl. nicht erreichbar ist (oben eigentlich ausgeschlossen)

- Zu guter letzt, wenn DNS nicht perfekt ist, dann läuft auch DFS nicht wirklich sauber (evtl. als erstes einfach mal DNS cache löschen im client)

 

Danke für die Tipps. Ich kann alle FQDN direkt erreichen ohne Probleme. Sowohl von meinem PC als auch von dem wo es diese DFS Probleme gibt.

Firewall steht auf Durchzug. Habe die Einstellungen auch nochmal angepasst und es brachte keine Besserung.

Replikation der DFS Server habe ich inder DFS Verwaltung testen lassen. Gab keine Probleme. Auch die Ereignisanzeige hat mir nix als Fehler ausgegeben.

Der Client ist zwar vom AD her in einem anderen Standort, aber wenn das VPN aktiviert ist in der Default First Site und zu diesem FileServer verbindet sich das DFS auch. Man kann dann wechseln, aber das behebt das Problem nicht, bzw. Bei client wo alles läuft kann man auch wechseln und es läuft weiter.

DNS Cache löschen versuch ich als nächstes.

 

Am 2.2.2021 um 09:31 schrieb Dukel:

Hauptsächlich oder nur?

Gibt es auch Anwender im LAN, die das Problem haben?

Gibt es auch Anwender im VPN, die dieses Problem nicht haben?

 

Hier gab es letztens einen Thread wegen VPN und Netzlaufwerken.

 

Es sind keine Anwender im LAN bekannt die das Problem haben

Es gibt anwender im VPN die absolut keine Probleme haben.

 

Ich habe heute einen neuen User im AD angelegt, ihm die Gruppen einer Person gegeben bei der es nicht geht.

Zudem eine VM aufgesetzt und diese in die Domain gehängt. Das Computerkonto befindet sich in einem Standort und die Netwzerkkarte in einem externen WLAN.

Habe mich dann per VPN verbunden und kann leider die Probleme nicht nachstellen.

[daabm 1.354]

Tipp: Bei DFS _immer_ mit FQDNs arbeiten. IMMER und ÜBERALL. Auch wenn man die dann eintippen muß, weil der dämliche Browse-Button eigentlich immer nur die Hostnamen einträgt.

Und kleine Frage: Die Leute, die Probleme haben - haben die evtl privat ne DNS-Domain, die da nen Konflikt produziert? Falsche DNS Suffixe oder Search Lists? DHCP im VPN kommt ja i.d.R. nicht nur vom VPN, sondern auch vom Heimnetz...

 

BTW: Ein Netzwerktrace auf nem Rechner, wo's nicht geht, könnte recht schnell Klarheit schaffen. Da sieht man nämlich, wohin der MUP tatsächlich will...

[Weingeist 159]

vor 13 Stunden schrieb Vinc211:

Ich habe ein kleines Problem mit DFS. Ein paar User aus einem unserer 3 Standorte bekommen die Fehlermeldung: "Der pfad ist nicht verfügbar." "Auf X:\Allgemein kann nicht zugegriffen werden." "das netzwerkadresse ist nicht erreichbar."

---------------------------------------------------------------------------

Es sind keine Anwender im LAN bekannt die das Problem haben

Es gibt anwender im VPN die absolut keine Probleme haben.

 

Ich habe heute einen neuen User im AD angelegt, ihm die Gruppen einer Person gegeben bei der es nicht geht.

Zudem eine VM aufgesetzt und diese in die Domain gehängt. Das Computerkonto befindet sich in einem Standort und die Netwzerkkarte in einem externen WLAN.

Habe mich dann per VPN verbunden und kann leider die Probleme nicht nachstellen.

 

Ich bin ich jetzt nicht sicher ob ich das richtig verstanden habe, aber hast Du die Probleme nur mit den Netzlaufwerken? Du sprichst von "X:\", das habe ich erst etwas überlesen. Oder kommst Du nun auch mit "\\dom.loc\DFS-Root\Folder" auf diesen Maschinen nicht drauf. Hab da ein Knopf. =)

Gleicher PC, anderer User (z.Bsp. neues Profil schon getestet?)

 

Bei Netzlaufwerken: Einfach mal alles rauschmeissen. Also Registry manuell bearbeiten damit restlos alles weg ist wenn einfaches trennen nicht reicht. User-Basis + Computerbasis. Dann neu starten. Dann neu verbinden. Und wie daabm bemerkt hat, unbedingt mit vollständiger fqdn verbinden.

 

Wenn etwas mit dem Anmelde-Token nicht stimmt, gibts manchmal auch Ärger. Sprich die Authentifizierung für die Domäne fehlt/verloren geht. Ursachen gibts da diverse. DFS reagiert hier auch ziemlich heikel.

 

AD Sync wäre auch eine theoretische Möglichkeit, also wenn der DFS-Stamm nicht korrekt repliziert wurde. Das müsste aber eigentlich bei allen zu Problemen führen. Ausser es gehen nicht alle über die gleichen AD-Server.

 

Aber eben ich würde auch mal Wireshark oder so anschmeissen und analysieren was da abgeht. Eventuell auch das Firewall-Journaling aktivieren.

Deutsch: auditpol.exe /set /category:"Objektzugriff" /subcategory:"Filterplattform: verworfene Pakete" /success:enable /failure:enable
International: auditpol.exe /set /category:"{6997984A-797A-11D9-BED3-505054503030}" /subcategory:"{0CCE9225-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable

 

Ansonsten: Hast mal versucht alles an IPv6 Helper Geschmäus rauszukicken um IPv4 zu erzwingen? Macht die Fehlersuche oft einfacher, auch per Wireshark. (Protokoll auf Netzadapter entfernen, Helper Services deaktivieren, IPv6 in Firewall Out explizit blocken, Priorität auf IPv4 einstellen, Komponenten deaktivieren evtl. auch SubService blockieren.)

[Vinc211 1]

Da das Problem immernoch besteht habe ich diesen Thread nochmal ausgegraben.

 

Es ist so das dies nur beim klicken aufs Laufwerk etc. passiert. Das Eingeben des FQDN funktioniert immer.

 

Manchmal funktioniert es nach einem Neustart wieder. Vor und nach dem Neustart sind ping auf dom.loc und alle ipconfig/all einstellungen gleich.

[Forseti2003 14]

Am 8.6.2021 um 11:24 schrieb Vinc211:

Da das Problem immernoch besteht habe ich diesen Thread nochmal ausgegraben.

 

Es ist so das dies nur beim klicken aufs Laufwerk etc. passiert. Das Eingeben des FQDN funktioniert immer.

 

Manchmal funktioniert es nach einem Neustart wieder. Vor und nach dem Neustart sind ping auf dom.loc und alle ipconfig/all einstellungen gleich.

Greift der VPN-User auf eine IP-Adresse zu oder auf den fqdn? Wenn fqdn prüf auch mal die HOST-Datei lokal im Windows-Verzeichnis oder die Routen, wie die eingetragen sind. Eventuell kommt der PC durcheinander. Kann es auch sein das die PC's die es betrifft WLAN und LAN haben oder sind diese nur auf einen Netzwerkweg ausgelegt?

[Weingeist 159]

Ich sage ja, schmeiss alles mal raus - auch alles was du in der Registry findest - und starte neu. Sicherstellen das es nicht mehr da ist. Dann verbinde es neu mit der FQDN und schau ob es dann Neustart-Fest ist oder nicht. Oder eben allfällige Logon-Scripts und/oder GPO's anpassen oder deaktivieren.

 

Dann gibts noch den hübschen Bug mit der Netzwerkerkennung. Sprich wenn er das Netz nicht erkennt (Sanduhr dreht und dreht und ....). Da hilft dann Netzadapter aktivieren/ deaktivieren bzw. neustart des Dienstes nla. (Oft hilft es ihn auf Automatisch verzögert einzustellen)

 

Ahja, ob Du was mit den Firewalllogs und Wireshark versucht hast, hast noch nicht beschrieben.

[Vinc211 1]

Habe nun mit Wireshark einen Mitschnitt gemacht.

Beim Aufrufen des Ordners Bremen kommen folgende Antworten:

SMB2 - Create Response, Error: STATUS_PATH_NOT_COVERED

 

etwas später im Protokoll findet sich auch:

SMB2 - Create Response, Error: STATUS_FILE_IS_A_DIRECTORY

 

leider kann ich dazu nicht viel finden und es auch nicht erklären. Netzwerk Problem wahrscheinlich, aber warum nur teilweise.

 

Wireshark habe ich bei einem Kollegen ausgeführt der das Laufwerk erreichen konnte und dann im laufenden Betrieb plötzlich nicht mehr. (so die aussage)

[Forseti2003 14]

Hast Du mal Deine DNS-Server geprüft, ob die sich gegenseitig sauber erkennen und die Zoneneinträge übernehmen? Auch mal die Zone prüfen, nicht das versehentlich einige Einträge ins Nirwana führen.

[Vinc211 1]

vor 1 Minute schrieb Forseti2003:

Hast Du mal Deine DNS-Server geprüft, ob die sich gegenseitig sauber erkennen und die Zoneneinträge übernehmen? Auch mal die Zone prüfen, nicht das versehentlich einige Einträge ins Nirwana führen.

ich kann im DNS keine Probleme feststellen, da alle nslookups und fqdn abfragen sauber laufen. wie gesagt: alle aufrufe funktionieren solange man sie manuell macht, nur der Doppelklick auf das Laufwerk funktioniert nicht.

 

ich überprüfe nochmal alles im DNS, glaube aber nicht das ich was finden werde.

[Weingeist 159]

So wie es aussieht scheitert er schon ziemlich früh. Ohne den Rest gesehen zu haben würde ich sagen, er findet den Pfad im Cache, will auf diesen zugreifen, kann aber den Domänen-Namen nicht auflösen.

 

Mögliches Problem:

- Keine saubere DNS-Auflösung in jenem Moment wo die Verbindung aufgebaut werden soll.

- Noch keine aktive Domänenzugehörigkeit (Sichtbar beim Netzadapter)

- Anderes Sicherheitstoken das nicht mehr gültig ist sobald er sich mit VPN einklinkt, die Verbindung hat er eventuell mit einem alten versucht aufzubauen, was dann scheitert.

-->laufwerke trennen und neu verbinden nachdem ein manueller Zugriff geklappt hat. Das gleiche auch mal nach einem Neustart und erst verbinden wenn VPN aufgebaut ist (das meinte ich mit alles rauskicken)

- Netzwerkprobleme --> Zu viel Paketloss --> Sicherheitstoken macht Ärger bzw. der Client verliert das Vertrauen des AD, dabei wird es bei verbundenen Netzlaufwerken gar nicht oder nicht sofort wiederhergstellt. Manueller Zugriff funktioniert dann meistens trotzdem, aber nicht zwingend stabil. (Hier hier es mal funktioniert indem ich die Geschwindigkeit gedrosselt habe, ist aber via VPN wohl eher tricky)

- Möglicherweise gibt es auch Ärger wenn das Netzlaufwerk via einem anderen Adapter aufgebaut wird, also einmal WLAN und dann LAN oder VPN-Adapter. Dann könnte es sein, dass irgendwo eine definierte Route gecached ist, die dann fehlschlägt.

 

EDIT: Hier findest den Ablauf einen DFS-Requests: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dfsc/1ff7d611-ba19-49fb-95f4-7c5358b86834

 

Aber eben, hier hilft vermutlich am Ende nur systematischen vorgehen, ausprobieren...

bearbeitet 18. Juni 2021 von Weingeist

[Vinc211 1]

vor 17 Minuten schrieb Weingeist:

So wie es aussieht scheitert er schon ziemlich früh. Ohne den Rest gesehen zu haben würde ich sagen, er findet den Pfad im Cache, will auf diesen zugreifen, kann aber den Domänen-Namen nicht auflösen.

 

Mögliches Problem:

- Keine saubere DNS-Auflösung in jenem Moment wo die Verbindung aufgebaut werden soll.

- Noch keine aktive Domänenzugehörigkeit (Sichtbar beim Netzadapter)

- Anderes Sicherheitstoken das nicht mehr gültig ist sobald er sich mit VPN einklinkt, die Verbindung hat er eventuell mit einem alten versucht aufzubauen, was dann scheitert.

-->laufwerke trennen und neu verbinden nachdem ein manueller Zugriff geklappt hat. Das gleiche auch mal nach einem Neustart und erst verbinden wenn VPN aufgebaut ist (das meinte ich mit alles rauskicken)

- Netzwerkprobleme --> Zu viel Paketloss --> Sicherheitstoken macht Ärger bzw. der Client verliert das Vertrauen des AD, dabei wird es bei verbundenen Netzlaufwerken gar nicht oder nicht sofort wiederhergstellt. Manueller Zugriff funktioniert dann meistens trotzdem, aber nicht zwingend stabil. (Hier hier es mal funktioniert indem ich die Geschwindigkeit gedrosselt habe, ist aber via VPN wohl eher tricky)

- Möglicherweise gibt es auch Ärger wenn das Netzlaufwerk via einem anderen Adapter aufgebaut wird, also einmal WLAN und dann LAN oder VPN-Adapter. Dann könnte es sein, dass irgendwo eine definierte Route gecached ist, die dann fehlschlägt.

 

EDIT: Hier findest den Ablauf einen DFS-Requests: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dfsc/1ff7d611-ba19-49fb-95f4-7c5358b86834

 

Aber eben, hier hilft vermutlich am Ende nur systematischen vorgehen, ausprobieren...

 

Habe pings laufen und nslookup in allen variationen getestet während ich das laufwerk anklicke. DNS kanns nicht sein.

Domänenzugehörigkeit ist da und soweit ich weiß kann diese doch nicht einfach im laufenden Betrieb verschwinden wenn man nichts am Netzwerk / VPN macht.

Das Laufwerk wird per GPO verbunden. Ich habe auch schon das Laufwerk entfenrt und bei bestehender Verbindung gpupdate durchgeführt doch der Fehler blieb bestehen. Manuell hab ich es glaube ich noch nicht versucht.

Paketloss schließe ich auch aus, da die Remoteverbindungen und Datei-Downloads über Workarounds ohne Probleme klappen.

Kollegen sind zuhause alle im WLAN und und dann per VPN Verbunden. Wie gesagt funktioniert es bei manchen dann einfach en VPN neuzustarten und dann gehts, bei manchen nicht.

 

Was mir auffällt ist das die Antworten im Wireshark nicht vom "nächsten" Namespace kommen sondern von einem anderen Standort. Die User kriegen per VPN eine IP die ich in AD Standort und Dienste der Default First Site zugewiesen habe, doch die antwort auf nslookup domain.loc und die Antwortem im Wireshark kommen alle auf einem Standort und nicht vom DC und Fileserver der Default-First-Site

[Forseti2003 14]

Anderer Ansatz wäre das VPN-Gateway, hat das vielleicht eine Policy/NAT-Routing aktiv die da ein Problem verursacht?