20
Netzlaufwerke Persistent wegen VPN
Guten Morgen zusammen,
wir verwenden in unserer Win 2008 R2-Domäne Logonscripte für die Zuweisung von Netzlaufwerken, ganz klassisch nach dieser Art:
Wir haben verschiedene Scripte, da wir an verschiedenen Standorten Server haben und abhängig vom regelmäßigen Standort wird das jeweilige Script dem Benutzer als Anmeldescript eingetragen. Darüber hinaus gibt es dann aus verschiedenen Gründen noch Unterscheidungen, so dass es insgesamt 25 verschiedene Scripte gibt.
Wir eine außerdem eine VPN-Lösung die ebenfalls Anmeldescripte aufrufen kann, jedoch nur sehr aufwendig je Benutzer, so dass wir das pauschalisieren müssen.
Meine Idee wäre nun, dass wir die Netzlaufwerke persistent machen, so dass die gemappten Laufwerke auch bei VPN-Verbindung ohne Anmeldescript zur Verfügung stehen. Damit etwaige Änderungen an den Laufwerken auch immer ziehen, würde ich das folgendermaßen realisieren:
So wäre gewährleistet, dass die Netzlaufwerke auch offline bestehen (natürlich dann getrennt) und bei VPN-Verbindung aufrufbar sind. Dennoch werden die Laufwerke im Firmennetzwerk jedesmal getrennt und neu gemappt, so dass Änderungen an bestehenden Laufwerksbuchstaben auch ziehen.
Spricht irgendetwas gegen diese Vorgehensweise?
wir verwenden in unserer Win 2008 R2-Domäne Logonscripte für die Zuweisung von Netzlaufwerken, ganz klassisch nach dieser Art:
net use s: \\server\share /persistent:noWir haben verschiedene Scripte, da wir an verschiedenen Standorten Server haben und abhängig vom regelmäßigen Standort wird das jeweilige Script dem Benutzer als Anmeldescript eingetragen. Darüber hinaus gibt es dann aus verschiedenen Gründen noch Unterscheidungen, so dass es insgesamt 25 verschiedene Scripte gibt.
Wir eine außerdem eine VPN-Lösung die ebenfalls Anmeldescripte aufrufen kann, jedoch nur sehr aufwendig je Benutzer, so dass wir das pauschalisieren müssen.
Meine Idee wäre nun, dass wir die Netzlaufwerke persistent machen, so dass die gemappten Laufwerke auch bei VPN-Verbindung ohne Anmeldescript zur Verfügung stehen. Damit etwaige Änderungen an den Laufwerken auch immer ziehen, würde ich das folgendermaßen realisieren:
net use s: /delete
net use u: /delete
net use z: /delete
net use s: \\server\share1 /persistent:yes /yes
net use u: \\server\share2 /persistent:yes /yes
net use z: \\server\share3 /persistent:yes /yesSo wäre gewährleistet, dass die Netzlaufwerke auch offline bestehen (natürlich dann getrennt) und bei VPN-Verbindung aufrufbar sind. Dennoch werden die Laufwerke im Firmennetzwerk jedesmal getrennt und neu gemappt, so dass Änderungen an bestehenden Laufwerksbuchstaben auch ziehen.
Spricht irgendetwas gegen diese Vorgehensweise?
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 311107
Url: https://administrator.de/forum/netzlaufwerke-persistent-wegen-vpn-311107.html
Ausgedruckt am: 06.04.2025 um 10:04 Uhr
20 Kommentare
Neuester Kommentar
Moin,
Das wird vermutlich nicht klappen.
Meldet der User sich ohne VPN-Verbindung an, so werden ihm zunächst alle Laufwerke getrennt.
Ein erfolgreiches Wiederverbinden der Laufwerke klappt dann aber nur, wenn die Ziele auch erreichbar sind (der Tunnel aufgebaut) ist.
Welche VPN-Lösung ist es denn und warum ist es aufwändig?
Kannst du nicht lokal auf den Devices ein script hinterlegen, welches bei erfolgreichem Aufbau der Verbindung dann ein script auf eurer Infrastruktur aufruft? von hier kannst du dann ja wieder zentralisiert arbeiten.
Gruß
em-pie
Zitat von @JoeDevlin:
Meine Idee wäre nun, dass wir die Netzlaufwerke persistent machen, so dass die gemappten Laufwerke auch bei VPN-Verbindung ohne Anmeldescript zur Verfügung stehen. Damit etwaige Änderungen an den Laufwerken auch immer ziehen, würde ich das folgendermaßen realisieren:
Meine Idee wäre nun, dass wir die Netzlaufwerke persistent machen, so dass die gemappten Laufwerke auch bei VPN-Verbindung ohne Anmeldescript zur Verfügung stehen. Damit etwaige Änderungen an den Laufwerken auch immer ziehen, würde ich das folgendermaßen realisieren:
> net use s: /delete
> net use u: /delete
> net use z: /delete
>
> net use s: \\server\share1 /persistent:yes /yes
> net use u: \\server\share2 /persistent:yes /yes
> net use z: \\server\share3 /persistent:yes /yes
> Das wird vermutlich nicht klappen.
Meldet der User sich ohne VPN-Verbindung an, so werden ihm zunächst alle Laufwerke getrennt.
Ein erfolgreiches Wiederverbinden der Laufwerke klappt dann aber nur, wenn die Ziele auch erreichbar sind (der Tunnel aufgebaut) ist.
Wir eine außerdem eine VPN-Lösung die ebenfalls Anmeldescripte aufrufen kann, jedoch nur sehr aufwendig je Benutzer, so dass wir das pauschalisieren müssen.
Welche VPN-Lösung ist es denn und warum ist es aufwändig?
Kannst du nicht lokal auf den Devices ein script hinterlegen, welches bei erfolgreichem Aufbau der Verbindung dann ein script auf eurer Infrastruktur aufruft? von hier kannst du dann ja wieder zentralisiert arbeiten.
Gruß
em-pie
Hallo,
Standort zu Standort oder macht jeder Client seine eigene VPN Trasse auf?
Gruß,
Peter
Standort zu Standort oder macht jeder Client seine eigene VPN Trasse auf?
So wäre gewährleistet, dass die Netzlaufwerke auch offline bestehen
Nein. Wird nichts. Wenn die VPN Tunnel nicht stehen und somit keinen Zugriff zu den freigaben - wird das nichts, ausser du nutzt tatsächlich Offline Files, aber das ist etwas anderes.Spricht irgendetwas gegen diese Vorgehensweise?
geht halt nicht. Du kannst kein laufwerksmapping auf Laufwerkje machen die nicht existieren. Warum sind die serverfreigaben nicht erreichbar? Du sagtest du machst VPN. Oder wird das VPN nur bei berdarf aufgebaut? Cölient zu Server VPN oder doch Standort zu Standort VPN? Wenn Standort zu Standort - warum steht der Tunnel nicht 24/7? Erspart dir dein gefrickel.Gruß,
Peter
ich würde sagen du richtest das per GPPs ein. Das geht über die Zielgruppenadressierung auch je nach Standort (Oder gleich DFS Namespaces einrichten).
Die bleiben auch ohne die VPN gecached und versuchen somit beim anmelden die Laufwerke zu verbinden.
Die bleiben auch ohne die VPN gecached und versuchen somit beim anmelden die Laufwerke zu verbinden.
Zitat von @em-pie:
Das wird vermutlich nicht klappen.
Meldet der User sich ohne VPN-Verbindung an, so werden ihm zunächst alle Laufwerke getrennt.
Ein erfolgreiches Wiederverbinden der Laufwerke klappt dann aber nur, wenn die Ziele auch erreichbar sind (der Tunnel aufgebaut) ist.
Das wird vermutlich nicht klappen.
Meldet der User sich ohne VPN-Verbindung an, so werden ihm zunächst alle Laufwerke getrennt.
Ein erfolgreiches Wiederverbinden der Laufwerke klappt dann aber nur, wenn die Ziele auch erreichbar sind (der Tunnel aufgebaut) ist.
Aber ohne VPN-Verbindung wird das Script ja nicht gestartet, d.h. eine Trennung über "/delete" findet nur statt, wenn das Script auch erreichbar ist.
Welche VPN-Lösung ist es denn und warum ist es aufwändig?
Wir setzen eine Juniper SSL-VPN-Lösung ein und müssten nun für alle 25 Möglichkeiten eigene Rollen anlegen und die dann auch weiter pflegen, wenn ein Benutzer ein anderes Anmeldescript erhält.
Kannst du nicht lokal auf den Devices ein script hinterlegen, welches bei erfolgreichem Aufbau der Verbindung dann ein script auf eurer Infrastruktur aufruft? von hier kannst du dann ja wieder zentralisiert arbeiten.
Gleiches Problem, ich kann ja nicht pauschal ein Anmeldescript hinterlegen, dann müsste ich bei jedem das passende hinterlegen und das dann auch immer mitändern.
Hallo,
Und die kann kein Standort zu Standort VPN? Damit erledigt sich dein Problem von alleine.
Gruß,
Peter
Und die kann kein Standort zu Standort VPN? Damit erledigt sich dein Problem von alleine.
Gruß,
Peter
Zitat von @SeaStorm:
ich würde sagen du richtest das per GPPs ein. Das geht über die Zielgruppenadressierung auch je nach Standort (Oder gleich DFS Namespaces einrichten).
Die bleiben auch ohne die VPN gecached und versuchen somit beim anmelden die Laufwerke zu verbinden.
ich würde sagen du richtest das per GPPs ein. Das geht über die Zielgruppenadressierung auch je nach Standort (Oder gleich DFS Namespaces einrichten).
Die bleiben auch ohne die VPN gecached und versuchen somit beim anmelden die Laufwerke zu verbinden.
Je nach Standort benötige ich das nicht, aber per GPO/GPP hätte natürlich den Vorteil, dass auch VPN-Benutzer die selten/nie im Firmennetzwerk vor Ort sind Änderungen mitbekommen.
Zitat von @Pjordorf:
Und die kann kein Standort zu Standort VPN? Damit erledigt sich dein Problem von alleine.
Und die kann kein Standort zu Standort VPN? Damit erledigt sich dein Problem von alleine.
Und dann bekommt jeder der 80 VPN-User einen VPN-Router der möglichst über LTE und batteriebetrieben eine VPN-Verbindung aufbaut? Dazu der kostennachteil im Ausland mit der deutschen SIM-Karte, wo doch das Hotel-WLAN kostenfreien Zugang bietet. Ich glaube ich belasse es bei den Firmenstandorten bei Site-to-Site.
Zitat von @JoeDevlin:
Gleiches Problem, ich kann ja nicht pauschal ein Anmeldescript hinterlegen, dann müsste ich bei jedem das passende hinterlegen und das dann auch immer mitändern.
Kannst du nicht lokal auf den Devices ein script hinterlegen, welches bei erfolgreichem Aufbau der Verbindung dann ein script auf eurer Infrastruktur aufruft? von hier kannst du dann ja wieder zentralisiert arbeiten.
Gleiches Problem, ich kann ja nicht pauschal ein Anmeldescript hinterlegen, dann müsste ich bei jedem das passende hinterlegen und das dann auch immer mitändern.
Hast mich, denke ich, falsch verstanden.
Auf dem Laptop/ PC legst du lokal eine immer gleichlautende batchfile (z.B. C:\CUSTOM\start_after_vpn.bat) ab, welche sinngemäß folgendes beinhaltet:
run \\mein-Server\share\logon.scriptund deine logon.script sähe dann wie folgt aus:
if User in Group1 then
goto Routine a
if User in Group2 then
goto Routine b
usw.Und Routine a, Routine b, etc. sind deine jetzigen Scripte.
Bzw. würde ich dynamisch immer nur Variablen setzen/ anpassen um dann im eigentlichen Script die Variablen entsprechend einzusetzen...
Bei Änderungen musst du dann nur noch das Script logon.script am Firmenstandort zentral anpassen
Zitat von @em-pie:
und deine logon.script sähe dann wie folgt aus:
und deine logon.script sähe dann wie folgt aus:
if User in Group1 then
> goto Routine a
> if User in Group2 then
> goto Routine b
> usw.
> Alles klar, jetzt weiß ich was Du meinst. Allerdings müsste ich dann wohl mit VBS über LDAP Gruppenmitgliedschaften abfragen, oder gibt's einen anderen weg?
über whoami /groups würdest du die Gruppen bekommen und müsstest dann noch die interessante aus der Rückgabe parsen.
Aber das ist doch alles total banane ... riesen Aufwand und Fehleranfällig ohne Ende ... für nix.
Verbinde die Laufwerke per GPPs. Dann bleiben die erst mal wo sie sind, weil persistent. Sämtliche Änderungen holt sich der Client dann beim nächsten Kontakt mit dem DC. Mach evtl. ein gpupdate beim verbinden der VPN um Sicher zu sein.
Aber so ... Scripts auf den Clients ablegen und pflegen? Da wird man ja bescheuert bei ...
Aber das ist doch alles total banane ... riesen Aufwand und Fehleranfällig ohne Ende ... für nix.
Verbinde die Laufwerke per GPPs. Dann bleiben die erst mal wo sie sind, weil persistent. Sämtliche Änderungen holt sich der Client dann beim nächsten Kontakt mit dem DC. Mach evtl. ein gpupdate beim verbinden der VPN um Sicher zu sein.
Aber so ... Scripts auf den Clients ablegen und pflegen? Da wird man ja bescheuert bei ...
Das ginge mit vbs oder der PowerShell.
Wenn du weiterhin auf Userebene arbeiten möchtest (was den Aufwand bei neuen/ entlassenden Usern erhöht), kannst du auch direkt mit nativen CMD-Kommandos ala
arbeiten
Um mit AD-Gruppen zu arbeiten, könnte dir der folgende Link helfen:
https://community.spiceworks.com/scripts/show/379-map-network-drive-if-u ...
In dem Link wird genau das erfüllt, was du haben möchtest, nämlich gruppenbezogen Laufwerke gemapped
Wenn du weiterhin auf Userebene arbeiten möchtest (was den Aufwand bei neuen/ entlassenden Usern erhöht), kannst du auch direkt mit nativen CMD-Kommandos ala
if %username%==mmustermann goto Routine1
if %username%==bmusterfrau goto Routine2
if %username%==lmueller goto Routine3
:Routine1
net use S: \\Server\Share1
goto End
:Routine2
net use S: \\Server\Share2
goto End
:Routine3
net use S: \\Server\Share3
goto End
:End
exitUm mit AD-Gruppen zu arbeiten, könnte dir der folgende Link helfen:
https://community.spiceworks.com/scripts/show/379-map-network-drive-if-u ...
In dem Link wird genau das erfüllt, was du haben möchtest, nämlich gruppenbezogen Laufwerke gemapped
Das ginge auch.
Nach dem Aufbau des VPN-Tunnels lediglich ein gpupdate durchführen.
Nach dem Aufbau des VPN-Tunnels lediglich ein gpupdate durchführen.
Aber so ... Scripts auf den Clients ablegen und pflegen? Da wird man ja bescheuert bei ...
eigentlich müsste das Script nur an einer Stelle gepflegt werden: Undzwar am zentralen Firmenstandort. Es darf dann nur nie verschoben werden, da sonst der Client das script nicht mehr finden würde....
Grundsätzlich ist mir die GPP-Lösung sympathischer und vor allem auch für meine Kollegen transparenter, die anderen Lösungen werden funktionieren, sind aber fehleranfälliger.
Das einzige Problem bei der GPP-Lösung sind meine VPN-User, die nie vor Ort im Firmennetzwerk sind. Ich blicke immer noch nicht genau durch wann die Gruppenmitgliedschaften eines AD-Benutzers aktualisiert werden, wenn das Aktualisieren nicht beim Login möglich ist (VPN ist da ja noch nicht aufgebaut). Die Gruppenmitgliedschaft ist für mich das Kriterium bei der Zielgruppenadressierung auf Elementebene.
Das einzige Problem bei der GPP-Lösung sind meine VPN-User, die nie vor Ort im Firmennetzwerk sind. Ich blicke immer noch nicht genau durch wann die Gruppenmitgliedschaften eines AD-Benutzers aktualisiert werden, wenn das Aktualisieren nicht beim Login möglich ist (VPN ist da ja noch nicht aufgebaut). Die Gruppenmitgliedschaft ist für mich das Kriterium bei der Zielgruppenadressierung auf Elementebene.
wenn sie eine VPN haben, sind sie doch "mit dem Firmennetz" verbunden. Sofern sie mit der VPN auch Zugang zu einem DC haben, ist alles gut.
Und ohne VPN ist es eh egal, weil sie ohne VPN ja auch keine Netzlaufwerke haben.
Verstehe das Problem nicht...
GPO/GPP wird per Default alle 90 Minuten aktualisiert, sofern der Kontakt zum DC steht.
Damit kommen auch die Gruppenmitgliedschaften usw.
Und ohne VPN ist es eh egal, weil sie ohne VPN ja auch keine Netzlaufwerke haben.
Verstehe das Problem nicht...
GPO/GPP wird per Default alle 90 Minuten aktualisiert, sofern der Kontakt zum DC steht.
Damit kommen auch die Gruppenmitgliedschaften usw.
Zitat von @SeaStorm:
wenn sie eine VPN haben, sind sie doch "mit dem Firmennetz" verbunden. Sofern sie mit der VPN auch Zugang zu einem DC haben, ist alles gut.
Und ohne VPN ist es eh egal, weil sie ohne VPN ja auch keine Netzlaufwerke haben.
Verstehe das Problem nicht...
GPO/GPP wird per Default alle 90 Minuten aktualisiert, sofern der Kontakt zum DC steht.
Damit kommen auch die Gruppenmitgliedschaften usw.
wenn sie eine VPN haben, sind sie doch "mit dem Firmennetz" verbunden. Sofern sie mit der VPN auch Zugang zu einem DC haben, ist alles gut.
Und ohne VPN ist es eh egal, weil sie ohne VPN ja auch keine Netzlaufwerke haben.
Verstehe das Problem nicht...
GPO/GPP wird per Default alle 90 Minuten aktualisiert, sofern der Kontakt zum DC steht.
Damit kommen auch die Gruppenmitgliedschaften usw.
Nein, zum Zeitpunkt des Logins bin ich nicht mit dem Firmenetzwerk verbunden, somit melde ich mich mit den zwischengespeicherten Anmeldedaten an. Beim anschließenden Aufbau der VPN-Verbindung lasse ich ein Logonscript u.a. mit gpupdate laufen, dabei werden aber die Gruppenmitgliedschaften NICHT aktualisiert. Demzufolge funktionieren gruppenbasierte GPOs auch nicht. Es gibt verschiedene Workarounds mit "klist /purge" aber das ist nicht ideal und soll auch zu Problemen führen.
Hallo,
Es gibt aber auch VPNs welche sich noch vor der Benutzeranmeldung etablieren...
Gruß,
Peter
Es gibt aber auch VPNs welche sich noch vor der Benutzeranmeldung etablieren...
Gruß,
Peter
Das stimmt, leider ist das mit unserem noch nicht möglich. DirectAccess wäre perspektivisch auch noch eine Alternative, allerdings müssten wir dann auf Windows 7 bzw. Windows 10 Enterprise umsteigen.
Hallo,
Gruß,
Peter
Zitat von @JoeDevlin:
allerdings müssten wir dann auf Windows 7 bzw. Windows 10 Enterprise umsteigen.
Bedeutet dies im umkehrschluss das ihr noch XP/Vista auf den Mobilen Arbeitsplätzen nutzt? Denn wenn du erwägst GPP einzusetzen dann ist XP das minimum und wenn du jetzt sagst das wenn du DirectAccess nutzen wolltest du mindestens auf Windows 7 gehen müsstest.... Langsam kommt Licht in deine Abneigung gegenüber jede vorgeschlagene Lösung... allerdings müssten wir dann auf Windows 7 bzw. Windows 10 Enterprise umsteigen.
Gruß,
Peter
(und DA unter Win7 einzurichten macht gar keinen Spass...)
Zitat von @Pjordorf:
allerdings müssten wir dann auf Windows 7 bzw. Windows 10 Enterprise umsteigen.
Bedeutet dies im umkehrschluss das ihr noch XP/Vista auf den Mobilen Arbeitsplätzen nutzt? Denn wenn du erwägst GPP einzusetzen dann ist XP das minimum und wenn du jetzt sagst das wenn du DirectAccess nutzen wolltest du mindestens auf Windows 7 gehen müsstest.... Langsam kommt Licht in deine Abneigung gegenüber jede vorgeschlagene Lösung... Nein, wir setzen Windows 7 Professional ein, eine Migration auf Windows 10 Professional ist in Planung.
Meine GPP-Abneigung basiert lediglich auf der VPN-Problematik, ich werde dazu einfach mal Tests durchführen und gucken, wie die Zielgruppenadressierung auf Elementebene funktioniert, wenn der Benutzer nur per VPN arbeitet und sich die Gruppenmitgliedschaften ändern.
