Jump to content

Netzlaufwerke bei "schneller" Anmeldung nicht verbunden


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

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 von Vandro
Link zu diesem Kommentar

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.

Link zu diesem Kommentar

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. 

Link zu diesem Kommentar

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

Link zu diesem Kommentar

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?

Link zu diesem Kommentar

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. ;)

Link zu diesem Kommentar

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 von Vandro
Link zu diesem Kommentar

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 von Vandro
Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...