Vandro 0 Geschrieben 16. Oktober 2017 Melden Teilen Geschrieben 16. Oktober 2017 (bearbeitet) Hallo liebe MCSE Gemeinschaft, ich komme bei einem kleinen, aber nervigen Problem derzeit nicht weiter. Aktuelle Clients haben reproduzierbar das Problem, dass wenn der User den Clients startet und sobald es möglich ist sein Kennwort eingibt und sich anmeldet, die Netzlaufwerke nicht verbunden sind. Er erhält eine Meldung und die Laufwerke haben ein rotes X. Wartet er nun ca. 60 Sekunden, kann er auf die Laufwerke zugreifen. Wenn der User den PC startet und mit der Kennworteingabe ein paar Sekunden wartet, läuft alles problemlos. Packe ich z.B. Outlook in den Autostart, funktioniert der Zugriff auf den Exchange perfekt, während die Netzlaufwerke noch nicht funktionieren. Ein Ping geht ebenfalls an alle Server sofort nach der Anmeldung, während die Netzlaufwerke die besagten 60 Sekunden benötigen, bis der Zugriff möglich ist. Das Netzwerk scheint also bereit zu sein. Das Phänomen tritt nur auf neuen PCs auf und auch nur, wenn User wirklich sehr schnell sein Kennwort eingibt. Die Ereignisanzeigen sind sauber, keine Fehler die auf Netzlaufwerke oder nicht bearbeitete GPO hinweisen. Alle Dienste starten vernünftig und die GPOs werden auch korrekt verarbeitet. Virenscanner und Firewall testweise deaktiviert, keine Änderung. Folgende GPOs / GPPs sind gesetzt: Fast Boot deaktiviert (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Power\HiberbootEnabled) Computerkonfiguration\Administrative Vorlagen\System\Gruppenrichtlinie\Wartezeit für Richtlinienverarbeitung beim Systemstart angeben (60 Sekunden) Computerkonfiguration\Administrative Vorlagen\System\Anmelden\Beim Neustart des Computer... immer auf das Netzwerk warten Hier bin ich mir unsicher, ob ich diese Richtlinie überhaupt benötige, da wir nicht mit Login Skripten arbeiten - aktiviert sind derzeit folgende: Computerkonfiguration\Administrative Vorlagen\System\Skripts --> Anmeldeskripts gleichzeitig ausführen --> Maximale Wartezeit für Gruppenrichtlinienskripts angeben (0 Sekunden, also solange warten, bis das Skript abgeschlossen ist) --> Startskripts asynchron ausführen GPP für die Laufwerke Option Erstellen mit dem jeweiligen Pfad auf den DFS Share. Eckdaten: Clients alle homogen auf Windows 10 Pro, IPs via DHCP (mit fester IP selbiges Problem), DNS, WINS arbeiten sauber 2x DCs 2012R2 DFS-Namespaceserver 1x STORAGE 2012R2 worauf die Shares liegen Hat jemand von euch ein ähnliches Problem und eventuell eine Lösung? Ich könnte natürlich die Kennwortrichtlinie auf 14 Stellen setzen, aber da steigen mir meine User sicher aufs Dach :-) Grüße bearbeitet 16. Oktober 2017 von Vandro Zitieren Link zu diesem Kommentar
Sunny61 806 Geschrieben 16. Oktober 2017 Melden Teilen Geschrieben 16. Oktober 2017 Wie werden die Laufwerke verbunden? Per GPP? Wenn ja, Ersetzen, Aktualisieren oder Erstellen? Oder doch per Scirpt? Schau dir auch diesen Artikel dazu an: https://www.gruppenrichtlinien.de/artikel/ssd-zu-schnell-synchroner-startvorgang-nicht-moeglich/ Zitieren Link zu diesem Kommentar
Vandro 0 Geschrieben 16. Oktober 2017 Autor Melden Teilen Geschrieben 16. Oktober 2017 Wie werden die Laufwerke verbunden? Per GPP? Wenn ja, Ersetzen, Aktualisieren oder Erstellen? Oder doch per Scirpt? Schau dir auch diesen Artikel dazu an: https://www.gruppenrichtlinien.de/artikel/ssd-zu-schnell-synchroner-startvorgang-nicht-moeglich/ Per GPP mit der Option Erstellen. Bei Aktualisieren hatten wir immer Schwierigkeiten, dass sich die geöffnete Ordnerstruktur der User immer zum Aktualisierungszeitpunkt der GPO geschlossen hat. Den Link kenne ich, die GPO ist gesetzt und der Registrywert bringt keine Besserung. Zitieren Link zu diesem Kommentar
Sunny61 806 Geschrieben 16. Oktober 2017 Melden Teilen Geschrieben 16. Oktober 2017 Erstellen und Ersetzen ist schlecht, aktualisieren ist die bessere Variante. Bei Erstellen wird in der laufenden Sitzung getrennt und wieder neu erstellt. Welchen der Registrywerte hast Du gesetzt? Oder hast Du gleich ganz oben das Lesen aufgehört? Zitieren Link zu diesem Kommentar
lefg 276 Geschrieben 16. Oktober 2017 Melden Teilen Geschrieben 16. Oktober 2017 Moin Ich denke mal, beim schnellen Anmelden erfolgt diese cached, da die Netzwerkverbindung noch nicht vorhanden ist. Die klassische Abhilfe ist die Gruppenrichtlinie "...... immeer auf das Netzwerk warten". Zitieren Link zu diesem Kommentar
Vandro 0 Geschrieben 17. Oktober 2017 Autor Melden Teilen Geschrieben 17. Oktober 2017 Erstellen und Ersetzen ist schlecht, aktualisieren ist die bessere Variante. Bei Erstellen wird in der laufenden Sitzung getrennt und wieder neu erstellt. Welchen der Registrywerte hast Du gesetzt? Oder hast Du gleich ganz oben das Lesen aufgehört? Ich habe heute wieder ein paar Tests gefahren und die GPPs auf AKTUALISIEREN geändert, kein Erfolg. So wie Du die Wirkweise von "ERSTELLEN" beschreibst, habe ich es nicht erfahren. Bei mir bewirkt ERSETZTEN genau das von Dir beschriebenen Vorgehen, dass es getrennt und neu verbunden wird. Beim ERSTELLEN prüft er nur ob vorhanden, falls ja macht er gar nichts, falls nein verbindet er. So ist zumindest meine Erfahrung. Ebenfalls habe ich erneut den Artikel gelesen und die GPO (Wartezeit für Richtlinienverarbeitung...) erneut gesetzt. Wenn ich es richtig verstehe, bringt der Trick mit der Abhängigkeit nur weniger Wartezeit für Geräten außerhalb des Netztes. Dennoch habe ich das am Testclient umgesetzt, keine Änderung. Es bleibt leider bisher dabei, wenn der User sehr schnell sein Kennwort eingibt, sind die Netzlaufwerke erst nach ca. 60 Sekunden verbunden. Moin Ich denke mal, beim schnellen Anmelden erfolgt diese cached, da die Netzwerkverbindung noch nicht vorhanden ist. Die klassische Abhilfe ist die Gruppenrichtlinie "...... immeer auf das Netzwerk warten". Danke für deinen Kommentar. Steht schon im Eingangspost, diese GPO ist selbstverständlich gesetzt. Alle GPOs und GPPs werden auch ordnungsgemäß verarbeitet, nur die Netzlaufwerke stehen eben nicht sofort zur Verfügung. Zitieren Link zu diesem Kommentar
NilsK 2.939 Geschrieben 17. Oktober 2017 Melden Teilen Geschrieben 17. Oktober 2017 Moin, Danke für deinen Kommentar. Steht schon im Eingangspost, diese GPO ist selbstverständlich gesetzt. da ich gerade letzte Woche wieder einen Kunden hatte, der das auch sagte, wo es aber nach langem, langem Troubleshooting dann doch nicht so war - ist das überprüft? Wirkt das entsprechende GPO auf diese Rechner? Gruß, Nils Zitieren Link zu diesem Kommentar
Vandro 0 Geschrieben 17. Oktober 2017 Autor Melden Teilen Geschrieben 17. Oktober 2017 Moin, da ich gerade letzte Woche wieder einen Kunden hatte, der das auch sagte, wo es aber nach langem, langem Troubleshooting dann doch nicht so war - ist das überprüft? Wirkt das entsprechende GPO auf diese Rechner? Gruß, Nils Sie wird mir zumindest im RSOP angezeigt, ob sie auch tatsächlich zieht weiß ich nicht. Wie kann ich das im Detail prüfen? Zitieren Link zu diesem Kommentar
Sunny61 806 Geschrieben 17. Oktober 2017 Melden Teilen Geschrieben 17. Oktober 2017 Prüfen kannst Du das alles in der Registry direkt auf den betroffenen Clients. Ist denn auch ganz sicher der Schnellstart abgeschaltet? powercfg /hibernate off in einer administrativen Commandline hilft. Wir haben ~580 W10 Clients, bei keinem einzigen das von dir angesprochene Problem. Evtl. ist ja der AV-Scanner der Schuldige, der vieles verhindert. BTW: Es heißt ERSETZEN, da ist ein t zu viel bei dir. ;) Zitieren Link zu diesem Kommentar
Vandro 0 Geschrieben 17. Oktober 2017 Autor Melden Teilen Geschrieben 17. Oktober 2017 (bearbeitet) Prüfen kannst Du das alles in der Registry direkt auf den betroffenen Clients. Ist denn auch ganz sicher der Schnellstart abgeschaltet? powercfg /hibernate off in einer administrativen Commandline hilft. Wir haben ~580 W10 Clients, bei keinem einzigen das von dir angesprochene Problem. Evtl. ist ja der AV-Scanner der Schuldige, der vieles verhindert. BTW: Es heißt ERSETZEN, da ist ein t zu viel bei dir. ;) Fastboot ist definitv abgeschaltet, habe es auch nochmals mit powercfg /hibernate off getestet. Der Regkey "SyncForegroundPolicy" mit dem DWORD Wert 1 ist gesetzt. Die GPO habe ich ebenfalls nochmals lokal gesetzt... Ihr könnt es euch denken --> keine Änderung. Ich teste alles auf einem frisch installierten Windows 10 1703 Client mit allen Updates, ohne Virenscanner und Firewall. bearbeitet 17. Oktober 2017 von Vandro Zitieren Link zu diesem Kommentar
lefg 276 Geschrieben 17. Oktober 2017 Melden Teilen Geschrieben 17. Oktober 2017 (bearbeitet) Moin Ob es hilfreich ist? Edit: Es gibt eine Anleitung zum verzögerten Start eines Dienstes. https://www.gruppenrichtlinien.de/artikel/ssd-zu-schnell-synchroner-startvorgang-nicht-moeglich/ Edit: Das scheint wohl aber schon bekannt. bearbeitet 18. Oktober 2017 von lefg Zitieren Link zu diesem Kommentar
Sunny61 806 Geschrieben 17. Oktober 2017 Melden Teilen Geschrieben 17. Oktober 2017 Ob es hilfreich ist? https://www.gruppenrichtlinien.de/artikel/ssd-zu-schnell-synchroner-startvorgang-nicht-moeglich/ Wurde ihm schon gepostet. http://www.mcseboard.de/topic/211487-netzlaufwerke-bei-schneller-anmeldung-nicht-verbunden/?do=findComment&comment=1341417 Zitieren Link zu diesem Kommentar
Vandro 0 Geschrieben 18. Oktober 2017 Autor Melden Teilen Geschrieben 18. Oktober 2017 (bearbeitet) Problem gelöst Die Lösung habe ich hier gefunden: https://community.spiceworks.com/topic/291388-windows-doesn-t-recognize-domain-until-60-seconds-after-startup Netbios Domainname in DNS eintragen, Cache leeren und alles funktioniert auf den Rechnern tadellos. Es betrifft scheinbar nur PCs mit SSD, die zu schnell starten. Die jeweiligen GPOs haben bei mir bekanntlich nichts gebracht. Der einfache Host A Eintrag hingegen schon, die Erklärung was genau passiert und warum das die Lösung ist, bleibt aber leider aus. Vielleicht kann das von euch ja jemand aufklären? Laut dem Link oben, ist dies eine Lösung aus einem Microsoft Call. Danke euch für die Hilfe. bearbeitet 18. Oktober 2017 von Vandro Zitieren Link zu diesem Kommentar
lefg 276 Geschrieben 18. Oktober 2017 Melden Teilen Geschrieben 18. Oktober 2017 (bearbeitet) Moin Ich denke, die Gpruppenrichtlinien konnten nicht wirksam werden, die Auflösung funktionierte nicht, da der Client sich nicht in den DNS der Domäne eintragen konnte. Gab es denn keine Fehlermeldung im Ereignisprotokoll dazu? bearbeitet 18. Oktober 2017 von lefg Zitieren Link zu diesem Kommentar
Sunny61 806 Geschrieben 18. Oktober 2017 Melden Teilen Geschrieben 18. Oktober 2017 Problem gelöst Die Lösung habe ich hier gefunden: https://community.spiceworks.com/topic/291388-windows-doesn-t-recognize-domain-until-60-seconds-after-startup Danke euch für die Hilfe. Freut mich für Dich und Danke für die Rückmeldung. ;) Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.