DFS - Der Pfad ist nicht verfügbar

[Vinc211 1]

vor 1 Minute schrieb Forseti2003:

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

 

Verstehe nicht wie ein temporäres Problem bei einem Prozentsatz von leuten durch eine permanente Regel ausgelöst werden soll.

 

Wir haben eine Sophos UTM 9.7 mit dem Sophos Open VPN Client der die routen bei route.exe add setzt.

Das es dort manchmal zu DNS Problem kommt weiß ich, wie gesagt mit VPN neustart sind die dann behoben.

 

Auf meiner Suche im www bin ich übrigens auf einige gestoßen die das selbe Problem wie ich beschreiben, nur gabs da meistens keine Antworten drauf und keine Lösungen. Ich befürchte es ist MS hokus pokus.

[Weingeist 159]

Einfach mal alle möglichen Varianten durchtesten, was anderes bleibt dir nicht übrig. Dazu mit Wireshark analysieren.

1. Laufwerk eben nicht per GPO verbinden sondern wirklich erst wenn VPN voll da ist und Im Netzwerkadapter das Netzwerk angezeigt wird die Verbindung erstellen.

2. Eine Stufe retour, also Laufwerk nicht trennen, neu starten und schauen ob es nach VPN Aufbau wieder tut

3. Wieder eine Stufe retour, Laufwerk trennen, neu starten, manuell verbinden (versuchen), VPN aufbauen schauen obs tut

4. manuell trennen, manuell neu verbinden entweder direkt per Kommandozeile oder testweise erst im Explorer

 

So kriegst evtl. einen Work-Around hin der möglichst ohne Adminrecht und Neustart tut. Damit erstellst ein Script (sofern möglich und das Problem behebt), damit es der User selbst tun kann. Link auf das batch auf den Desktop. (Also Trennen und neu verbinden)

 

 

Falscher Namespace: Nun da kommen wir der Sache schon etwas näher ;)

Schuss ins blaue: Ihr habt zwei aktive DFS-Ziele aber nur eines ist per VPN erreichbar. Arbeitet er am anderen Standort, bekommt er entweder Zugriff auf beide Ziele oder auf genau ein anderes. Im Cache ist aber der Pfad zum "falschen" hinterlegt. Da verbundene Netzlaufwerke so gut wie nie - oder mir nicht erkennbaren System - aktualisiert werden, funktioniert der Zugriff nicht.

Ich denke der Workaround mit einem Script welches das Laufwerk trennt und neu verbindet, sollte funktionieren.

 

Aber von unterschiedlichen Sites und Standorten habe ich ehrlich gesagt keine Ahnung. Da ich nur kleine Umgebungen habe, versuche ich auch mehrere Standorte unter einen AD-Standort zu kriegen und die Leute per Fernzugriff auf das Hauptsystem arbeiten zu lassen. Sprich Jumphost Prinzip und möglichst Keep-it-simple. Ansonsten muss dann ein anderer ran.

bearbeitet 18. Juni 2021 von Weingeist

[Vinc211 1]

vor 1 Minute schrieb Weingeist:

Einfach mal alle möglichen Varianten durchtesten, was anderes bleibt dir nicht übrig. Dazu mit Wireshark analysieren.

1. Laufwerk eben nicht per GPO verbinden sondern wirklich erst wenn VPN voll da ist und Im Netzwerkadapter das Netzwerk angezeigt wird die Verbindung erstellen.

2. Eine Stufe retour, also Laufwerk nicht trennen, neu starten und schauen ob es nach VPN Aufbau wieder tut

3. Wieder eine Stufe retour, Laufwerk trennen, neu starten, manuell verbinden (versuchen), VPN aufbauen schauen obs tut

4. manuell trennen, manuell neu verbinden entweder direkt per Kommandozeile oder testweise erst im Explorer

 

So kriegst evtl. einen Work-Around hin der möglichst ohne Adminrecht und Neustart tut. Damit erstellst ein Script (sofern möglich und das Problem behebt), damit es der User selbst tun kann. Link auf das batch auf den Desktop. (Also Trennen und neu verbinden)

 

 

Falscher Namespace: Nun da kommen wir der Sache schon etwas näher ;)

Schuss ins blaue: Ihr habt zwei aktive DFS-Ziele aber nur eines ist per VPN erreichbar. Arbeitet er am anderen Standort, bekommt er entweder Zugriff auf beide Ziele oder auf genau ein anderes. Im Cache ist aber der Pfad zum "falschen" hinterlegt. Da verbundene Netzlaufwerke so gut wie nie - oder mir nicht erkennbaren System - aktualisiert werden, funktioniert der Zugriff nicht.

 

Aber von unterschiedlichen Sites und Standorten habe ich ehrlich gesagt keine Ahnung. Da ich nur kleine Umgebungen habe, versuche ich auch mehrere Standorte unter einen AD-Standort zu kriegen und die Leute per Fernzugriff auf das Hauptsystem arbeiten zu lassen. Sprich Jumphost Prinzip und möglichst Keep-it-simple. Ansonsten muss dann ein anderer ran.

 

Wir haben einen funktionierenden Workaround etabliert. Die User wissen das wenn das Laufwerk nicht per klick erreichbar ist Sie \\domain.loc oder \\fileserver.domain.loc eingeben können um die Daten zu erreichen. Manche haben sich da als Network share bereits eingerichtet. Aber das ist ja nicht Ziel oder Sinn des ganzen.

 

in den DFS Einstellungen kann man die Ziele ja selbst aktiv schalten und überprüfen. Alle Personen die sich per VPN anmelden bekommen in der DFS übersicht des laufwerks den richtigen share zugewiesen. Wechseln und überprüfen funktioniert auch, bringt aber nichts.

[NorbertFe 2.034]

vor 4 Minuten schrieb Vinc211:

\\domain.loc oder \\fileserver.domain.loc

Das Problem ist aber jetzt schon erkennbar welches sich daraus ergibt, oder? ;)

[Weingeist 159]

vor 37 Minuten schrieb Vinc211:

Wir haben einen funktionierenden Workaround etabliert. Die User wissen das wenn das Laufwerk nicht per klick erreichbar ist Sie \\domain.loc oder \\fileserver.domain.loc eingeben können um die Daten zu erreichen. Manche haben sich da als Network share bereits eingerichtet. Aber das ist ja nicht Ziel oder Sinn des ganzen.

Wie gesagt, erstelle ein Script unter C:\Scripts oder so welches das was per GPO ankommt neu macht. Sprich Netzlaufwerk trennen + wieder neu verbinden. Oder auch unter dem Netlogon-Share. Wenn etwas falsches zwischengespeichert ist, bekommst ein Netzlaufwerk selten wieder einfach so geradegebogen. Zumal immer noch die Frage ist, ob es nur neu erstellt wird per GPO wenn nicht bereits vorhanden (auch wenn falsch) oder komplett ersetzt wird. Wird es nicht ersetzt, dann gibt genau der eigene Work-Around nachher probleme wenn sie einen spezifischen Fileserver angeben jedoch nicht immer der gleiche verfügbar ist.

--> Daher mache ich das normal per Script (auch wenn per GPO ausgelöst oder Startup), dann bin ich sicher das es getrennt und neu verbunden wird und so mancher Ärger erspart wird.

bearbeitet 18. Juni 2021 von Weingeist

[Vinc211 1]

vor 1 Stunde schrieb NorbertFe:

Das Problem ist aber jetzt schon erkennbar welches sich daraus ergibt, oder? ;)

 

nein. ich sehe das problem mit den freigaben nicht.

[NorbertFe 2.034]

Dann ist ja gut. Der Zweck von dfs besteht für mich üblicherweise in der Servernamenunabhängigkeit. Wenn die User sich daran aber gewöhnen, daran links anlegen usw. usf., Rate mal was dann beim nächsten serverwechsel passieren wird ;)

[Vinc211 1]

Gerade eben schrieb NorbertFe:

Dann ist ja gut. Der Zweck von dfs besteht für mich üblicherweise in der Servernamenunabhängigkeit. Wenn die User sich daran aber gewöhnen, daran links anlegen usw. usf., Rate mal was dann beim nächsten serverwechsel passieren wird ;)

 

Der user Kreis der den Workaround nutzt ist relativ klein.

Wenn das DFS Probleme macht muss man ja irgendwas bereitstellen damit die Leute an ihre Daten kommen. Oder möchtest du sagen das die Freigaben ein Teil des Problems sein können?

 

vor 1 Stunde schrieb Weingeist:

Wie gesagt, erstelle ein Script unter C:\Scripts oder so welches das was per GPO ankommt neu macht. Sprich Netzlaufwerk trennen + wieder neu verbinden. Oder auch unter dem Netlogon-Share. Wenn etwas falsches zwischengespeichert ist, bekommst ein Netzlaufwerk selten wieder einfach so geradegebogen. Zumal immer noch die Frage ist, ob es nur neu erstellt wird per GPO wenn nicht bereits vorhanden (auch wenn falsch) oder komplett ersetzt wird. Wird es nicht ersetzt, dann gibt genau der eigene Work-Around nachher probleme wenn sie einen spezifischen Fileserver angeben jedoch nicht immer der gleiche verfügbar ist.

--> Daher mache ich das normal per Script (auch wenn per GPO ausgelöst oder Startup), dann bin ich sicher das es getrennt und neu verbunden wird und so mancher Ärger erspart wird.

 

Ich werde es das nächste mal ausprobieren, aber es löst das Problem nicht.

Der VPN wird erst nach dem Start von Windows gestartet, also werden Startup-skripte von NETLOGON oder GPO's nicht ausgeführt.

Alle Server sind dauerhaft verfügbar.

[Weingeist 159]

vor 17 Minuten schrieb Vinc211:

Ich werde es das nächste mal ausprobieren, aber es löst das Problem nicht.

Der VPN wird erst nach dem Start von Windows gestartet, also werden Startup-skripte von NETLOGON oder GPO's nicht ausgeführt.

Alle Server sind dauerhaft verfügbar.

Aber der Benutzer macht nur nen Doppelklick auf dem Desktop und es läuft wieder, Du kriegst weniger Telefonate und vor allem: Es wird so neu verbunden wie es eigentlich sollte, via DSF und nicht direkt via Serverfreigabe. Wie gesagt, Netzlaufwerke sind Diven, die werden quasi nicht einfach so aktualisiert. Die sollte man immer trennen und neu verbinden. Zum Beispiel beim anmelden. Die GPO soll auch trennen und neu verbinden und nicht einfach nur schauen ob da und wenn nicht, neu verbinden (ich wiederhole mich).

 

Oder VPN-verbinden im gleichen Script wie Trennen/verbinden, oder auf nen Trigger mit nem Task wenn Verbindung steht. Deren Möglichkeiten gibt es viele. Ich mag die 0815 Variante, User hat auf Desktop nen Link zum Script der ihm das Laufwerk auf Wunsch neu verbindet. Simpel und Effizient.