13
Automatisches verbinden NW-Laufwerke
Moin Leute,
folgendes, ich hab ein Problem mit mehreren Client Geräten, wo eine SSD verbaut ist.
Wenn die Geräte starten, dann ist scheinbar das Netzwerk zu langsam um die Laufwerke zu verbinden. (nicht immer bei 2 von 10x funktioniert es nach einem Neustart)
Lösung (dachte ich):
GPO im AD erstellen: Auf Netzwerk bei Start warten.
Hat leider nicht gefruchtet, GPO wurde vom Client sauber übernommen, via gpresult abgefragt, kein Fehler.
Nun ein Startskript erstellt:
Skript funktioniert, aber wieder nicht bei den Client Geräten..... wurde im AD als Startskript hinterlegt, wenn ich es bei mir teste funktioniert es, aber bei den Clients nicht...
Sind Lenovo Geräte, i5 12th, Intel Netzwerkkarte , 16gb ddr4 , 512gb ssd, aber bei anderen identen Geräten funktioniert es, Win11 auf aktuellen Stand, und im internen Netzwerk, also keine VPN dazwischen, sowie auch kein Citrix.... User hab ich bereits neu angelegt, hat in dem Fall nichts gebracht, wenn sich der User an einem anderen Gerät anmeldet, dann bekommt er die Verbindung, ich hab keinen Plan mehr....
Was hab ich bereits alles versucht:
- Netzwerkkabel getauscht
- Startskript erstellt
- GPO erstellt
- Gerät an einer anderen Netzwerkbuchse verwendet
- User neu erstellt am Gerät
- getestet mit einem anderen Gerät -> funktioniert
- aktuelle Treiber Win11
- aktuelle Intel Treiber von der Intel Seite nicht über WinUpdates
- Treiber runtergeschmissen und neu Installier
- Client Wipe & Neu Aufgesetzt
Jetz hab ich keine Idee mehr... die Verbindung wird hergestellt wenn gpupdate /force ausgeführt wird... ich kann auch den Fehler nicht replizieren, er tritt wie oben bereits erwähnt 8x bei 10 Neustarts auf, also es ist auch kein erkennbares Muster für mich erkennbar...
Jemand irgendeine Idee? Wo könnte ich was übersehen haben? was könnte ich noch versuchen... langsam verzweifle ich
Grüße
folgendes, ich hab ein Problem mit mehreren Client Geräten, wo eine SSD verbaut ist.
Wenn die Geräte starten, dann ist scheinbar das Netzwerk zu langsam um die Laufwerke zu verbinden. (nicht immer bei 2 von 10x funktioniert es nach einem Neustart)
Lösung (dachte ich):
GPO im AD erstellen: Auf Netzwerk bei Start warten.
Hat leider nicht gefruchtet, GPO wurde vom Client sauber übernommen, via gpresult abgefragt, kein Fehler.
Nun ein Startskript erstellt:
@echo off
set /p share=**********
set /p drive=**********
net use %drive%: %share% /persistent:yes
echo Netzwerklaufwerk %drive%: erfolgreich verbunden.
pauseSkript funktioniert, aber wieder nicht bei den Client Geräten..... wurde im AD als Startskript hinterlegt, wenn ich es bei mir teste funktioniert es, aber bei den Clients nicht...
Sind Lenovo Geräte, i5 12th, Intel Netzwerkkarte , 16gb ddr4 , 512gb ssd, aber bei anderen identen Geräten funktioniert es, Win11 auf aktuellen Stand, und im internen Netzwerk, also keine VPN dazwischen, sowie auch kein Citrix.... User hab ich bereits neu angelegt, hat in dem Fall nichts gebracht, wenn sich der User an einem anderen Gerät anmeldet, dann bekommt er die Verbindung, ich hab keinen Plan mehr....
Was hab ich bereits alles versucht:
- Netzwerkkabel getauscht
- Startskript erstellt
- GPO erstellt
- Gerät an einer anderen Netzwerkbuchse verwendet
- User neu erstellt am Gerät
- getestet mit einem anderen Gerät -> funktioniert
- aktuelle Treiber Win11
- aktuelle Intel Treiber von der Intel Seite nicht über WinUpdates
- Treiber runtergeschmissen und neu Installier
- Client Wipe & Neu Aufgesetzt
Jetz hab ich keine Idee mehr... die Verbindung wird hergestellt wenn gpupdate /force ausgeführt wird... ich kann auch den Fehler nicht replizieren, er tritt wie oben bereits erwähnt 8x bei 10 Neustarts auf, also es ist auch kein erkennbares Muster für mich erkennbar...
Jemand irgendeine Idee? Wo könnte ich was übersehen haben? was könnte ich noch versuchen... langsam verzweifle ich
Grüße
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 6998363035
Url: https://administrator.de/contentid/6998363035
Ausgedruckt am: 25.11.2024 um 09:11 Uhr
13 Kommentare
Neuester Kommentar
Hi,
Netzlaufwerke via GPP (Aktion: Aktualisieren) funktionieren bei uns zuverlässig, egal wie schnell der Rechner ist.
-Thomas
Netzlaufwerke via GPP (Aktion: Aktualisieren) funktionieren bei uns zuverlässig, egal wie schnell der Rechner ist.
die Verbindung wird hergestellt wenn gpupdate /force ausgeführt wird.
Als Notlösung gpupdate als scheduled task bei logon?-Thomas
2
Zitat von @3063370895:
die Verbindung wird hergestellt wenn gpupdate /force ausgeführt wird.
Als Notlösung gpupdate als scheduled task bei logon?-Thomas
wäre mein Notnagel, aber da blockiert der Client 2 - 3 Minuten bei der GPO Übernahme
ich würde wie hier beschrieben das erweiterte Logging anschalten und dort in den Logs dann schauen.
Auf jeden Fall würde ich von Netzlaufwerken per Startskript absehen und nur per GPP verteilen.
-Thomas
Auf jeden Fall würde ich von Netzlaufwerken per Startskript absehen und nur per GPP verteilen.
-Thomas
Hi,
E.
Skript funktioniert, aber wieder nicht bei den Client Geräten..... wurde im AD als Startskript hinterlegt, wenn ich es bei mir teste funktioniert es, aber bei den Clients nicht...
Netzlaufwerke sind i.A. für Benutzer. Also nicht als Start-Script (Computerkonfiguration) sondern als Login-Script (Benutzerkonfiguration) ausführen lassen. Die GPO muss dann für die Benutzer gelten und nicht für die Clients.E.
3
Moin.
Versuchs mal hiermit:
Cheers,
jsysde
Versuchs mal hiermit:
Cheers,
jsysde
Hi,
würde da ansetzen:
Prüf mal, ob die Clients an der LSA authen oder am DC. Kannst Du, indem Du zwischengespeicherte Logons deaktivierst und die GPO anwendest. Computerkonfiguration => Richtlinien => Sicherheitseinstellungen => Lokale Richtlinien => Sicherheitsoptionen => Interaktive Anmeldung: Anzahl zwischenzuspeichernder vorheriger Anmeldungen auf 0 setzen und auf einen von den Problemrechnern anwenden.
Damit ist gesichert, daß Anmeldung mit Domänenaccount nur geht, wenn DC erreichbar.
würde da ansetzen:
- Timingproblem beim Netzwerkstack (Benutzer melden an, während Netzwerkstack lädt - hatte sowas schon bei Rechnern mit Wifi-Adapter) ==> ändert sich verhalten, wenn die Kiste angeschaltet wird und vor der Anmeldung erstmal 30, 40 Sekunden in Ruhe gelassen wird?
- Adresszuweisung (DHCP regiert zu langsam)
- Namensauflösung (welche DNS-Server konfiguriert, nur DCs oder zusätzliche?)
Prüf mal, ob die Clients an der LSA authen oder am DC. Kannst Du, indem Du zwischengespeicherte Logons deaktivierst und die GPO anwendest. Computerkonfiguration => Richtlinien => Sicherheitseinstellungen => Lokale Richtlinien => Sicherheitsoptionen => Interaktive Anmeldung: Anzahl zwischenzuspeichernder vorheriger Anmeldungen auf 0 setzen und auf einen von den Problemrechnern anwenden.
Damit ist gesichert, daß Anmeldung mit Domänenaccount nur geht, wenn DC erreichbar.
Computereinstellungen \ Administrative Vorlagen \ System \ Gruppenrichtlinie \ Wartezeit für Richtlinienverarbeitung beim Systemstart
1
Moin,
Wenn der Client im OS steht, und der User angemeldet ist werden die Pfade erst nach einem gpupdate /force im Explorer verbunden, auch ein Warten hat nichts gebracht.
Mein Fehler, die Geräte bei uns sind über die MAC am DHCP reserviert mit einer fixen IP
Wir haben nur die des DC´s hinterlegt, tendierst du in die Richtung dass die Namensauflösung hier ggf. ein Problem darstellen kann?
Prüf mal, ob die Clients an der LSA authen oder am DC. Kannst Du, indem Du zwischengespeicherte Logons deaktivierst und die GPO anwendest. Computerkonfiguration => Richtlinien => Sicherheitseinstellungen => Lokale Richtlinien => Sicherheitsoptionen => Interaktive Anmeldung: Anzahl zwischenzuspeichernder vorheriger Anmeldungen auf 0 setzen und auf einen von den Problemrechnern anwenden.
Damit ist gesichert, daß Anmeldung mit Domänenaccount nur geht, wenn DC erreichbar.
Danke für den Tipp, werd ich gleich umsetzen.
Grüße
Zitat von @tgvoelker:
Hi,
würde da ansetzen:
Hi,
würde da ansetzen:
- Timingproblem beim Netzwerkstack (Benutzer melden an, während Netzwerkstack lädt - hatte sowas schon bei Rechnern mit Wifi-Adapter) ==> ändert sich verhalten, wenn die Kiste angeschaltet wird und vor der Anmeldung erstmal 30, 40 Sekunden in Ruhe gelassen wird?
Wenn der Client im OS steht, und der User angemeldet ist werden die Pfade erst nach einem gpupdate /force im Explorer verbunden, auch ein Warten hat nichts gebracht.
* Adresszuweisung (DHCP regiert zu langsam)
Mein Fehler, die Geräte bei uns sind über die MAC am DHCP reserviert mit einer fixen IP
* Namensauflösung (welche DNS-Server konfiguriert, nur DCs oder zusätzliche?)
Wir haben nur die des DC´s hinterlegt, tendierst du in die Richtung dass die Namensauflösung hier ggf. ein Problem darstellen kann?
Prüf mal, ob die Clients an der LSA authen oder am DC. Kannst Du, indem Du zwischengespeicherte Logons deaktivierst und die GPO anwendest. Computerkonfiguration => Richtlinien => Sicherheitseinstellungen => Lokale Richtlinien => Sicherheitsoptionen => Interaktive Anmeldung: Anzahl zwischenzuspeichernder vorheriger Anmeldungen auf 0 setzen und auf einen von den Problemrechnern anwenden.
Damit ist gesichert, daß Anmeldung mit Domänenaccount nur geht, wenn DC erreichbar.
Danke für den Tipp, werd ich gleich umsetzen.
Grüße
Zitat von @kpunkt:
Computereinstellungen \ Administrative Vorlagen \ System \ Gruppenrichtlinie \ Wartezeit für Richtlinienverarbeitung beim Systemstart
Computereinstellungen \ Administrative Vorlagen \ System \ Gruppenrichtlinie \ Wartezeit für Richtlinienverarbeitung beim Systemstart
Dank & Anerkennung
Noch eine Nachfrage: tritt das Verhalten auch auf, wenn Anmeldeskripte im Benutzerkonto angegeben sind? (ADUC, Benutzer, Register Konto. Skripte liegen auf dem DC in NETLOGON. Angabe Dateiname+Erweiterung)
Zitat von @MrHeisenberg:
Mein Fehler, die Geräte bei uns sind über die MAC am DHCP reserviert mit einer fixen IP
Die IP kommt ja trotzdem vom Server, der weist nur immer dieselbe zu.Mein Fehler, die Geräte bei uns sind über die MAC am DHCP reserviert mit einer fixen IP
Wir haben nur die des DC´s hinterlegt, tendierst du in die Richtung dass die Namensauflösung hier ggf. ein Problem darstellen kann?
Ja. Möglich wäre auch, daß alte DCs Artefakte hinterlassen haben. Sofern in den AD-Standorten alte Server drin sind oder im DNS, die Einträge entfernen.Zitat von @tgvoelker:
Noch eine Nachfrage: tritt das Verhalten auch auf, wenn Anmeldeskripte im Benutzerkonto angegeben sind? (ADUC, Benutzer, Register Konto. Skripte liegen auf dem DC in NETLOGON. Angabe Dateiname+Erweiterung)
Wenn ich mich mit dem User an einem anderen Gerät anmelde, dann funktionieren die Scripte bzw. GPO´sNoch eine Nachfrage: tritt das Verhalten auch auf, wenn Anmeldeskripte im Benutzerkonto angegeben sind? (ADUC, Benutzer, Register Konto. Skripte liegen auf dem DC in NETLOGON. Angabe Dateiname+Erweiterung)
Zitat von @MrHeisenberg:
Mein Fehler, die Geräte bei uns sind über die MAC am DHCP reserviert mit einer fixen IP
Die IP kommt ja trotzdem vom Server, der weist nur immer dieselbe zu.Mein Fehler, die Geräte bei uns sind über die MAC am DHCP reserviert mit einer fixen IP
stimmt
Wir haben nur die des DC´s hinterlegt, tendierst du in die Richtung dass die Namensauflösung hier ggf. ein Problem darstellen kann?
Ja. Möglich wäre auch, daß alte DCs Artefakte hinterlassen haben. Sofern in den AD-Standorten alte Server drin sind oder im DNS, die Einträge entfernen.Wir verwenden nur einen DC bzw. einer steht dahinter als Backup, aber in unseren Standort ist nur einer aktiv, unser Backup liegt in einer Außenstelle
Versuch mal im Benutzerkonto in ADUC (NICHT in der GPO) ein Anmeldescript zu machen (damit kannst Du Laufwerke auch verbinden). Werden die immer ausgeführt?
Und schau mal in die AD-Standorte und Dienste, da müßten Subnetze definiert sein und Standorte. Windows wählt den DC anhand der dem Standort zugewiesenen Subnetze. Wenn das nicht richtig konfiguriert ist, dann kann es sein, daß ein DC gewählt wird, der langsam reagiert.
Und schau mal in die AD-Standorte und Dienste, da müßten Subnetze definiert sein und Standorte. Windows wählt den DC anhand der dem Standort zugewiesenen Subnetze. Wenn das nicht richtig konfiguriert ist, dann kann es sein, daß ein DC gewählt wird, der langsam reagiert.
