11
Nicht-Domänen Netzlaufwerk dauerhaft einbinden
Hallöchen zusammen, ich habe folgendes Problem:
Die Rechner bei uns in der Zweigstelle sind seit neuestem über ein VPN Gateway mit dem Hauptstandort verbunden, und melden sich jetzt dort an der Windows Domäne an. Über die Gruppenrichtlinie werden diverse Netzlaufwerke eingebunden, die sich allesamt am Hauptstandort befinden. Es soll jetzt aber EIN weiteres Netzlaufwerk permanent bei den PCs an der Zweigstelle eingebunden werden, das sich auf einem NAS befindet, das auch in der Zweigstelle steht. Das NAS ist also nicht Teil der Domäne, und das soll es auch nicht werden, damit mehr Ausfallsicherheit gegeben ist. Die User in der Zweigstelle arbeiten zu 90% auf dem lokalen NAS.
Bisher war das Netzlaufwerk immer einfach im Windows Explorer eingebunden worden, mit dem Haken gesetzt bei "Verbindung bei Anmeldung wiederherstellen".
Das klappt jetzt nicht mehr, da alle Netzlaufwerke bei der Domänenanmeldung getrennt, und dann nur die Remote-Laufwerke eingebunden werden. Beim Neustart ist es also immer weg und muss manuell neu verbunden werden.
Ich habe schon versucht, mittels Login Batch-Skript über den lokalen Gruppenrichtlinien-Editor das Netzlaufwerk einzubinden, hat aber nicht sauber funktioniert, da erstens das rote X erschien, und der Name des Laufwerkes als "Nichtverbundenes Netzlaufwerk" angezeigt wurde, OBWOHL es verbunden war. Außerdem die Windows Popup Meldung, dass "nicht alle Netzlaufwerke verbunden" seien.
Folgendes Kommando habe ich verwendet:
@echo off
net use M: \\nas\freigabe /user:USER PASSWORD /persistent:yes
Mittels Powershell Kommando New-PSDrive habe ich es auch schon probiert, aber das hat mittels Login Skript gar nicht funktioniert, und scheinbar muss man der Powershell auch umfassende Rechte einräumen damit es überhaupt funktionieren kann.
Das Laufwerk über die Gruppenrichtlinie für alle einbinden kommt nicht in Frage, es soll nur den Usern in der Zweigstelle zur Verfügung stehen.
Weiß jemand einen sauberen und unkomplizierten Weg, wie man ein solches (Dritt-) Netzlaufwerk dauerhaft einbindet?
Die Rechner bei uns in der Zweigstelle sind seit neuestem über ein VPN Gateway mit dem Hauptstandort verbunden, und melden sich jetzt dort an der Windows Domäne an. Über die Gruppenrichtlinie werden diverse Netzlaufwerke eingebunden, die sich allesamt am Hauptstandort befinden. Es soll jetzt aber EIN weiteres Netzlaufwerk permanent bei den PCs an der Zweigstelle eingebunden werden, das sich auf einem NAS befindet, das auch in der Zweigstelle steht. Das NAS ist also nicht Teil der Domäne, und das soll es auch nicht werden, damit mehr Ausfallsicherheit gegeben ist. Die User in der Zweigstelle arbeiten zu 90% auf dem lokalen NAS.
Bisher war das Netzlaufwerk immer einfach im Windows Explorer eingebunden worden, mit dem Haken gesetzt bei "Verbindung bei Anmeldung wiederherstellen".
Das klappt jetzt nicht mehr, da alle Netzlaufwerke bei der Domänenanmeldung getrennt, und dann nur die Remote-Laufwerke eingebunden werden. Beim Neustart ist es also immer weg und muss manuell neu verbunden werden.
Ich habe schon versucht, mittels Login Batch-Skript über den lokalen Gruppenrichtlinien-Editor das Netzlaufwerk einzubinden, hat aber nicht sauber funktioniert, da erstens das rote X erschien, und der Name des Laufwerkes als "Nichtverbundenes Netzlaufwerk" angezeigt wurde, OBWOHL es verbunden war. Außerdem die Windows Popup Meldung, dass "nicht alle Netzlaufwerke verbunden" seien.
Folgendes Kommando habe ich verwendet:
@echo off
net use M: \\nas\freigabe /user:USER PASSWORD /persistent:yes
Mittels Powershell Kommando New-PSDrive habe ich es auch schon probiert, aber das hat mittels Login Skript gar nicht funktioniert, und scheinbar muss man der Powershell auch umfassende Rechte einräumen damit es überhaupt funktionieren kann.
Das Laufwerk über die Gruppenrichtlinie für alle einbinden kommt nicht in Frage, es soll nur den Usern in der Zweigstelle zur Verfügung stehen.
Weiß jemand einen sauberen und unkomplizierten Weg, wie man ein solches (Dritt-) Netzlaufwerk dauerhaft einbindet?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 654437
Url: https://administrator.de/contentid/654437
Printed on: April 19, 2024 at 17:04 o'clock
11 Comments
Latest comment
Moin,
Du schreibst, dass du das Laufwerk über eine lokalen Gruppenrichtlinie eingebunden hast.
Warum machst Du das nicht mit einer GPO/GPP?
Hier könntest Du das Verhalten besser zentral steuern.
Warten auf das Netz aktivieren und schauen was passiert.
Und ein rotes X gehört bei windows zum guten Ton, ärgerlich aber kann schon mal vorkommen.
Grüße
Du schreibst, dass du das Laufwerk über eine lokalen Gruppenrichtlinie eingebunden hast.
Warum machst Du das nicht mit einer GPO/GPP?
Hier könntest Du das Verhalten besser zentral steuern.
Warten auf das Netz aktivieren und schauen was passiert.
Und ein rotes X gehört bei windows zum guten Ton, ärgerlich aber kann schon mal vorkommen.
Grüße
1
In der Zweigstelle einen Read-Only-DC aufstellen, dann mit GPP und Zielgruppenadressierung die Netzlaufwerke verbinden. Die dämliche Warnung kannst du auch per GPP deaktivieren:
https://www.tenforums.com/tutorials/145379-disable-could-not-reconnect-a ...
https://www.tenforums.com/tutorials/145379-disable-could-not-reconnect-a ...
1
Hallo,
ich könnte mir vorstellen, dass deine Variante mit "lokaler Batch" ohne rotes X oder Namensproblem klappt, wenn du mit "persistent:no" verbindest.
Da ja eh alle erstmal getrennt werden, ist "persistent:yes" per se unnötig/nicht möglich. -> Es wird ja eh getrennt.
Ich persönlich verwende "persistent:yes" nie, da ich da immer mal wieder so komische Phänome hatte und das "retten" über nenn Boot nie wirklich sauber funktioniert hat.
MfG IceBeer
ich könnte mir vorstellen, dass deine Variante mit "lokaler Batch" ohne rotes X oder Namensproblem klappt, wenn du mit "persistent:no" verbindest.
Da ja eh alle erstmal getrennt werden, ist "persistent:yes" per se unnötig/nicht möglich. -> Es wird ja eh getrennt.
Ich persönlich verwende "persistent:yes" nie, da ich da immer mal wieder so komische Phänome hatte und das "retten" über nenn Boot nie wirklich sauber funktioniert hat.
MfG IceBeer
1
Danke erstmal! Einen extra Domain-Controller aufstellen ist den Aufwand für die Größe der Zweigstelle nicht wert. Es handelt sich ja im Grunde um eine Kleinigkeit, ein einzelnes Netzlaufwerk, das eingebunden werden muss.
Wenn ich es manuell einbinde, einfach im Explorer nachdem der Login stattgefunden habe,. funktioniert es ja einwandfrei. Muss ich vielleicht eine Verzögerung in das Batch Skript einbauen?
Wenn ich es manuell einbinde, einfach im Explorer nachdem der Login stattgefunden habe,. funktioniert es ja einwandfrei. Muss ich vielleicht eine Verzögerung in das Batch Skript einbauen?
Ich habe nicht mal Zugriff auf den Windows Server und die Gruppenrichtlinien Einstellungen. Es handelt sich lediglich um eine handvoll Rechner, bei denen automatisch nachdem Login ein einzelnes Netzlaufwerk eingebunden werden muss.
Habs ausprobiert, leider keine Änderung. Aber Recht hast da natürlich, persistent:yes ist widersinnig gewesen. Hab einen kleinen timeout 5 noch in die Batch Datei reingeschrieben, hat leider auch nix gebracht...
Irgendwelche anderen Ideen?
Irgendwelche anderen Ideen?
Ich mache es nicht über die GPO da ich den Windows Server gar nicht verwalte, und eben nur lokal auf einigen wenigen Rechnern dieses Netzlaufwerk eingebunden ist. Und leider ist da nicht nur das rote X, sondern es steht auch fett "Nichtverbundenes Netzlaufwerk", was schon doof aussieht. Es ist ja verbunden!
Zitat von @kabratze:
Danke erstmal! Einen extra Domain-Controller aufstellen ist den Aufwand für die Größe der Zweigstelle nicht wert. Es handelt sich ja im Grunde um eine Kleinigkeit, ein einzelnes Netzlaufwerk, das eingebunden werden muss.
Wenn ich es manuell einbinde, einfach im Explorer nachdem der Login stattgefunden habe,. funktioniert es ja einwandfrei. Muss ich vielleicht eine Verzögerung in das Batch Skript einbauen?
Danke erstmal! Einen extra Domain-Controller aufstellen ist den Aufwand für die Größe der Zweigstelle nicht wert. Es handelt sich ja im Grunde um eine Kleinigkeit, ein einzelnes Netzlaufwerk, das eingebunden werden muss.
Wenn ich es manuell einbinde, einfach im Explorer nachdem der Login stattgefunden habe,. funktioniert es ja einwandfrei. Muss ich vielleicht eine Verzögerung in das Batch Skript einbauen?
Warum soll es denn den Aufwand nicht wert sein, wenn eine "hohe" Verfügbarkeit gefordert ist?
Entweder ist eine Hohe Verfügbarkeit wirklich notwendig und es ist den Aufwand wert, oder die hohe Verfügbarkeit wird nicht benötigt und es ist den Aufwand nicht wert. In beiden Fällen landet die NAS in der Domäne.
Aus diesem Grund die NAS nicht in die Domäne zu nehmen, ist zumindest unsinnig. Und sicherheitstechnisch ist es definitiv auch kein Zugewinn, insbesondere dann nicht, wenn man laienhaft Passwörter im Skript hinterlegt sind...
Ich habe nicht mal Zugriff auf den Windows Server und die Gruppenrichtlinien Einstellungen. Es handelt sich lediglich um eine handvoll Rechner, bei denen automatisch nachdem Login ein einzelnes Netzlaufwerk eingebunden werden muss.
Darf man fragen, ob Du überhaupt Mitglied der IT bist? Nicht böse gemeint, aber alles in allem klingt das schon sehr ungewöhnlich.
Wer verwaltet denn die Windows Server?
Gruß
Alex
Ich verwalte die IT in der Zweigstelle. Bisher waren wir ganz abgekoppelt vom Hauptstandort.
Ich habe inzwischen gemerkt, dass das fehlerhafte Einbinden des Netzlaufwerkes gar nichts mit der Domäne zu tun hat. Das Einbinden per Batchdatei als Logon-Skript verursacht diesen Fehler auch bei PCs, die nicht Teil der Domäne sind.
Mir ist bewusst, dass das Hinterlegen Passwörter im Skript laienhaft ist, aber da´es jetz erst mal laufen muss, habe ich es eben so versucht.
Aber das war ja auch Motivation meiner Frage, ob das nicht besser geht.
Wenn wir das NAS in die Domäne aufnehmen, und das Netzlaufwerk per GPO einbinden, dann ist es ja auch für alle andern User des Hauptstandortes verfügbar, was nicht sein soll. Und wenn das Internet ausfällt, dann können wir ja nichtmal lokal auf unserem NAS arbeiten, da der Domänencontroller nicht erreichbar ist, oder?
Ich habe inzwischen gemerkt, dass das fehlerhafte Einbinden des Netzlaufwerkes gar nichts mit der Domäne zu tun hat. Das Einbinden per Batchdatei als Logon-Skript verursacht diesen Fehler auch bei PCs, die nicht Teil der Domäne sind.
Mir ist bewusst, dass das Hinterlegen Passwörter im Skript laienhaft ist, aber da´es jetz erst mal laufen muss, habe ich es eben so versucht.
Aber das war ja auch Motivation meiner Frage, ob das nicht besser geht.
Wenn wir das NAS in die Domäne aufnehmen, und das Netzlaufwerk per GPO einbinden, dann ist es ja auch für alle andern User des Hauptstandortes verfügbar, was nicht sein soll. Und wenn das Internet ausfällt, dann können wir ja nichtmal lokal auf unserem NAS arbeiten, da der Domänencontroller nicht erreichbar ist, oder?
Zitat von @kabratze:
Ich verwalte die IT in der Zweigstelle. Bisher waren wir ganz abgekoppelt vom Hauptstandort.
Ich habe inzwischen gemerkt, dass das fehlerhafte Einbinden des Netzlaufwerkes gar nichts mit der Domäne zu tun hat. Das Einbinden per Batchdatei als Logon-Skript verursacht diesen Fehler auch bei PCs, die nicht Teil der Domäne sind.
Mir ist bewusst, dass das Hinterlegen Passwörter im Skript laienhaft ist, aber da´es jetz erst mal laufen muss, habe ich es eben so versucht.
Aber das war ja auch Motivation meiner Frage, ob das nicht besser geht.
Ich verwalte die IT in der Zweigstelle. Bisher waren wir ganz abgekoppelt vom Hauptstandort.
Ich habe inzwischen gemerkt, dass das fehlerhafte Einbinden des Netzlaufwerkes gar nichts mit der Domäne zu tun hat. Das Einbinden per Batchdatei als Logon-Skript verursacht diesen Fehler auch bei PCs, die nicht Teil der Domäne sind.
Mir ist bewusst, dass das Hinterlegen Passwörter im Skript laienhaft ist, aber da´es jetz erst mal laufen muss, habe ich es eben so versucht.
Aber das war ja auch Motivation meiner Frage, ob das nicht besser geht.
Okay, dann wäre das schonmal geklärt.
Wenn wir das NAS in die Domäne aufnehmen, und das Netzlaufwerk per GPO einbinden, dann ist es ja auch für alle andern User des Hauptstandortes verfügbar, was nicht sein soll.
Nein, man kann in den GPOs festlegen, dass das Netzlaufwerk nur für Benutzer in bestimmten OUs oder Sicherheitsgruppen eingebunden werden soll. Best Practice ist hier Item-Level-Targeting.
Darüber hinaus kann (und sollte) man in den Dateisystemberechtigungen auf der NAS auch genau festlegen, welche Sicherheitsgruppen Zugriff auf welche Dateien und Ordner haben sollen.
Und wenn das Internet ausfällt, dann können wir ja nichtmal lokal auf unserem NAS arbeiten, da der Domänencontroller nicht erreichbar ist, oder?
Nicht ganz. Kerberos-Tickets überleben i.d.R. bis zu zehn Stunden ohne Aktualisierung. Solange der Ausfall nur ein paar Minuten oder Stunden dauert, sollte man trotzdem noch lokal arbeiten können.
Abhilfe schaffen kann hier auch eine redundante Anbindung.
Was ich auf jeden Fall empfehlen würde, ist die ganze Situation auch mal mit der IT vom Hauptstandort durchzusprechen, und gemeinsam eine Lösung zu finden.
Gruß
Alex
Nein, man kann in den GPOs festlegen, dass das Netzlaufwerk nur für Benutzer in bestimmten OUs oder Sicherheitsgruppen eingebunden werden soll. Best Practice ist hier Item-Level-Targeting.
Das hatte ich dem Admin auch vorgeschlagen, aber er will die Rechte-Verwaltung so einfach und schlank wie möglich halten (für alle gleich), was ich auch verstehen kann. Und da es wirklich nur um die Einbindung eines einzelnen, weiteren lokalen Netzlaufwerkes in der Zweigstelle geht, dachten wir halt, es müsste auch so gehen.Ist es denn möglich, nicht immer alle Netzlaufwerke bei der Domänenanmeldung zu trennen und neu zu verbinden (was ja "unseres" rausschmeisst), sondern nur ab einem bestimmten Buchstaben? Und wenn unsere Freigabe einfach einen Laufwerksbuchstaben "davor" hat, bleibt es erhalten?
