10
Netzwerk-Home (AD-Basisverzeichnis) zweier User frühmorgens nicht verbunden
Hallo.
- Microsoft-Windows-Active-Directory-Domäne firma.local
- Domänenfunktionsebene 2016
- 2 DCs, 1 x physisch, 1x virtuell, beide W2K16, aktuell gepatcht
- Fileserver Windows 2012 R2, virtuell, aktuell gepatcht
- Windows-10-Pro-x64-Clients, Buildversion 21H2, alle aktuell gepatcht
Das Userhome im Netzwerk verbinden wir bei allen Usern per Basisverzeichniseintrag in den AD-Eigenschaften der User, bei uns per Laufwerk H: \\Fileserver\homes$\<username>. Sonstige Netzlaufwerke per Logon-Skript.
Bei zwei Usern passiert seit circa 6-8 Wochen jeden Tag frühmorgens bei der ersten Windows-Anmeldung des Tages an ihren Bürorechnern das Gleiche: Laufwerk H: ist nicht verbunden. Das passiert nur bei diesen beiden, bei allen anderen (circa 25-30 Leute) nicht. Die beiden bemerken das auch sofort, weil der Desktop nahezu leer ist (weil er nach H:\Desktop umgeleitet ist - das ist aber auch bei allen anderen der Fall), außerdem prangt eine dicke Fehlermeldung, die aussagt, das Laufwerk H:\ nicht verbunden ist.
Merkwürdig: Die beiden behelfen sich mit einem Neustart, danach ist H:\ dann problemlos verbunden. Auch wenn die beiden irgendwann später am Tag ihre Rechner neustarten, gibt's keine Probleme mehr mit Netzlaufwerk H:\, das passiert also nur frühmorgens.
Besonderheit: Die beiden sind Früh-Frühaufsteher und die beiden ersten des Tages im Gebäude, ungefähr zur gleichen Zeit. Die dritte Person kommt erst eine Viertelstunde später in's Haus und hat keine Probleme, auch alle noch später eintreffenden Kollegen nicht. Auch ich nicht.
Problem: Einer der beiden mit dem Problem ist mein Chef, und jetzt verliert er allmählich die Geduld, ist genervt von dem täglichen Doppelstart, was ich verstehen kann. Er hat mich schon gefragt, ob die Switche und/oder der Fileserver da noch schlafen, und erst durch seinen ersten Anmeldeimpuls als erster des Tages dann aufwachen, weshalb H:\ nicht verbunden wird, die nachfolgenden Netzlaufwerke (per Logonskript) aber schon.
Backup läuft zu der Zeit keines mehr, die Backups (Veeam) sind allerspätestens morgens um Vier beendet.
Ich weiß nicht mal ansatzweise, wie ich das Problem angehen soll.
Hat jemand einen Rat?
Danke Euch erstmal.
Viele Grüße
von
departure69
- Microsoft-Windows-Active-Directory-Domäne firma.local
- Domänenfunktionsebene 2016
- 2 DCs, 1 x physisch, 1x virtuell, beide W2K16, aktuell gepatcht
- Fileserver Windows 2012 R2, virtuell, aktuell gepatcht
- Windows-10-Pro-x64-Clients, Buildversion 21H2, alle aktuell gepatcht
Das Userhome im Netzwerk verbinden wir bei allen Usern per Basisverzeichniseintrag in den AD-Eigenschaften der User, bei uns per Laufwerk H: \\Fileserver\homes$\<username>. Sonstige Netzlaufwerke per Logon-Skript.
Bei zwei Usern passiert seit circa 6-8 Wochen jeden Tag frühmorgens bei der ersten Windows-Anmeldung des Tages an ihren Bürorechnern das Gleiche: Laufwerk H: ist nicht verbunden. Das passiert nur bei diesen beiden, bei allen anderen (circa 25-30 Leute) nicht. Die beiden bemerken das auch sofort, weil der Desktop nahezu leer ist (weil er nach H:\Desktop umgeleitet ist - das ist aber auch bei allen anderen der Fall), außerdem prangt eine dicke Fehlermeldung, die aussagt, das Laufwerk H:\ nicht verbunden ist.
Merkwürdig: Die beiden behelfen sich mit einem Neustart, danach ist H:\ dann problemlos verbunden. Auch wenn die beiden irgendwann später am Tag ihre Rechner neustarten, gibt's keine Probleme mehr mit Netzlaufwerk H:\, das passiert also nur frühmorgens.
Besonderheit: Die beiden sind Früh-Frühaufsteher und die beiden ersten des Tages im Gebäude, ungefähr zur gleichen Zeit. Die dritte Person kommt erst eine Viertelstunde später in's Haus und hat keine Probleme, auch alle noch später eintreffenden Kollegen nicht. Auch ich nicht.
Problem: Einer der beiden mit dem Problem ist mein Chef, und jetzt verliert er allmählich die Geduld, ist genervt von dem täglichen Doppelstart, was ich verstehen kann. Er hat mich schon gefragt, ob die Switche und/oder der Fileserver da noch schlafen, und erst durch seinen ersten Anmeldeimpuls als erster des Tages dann aufwachen, weshalb H:\ nicht verbunden wird, die nachfolgenden Netzlaufwerke (per Logonskript) aber schon.
Backup läuft zu der Zeit keines mehr, die Backups (Veeam) sind allerspätestens morgens um Vier beendet.
Ich weiß nicht mal ansatzweise, wie ich das Problem angehen soll.
Hat jemand einen Rat?
Danke Euch erstmal.
Viele Grüße
von
departure69
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: 1578223109
Url: https://administrator.de/contentid/1578223109
Ausgedruckt am: 21.11.2024 um 21:11 Uhr
10 Kommentare
Neuester Kommentar
Hi,
Du könntest versuchen, es über einen Workaround zu kompensieren:
--> Auch das Verbinden des Homedrive zusätzlich in das Loginscript aufnehmen.
Spontan hätte ich ja auf die Einstellung "Beim Neustart und Anmeldung immer auf das Netzwerk warten" getippt. Aber da würde nicht ins Bild passen, dass es nach einem Neustart dann geht.
Ich glaube es zwar nicht wirklich, aber Du könntest es ja mal ausschließen: Was ist, wenn sich früh morgens an diesen Rechnern ein anderer Benutzer anmeldet? Da müsstest Du mal ne Frühschicht einschieben. Oder Deinen Chef dazu bekommen, dass er es zuerst mal mit einem anderen Benutzer versucht. So als einmaligen Test.
Ansonsten - bei dieser Fehlerbeschreibung - würde ich ein Hardware-"Problem" (Zustand) vermuten. Was habt Ihr da im Einsatz, was eine "verspätete" Verbindung des Clients zum Netz verursachen könnte? Wie ist der Client am Netz? LAN oder WLAN?
E.
Du könntest versuchen, es über einen Workaround zu kompensieren:
--> Auch das Verbinden des Homedrive zusätzlich in das Loginscript aufnehmen.
Spontan hätte ich ja auf die Einstellung "Beim Neustart und Anmeldung immer auf das Netzwerk warten" getippt. Aber da würde nicht ins Bild passen, dass es nach einem Neustart dann geht.
Ich glaube es zwar nicht wirklich, aber Du könntest es ja mal ausschließen: Was ist, wenn sich früh morgens an diesen Rechnern ein anderer Benutzer anmeldet? Da müsstest Du mal ne Frühschicht einschieben. Oder Deinen Chef dazu bekommen, dass er es zuerst mal mit einem anderen Benutzer versucht. So als einmaligen Test.
Ansonsten - bei dieser Fehlerbeschreibung - würde ich ein Hardware-"Problem" (Zustand) vermuten. Was habt Ihr da im Einsatz, was eine "verspätete" Verbindung des Clients zum Netz verursachen könnte? Wie ist der Client am Netz? LAN oder WLAN?
E.
Moin,
spontan würde ich mal prüfen, ob es irgendwelche Restriktionen bzgl. der Anmeldezeiten am System gibt.
Vielleicht liegen die beiden knapp ausserhalb des Erlaubten.
Gruß
Looser
spontan würde ich mal prüfen, ob es irgendwelche Restriktionen bzgl. der Anmeldezeiten am System gibt.
Vielleicht liegen die beiden knapp ausserhalb des Erlaubten.
Gruß
Looser
Moin,
Spontan fallen mir 3 Möglichkeiten ein, das Problem zu lösen.
1. Du Überzeugst dein Chef später in seiner Firma auszuschlagen
2. Du bist zukünftig als erstes in der Firma und ziehst die "Fehlanmeldung" auf dich
3. Du schaust im Eventlog nach, was los ist.
Gruß
C.C.
Spontan fallen mir 3 Möglichkeiten ein, das Problem zu lösen.
1. Du Überzeugst dein Chef später in seiner Firma auszuschlagen
2. Du bist zukünftig als erstes in der Firma und ziehst die "Fehlanmeldung" auf dich
3. Du schaust im Eventlog nach, was los ist.
Gruß
C.C.
Spontan hätte ich ja auf die Einstellung "Beim Neustart und Anmeldung immer auf das Netzwerk warten" getippt. Aber da würde nicht ins Bild passen, dass es nach einem Neustart dann geht.
Hätte ich auch getippt, zusammen mit Fast Startup und/oder Hibernating.
Fast Startup und Hibernating wird bei mir immer deaktiviert, weil es seit SSDs kaum mehr relevant ist und dafür erstaunlich viele Probleme bringt, die sich meist in genau so etwas lästigem und schwer reproduzierbarem äußern.
Was ist, wenn sich früh morgens an diesen Rechnern ein anderer Benutzer anmeldet?
Hier aber aufpassen, dass es keine Erstanmeldung ist, ansonsten wird das Problem vermutlich erstmal nicht auftreten, weil sowieso auf Antwort vom DC gewartet wird.
Servus,
diese Thematik haben wir öfters auch im Unternehmen. Grundsätzlich ist das Home-Laufwerk im AD hinterlegt, zusätzlich auch im Login-Skript. Selbst da gibt es hin und wieder Probleme. Bei manchen Usern habe ich ein Skript geschrieben, welches manuell nochmal die Netzlaufwerke mappt - erst per Host-Name, dann per IP.
-> Die Problematik ist bei uns zumindest meist das fehlerhafte Auflösen des Host-Names. Ein ipconfig /flushdns richtet es dann immer wieder, nachdem der PC selber es oft nicht auf die Reihe kriegt. Des Weiteren schaue ich deswegen auch direkt bei den DNS-Einträgen rein, ob dort noch alles richtig konfiguriert ist - einfach zur Sicherheit.
Aber auch Abhängigkeiten wie LAN oder WLAN können da mit reinspielen.
diese Thematik haben wir öfters auch im Unternehmen. Grundsätzlich ist das Home-Laufwerk im AD hinterlegt, zusätzlich auch im Login-Skript. Selbst da gibt es hin und wieder Probleme. Bei manchen Usern habe ich ein Skript geschrieben, welches manuell nochmal die Netzlaufwerke mappt - erst per Host-Name, dann per IP.
-> Die Problematik ist bei uns zumindest meist das fehlerhafte Auflösen des Host-Names. Ein ipconfig /flushdns richtet es dann immer wieder, nachdem der PC selber es oft nicht auf die Reihe kriegt. Des Weiteren schaue ich deswegen auch direkt bei den DNS-Einträgen rein, ob dort noch alles richtig konfiguriert ist - einfach zur Sicherheit.
Aber auch Abhängigkeiten wie LAN oder WLAN können da mit reinspielen.
Servus,
sind die Clients von der Hardware alle identisch? Wie sieht es mit den LAN Treibern aus?
Was passiert, wenn sich dein Chef morgens mal an einem anderen Client anmeldet? (zum testen)
Grüße
sind die Clients von der Hardware alle identisch? Wie sieht es mit den LAN Treibern aus?
Was passiert, wenn sich dein Chef morgens mal an einem anderen Client anmeldet? (zum testen)
Grüße
Moin,
steht denn was im EventLog des Clients?
mal den FQDN oder die IP des Filers hinterlegt?
Wir haben auch mal ein Jahr mit derartigen Problemen gekämpft und am Ende war's der Virenscanner der den Zugriff auf einen Pfad - der nicht mehr exisierte aber auf dem gleichen Filer lag - gesperrt hat.
Viel Erfolg.
Gruß
steht denn was im EventLog des Clients?
mal den FQDN oder die IP des Filers hinterlegt?
Wir haben auch mal ein Jahr mit derartigen Problemen gekämpft und am Ende war's der Virenscanner der den Zugriff auf einen Pfad - der nicht mehr exisierte aber auf dem gleichen Filer lag - gesperrt hat.
Viel Erfolg.
Gruß
Die beiden Gesellen 15 Min. später anfangen lassen? 
Sorry...ist ja erst Donnerstag. Aber mal im Ernst....lass die beiden mal testweise sich erst 15 Min. später anmelden. Falls es dann flutscht, hast du ein recht enges Zeitfenster, das du nach Fehlern absuchen kannst.
Sorry...ist ja erst Donnerstag. Aber mal im Ernst....lass die beiden mal testweise sich erst 15 Min. später anmelden. Falls es dann flutscht, hast du ein recht enges Zeitfenster, das du nach Fehlern absuchen kannst.
An alle:
Danke Euch für die zahlreichen Beiträge.
Habe jetzt (gestern) den Workaround genommen, den @emeriks und @SirEistee empfohlen haben. Laufwerk H: (also net use H: \\fileserver\homes$\username) steht jetzt bei den beiden Betroffenen nicht mehr nur in den AD-Eigenschaften als Basislaufwerk, sondern zusätzlich auch im Logon-Skript. Klappt einwandfrei, bei beiden Usern keine Probleme mehr mit dem Home-Laufwerk, bei einem war ich heute früh zugegen (bin extra früher zur Arbeit zum Zuschauen, weil das ja später am Tag nicht mehr reproduzierbar ist, sondern immer nur bei erster Anmeldung frühmorgens), alles paletti.
Der Workaround löst jetzt das Problem, zur tiefergehenden Ursachenforschung hab' ich allerdings weder Zeit noch Muße. An der Host-Namenslänge (Net-BIOS-Name gegen FQDN) lag es jedoch sicher nicht, wir verwenden schon seit längerer Zeit in allen Pfaden und allen Bezeichnungen nur noch den FQDN, auch im intern LAN. Grund dafür war aber der WAN-VPN, der braucht bei uns in jedem Fall die FQDNs. Und weil ich nicht ständig darüber nachdenken will, verwenden wir nur noch die vollen, langen FQDN-Bezeichnungen, bei allen User- und Hostnamen, und das überall.
Schnellstart ist auch bei allen Rechnern deaktiviert, daran kann es auch nicht liegen
@148656:
Jetzt aber nicht übertreiben, sooo weit wollte ich dann doch nicht gehen. Da könntest Du mir bei einem neuen Gerät oder einer neuen Software ja vergleichsweise auch ein RTFM an den Kopf werfen!
Nochmals Danke an alle.
Viele Grüße
von
departure69
Danke Euch für die zahlreichen Beiträge.
Habe jetzt (gestern) den Workaround genommen, den @emeriks und @SirEistee empfohlen haben. Laufwerk H: (also net use H: \\fileserver\homes$\username) steht jetzt bei den beiden Betroffenen nicht mehr nur in den AD-Eigenschaften als Basislaufwerk, sondern zusätzlich auch im Logon-Skript. Klappt einwandfrei, bei beiden Usern keine Probleme mehr mit dem Home-Laufwerk, bei einem war ich heute früh zugegen (bin extra früher zur Arbeit zum Zuschauen, weil das ja später am Tag nicht mehr reproduzierbar ist, sondern immer nur bei erster Anmeldung frühmorgens), alles paletti.
Der Workaround löst jetzt das Problem, zur tiefergehenden Ursachenforschung hab' ich allerdings weder Zeit noch Muße. An der Host-Namenslänge (Net-BIOS-Name gegen FQDN) lag es jedoch sicher nicht, wir verwenden schon seit längerer Zeit in allen Pfaden und allen Bezeichnungen nur noch den FQDN, auch im intern LAN. Grund dafür war aber der WAN-VPN, der braucht bei uns in jedem Fall die FQDNs. Und weil ich nicht ständig darüber nachdenken will, verwenden wir nur noch die vollen, langen FQDN-Bezeichnungen, bei allen User- und Hostnamen, und das überall.
Schnellstart ist auch bei allen Rechnern deaktiviert, daran kann es auch nicht liegen
@148656:
Du schaust im Eventlog nach, was los ist.
Jetzt aber nicht übertreiben, sooo weit wollte ich dann doch nicht gehen. Da könntest Du mir bei einem neuen Gerät oder einer neuen Software ja vergleichsweise auch ein RTFM an den Kopf werfen!
Nochmals Danke an alle.
Viele Grüße
von
departure69
Der Vorschlag ist für mich durchaus akzeptabel.
