Windows 10: Gruppenrichtlinie kann nicht direkt nach dem Booten angewendet werden, ist aber später erfolgreich

Question

Mein Problem ist, dass die Gruppenrichtlinie nicht angewendet wird, wenn ein Client neu gestartet wird. Direkt nach dem Start veröffentlicht der Client eine Fehlermeldung im Ereignisprotokoll mit der Quelle „GroupPolicy (Microsoft-Windows-GroupPolicy)“ und der Ereignis-ID 1058: „Die Verarbeitung der Gruppenrichtlinie ist fehlgeschlagen. [...]“. Auf der Registerkarte „Details“ lautet der Fehlercode 50, was für ERROR_NOT_SUPPORTED steht. Es handelt sich nicht nur um ein kosmetisches Problem: Die Richtlinien werden tatsächlich nicht richtig angewendet: Die zugeordneten Netzwerklaufwerke sind beispielsweise nicht vorhanden. Nach einer Weile funktioniert die Ausführung von „gpupdate“ und die Richtlinien werden normal angewendet: Die zugeordneten Netzwerklaufwerke werden angezeigt.

Das einfachste Szenario, in dem ich das Problem reproduzieren konnte: Neu erstellte Domäne auf frisch installiertem Windows Server 2012R2, Client ist eine frisch installierte 64-Bit-Maschine mit Windows 10. Die Domäne besteht nur aus einem Domänencontroller und hat keine Beziehungen zu anderen Domänen.

Da die Fehlermeldung besagt, dass Windows eine .GPT-Datei aus der Sysvol-Freigabe der Domäne nicht lesen kann, habe ich versucht, über eine Eingabeaufforderung auf dieselbe Datei zuzugreifen. Und tatsächlich erhalte ich Folgendes, wenn ich direkt nach dem Booten eine Eingabeaufforderung öffne:

C:\Users\username>dir \\domain.example.com\sysvol
The request is not supported.

Nach einer Wartezeit von ein oder zwei Minuten wird durch Ausführen desselben Befehls eine Verzeichnisliste angezeigt. Wenn Sie an dieser Stelle gpupdate ausführen, funktioniert das problemlos.

Ich habe die Gruppenrichtlinieneinstellung „Beim Starten und Anmelden des Computers immer auf das Netzwerk warten“ auf „Aktiviert“ gesetzt und weiß, dass diese Richtlinie angewendet wird: Im selben Richtlinienobjekt ist eine Registrierungseinstellung angegeben, und wenn ich die Registrierung auf dem Client überprüfe, ist die angegebene Einstellung vorhanden.

Weitere Faktoren, die relevant sein könnten:

• NTLM ist in der Domäne eingeschränkt, aber das scheint keine Rolle zu spielen: Selbst nach der Aktivierung, Aktualisierung der Richtlinien und dem Neustart aller Maschinen bleiben die Symptome dieselben.
• Dabei spielt es keine Rolle, ob der Server per DHCP oder mit einer statischen Konfiguration konfiguriert ist.
• Der DNS-Server für die Domäne unterstützt keine dynamischen Updates. Die erforderlichen Einträge wurden manuell hinzugefügt (aus C:\Windows\System32\config\netlogon.dns).
• Der Ruhezustand ist auf dem Client (mit powercfg /h off) deaktiviert, sodass jeder Systemstart ein vollständiger Systemstart und kein Schnellstart ist.
• Die Wartezeit für die Richtlinienverarbeitung beim Start ist auf 120 Sekunden eingestellt.
• Die Verbindung zum DC funktioniert einwandfrei. Pings funktionieren. Wenn ich den Client ausschalte, mein Konto in AD deaktiviere und den Client wieder einschalte, meldet mich der Client nicht an: Er merkt sofort, dass das Konto deaktiviert ist.
• Abgesehen von diesem Problem fällt mir nichts Ungewöhnliches auf.

Dies scheint eher ein SMB-Problem als ein Gruppenrichtlinienproblem zu sein. Das Sniffen der Verbindung auf der Serverseite zeigt etwas Interessantes: Wenn ich den Befehl zum ersten Mal ausführe dir \\domain.example.com\sysvol, wird im Microsoft Message Analyzer auf dem DC Folgendes angezeigt:

1. Der Client stellt eine TCP-Verbindung zum Port 445 des DC her und eine ComNegotiation wird erfolgreich durchgeführt (DialectRevision: 0x02FF).
2. Unmittelbar danach wird ein Negotiate erfolgreich durchgeführt. Die DialectRevision ist 0x0302.
3. Unmittelbar danach schließt der Client die TCP-Verbindung mit einem TCP RST (??)

Jedes Mal, wenn ich den Befehl ausgebe und den Fehler erhalte, werden die Schritte 2 und 3 ausgeführt.

Wenn der Befehl zu funktionieren beginnt, werden die Schritte 1 und 2 ausgeführt, doch anstatt dass der Client ein TCP RST sendet, wird ein SessionSetup ausgeführt, dann ein TreeConnect und anschließend kommt es zu einer ganzen Menge (scheinbar normalem) SMB-Chatter.

Es scheint also, als ob der Client erst ein oder zwei Minuten nach dem Booten richtig über SMB mit dem DC kommunizieren kann, was dazu führt, dass die Verarbeitung der Gruppenrichtlinie fehlschlägt.

Weiß jemand, wie ich dieses Problem debuggen und lösen kann?

Answer 1

Ab Windows 8 hat Microsoft das Konzept des „Schnellstarts“ eingeführt, bei dem beim Herunterfahren des Betriebssystems der Arbeitsspeicherbedarf des Betriebssystems in den Ruhezustand versetzt wird, genau wie Hibernate in normalen Ruhezustandsszenarien funktioniert. Dies führt dazu, dass das Betriebssystem schneller hochfährt, hat aber auch den Nebeneffekt, dass die GP-Verarbeitung pro Computer beim Start deaktiviert wird. Das ist wahrscheinlich das, was Sie sehen, und dies kann deaktiviert werden, indem Sie die Richtlinie unter Computerkonfiguration\Richtlinien\Administrative Vorlagen\System\Herunterfahren\Verwendung von Schnellstart erforderlich deaktivieren.

Wenn das Problem dadurch nicht gelöst wird, handelt es sich höchstwahrscheinlich um ein Problem mit der Netzwerkstapeltaktung, bei dem die GP-Verarbeitung für den Computer beginnt, bevor der Netzwerkstapel vollständig initialisiert ist. Dies gibt es seit XP und ab Windows 7 hat Microsoft unter Computerkonfiguration\Richtlinien\Administrative Vorlagen\System\Gruppenrichtlinie\Wartezeit für Startrichtlinienverarbeitung eine Richtlinie hinzugefügt, mit der Sie die Zeit erhöhen können, die GP wartet, bevor es gestartet wird. Versuchen Sie, sie auf 60 Sekunden einzustellen, und prüfen Sie, ob das hilft.

Darren

Answer 2

Ich habe es geschafft, dieses Problem selbst zu lösen. FürReferenzFolgendes hat mein Problem gelöst:

Erstens lag ich falsch, als ich dachte, dass das Deaktivieren aller Blockierungen von NTLM zu den gleichen Symptomen führte. Es führte zu einemandersSymptom, das zufällig die gleiche Wirkung hatte. Ohne NTLM-Blockierungsrichtlinien dirführte der Befehl nun zu einem Zugriffsverweigerungsfehler. Die Gruppenrichtlinie ließ sich immer noch nicht anwenden, was Sinn macht: SYSVOL war immer noch nicht zugänglich.

Nach einiger Suche im Internet habe ich jedoch festgestellt, dass es ein häufigeres Problem gibt. Anscheinend können Windows 10-Clients Probleme beim Zugriff auf die SYSVOL-Freigabe von Domänencontrollern (und möglicherweise auch auf die NETLOGON-Freigabe) haben. Angeblich hat Windows 10 etwas an der Art und Weise geändert, wie auf diese Freigaben zugegriffen wird, was zu Problemen führen kann. Die Problemumgehung besteht darin, die UNC-Pfadhärtung auf dem Client für diese Freigaben zu deaktivieren, indem die Gruppenrichtlinie „Gehärtete UNC-Pfade“ für die Windows 10-Clients wie folgt festgelegt wird:

\\*\SYSVOL RequireMutualAuthentication=0,RequireIntegrity=0,RequirePrivacy=0
\\*\NETLOGON RequireMutualAuthentication=1,RequireIntegrity=1

(Wenn beim Zugriff auf die Netlogon-Freigabe von Windows 10-Clients aus Probleme auftreten, kann es hilfreich sein, alle drei Parameter auch für diese Freigabe auf Null zu setzen.)

Sehen Sie sich dieArtikel von Microsoft zu MS15-011für weitere Informationen. Es enthält eine gute Beschreibung der Sicherheitsauswirkungen einer Änderung dieser Einstellung sowie detaillierte Schritte zum Ändern der Richtlinie.

Warnung: Beachten Sie, dass die obigen Einstellungendeaktiviereneinige oder alle Schutzmaßnahmen gegen das Sicherheitsproblem, für das MS15-011 entwickelt wurde!NichtKopieren/fügen Sie sie einfach blind ein, aber treffen Sie eine fundierte Entscheidung auf der Grundlage der damit verbundenen Risiken. Außerdem wird dieses Problem wahrscheinlich irgendwann in der Zukunft gelöst. Vergessen Sie in diesem Fall nicht, diese Richtlinie auf die empfohlenen Werte einzustellen, wie in MS15-011 beschrieben.

Answer 3

Nur zur Information für alle, die diesen Thread finden: Wenn Sie die UNC-Härtung deaktivieren, indem Sie die gegenseitige Authentifizierung auf 0 setzen, wird ein Teil Ihrer Sicherheit deaktiviert. Wir haben dasselbe Problem mit Win7-Clients und ich habe versucht, mit Microsoft daran zu arbeiten. Sie sagten mir, es sei ein Fehler, haben mir aber bisher keine Möglichkeit gegeben, zu verfolgen, wann der Fehler behoben wird.

Weitere Informationen finden Sie in diesem anderen Thread. https://social.technet.microsoft.com/Forums/en-US/6a20e3f6-728a-4aa9-831a-6133f446ea08/gpos-do-not-apply-on-windows-10-enterprise-x64

Answer 4

Ich habe mehrere Vorschläge ausprobiert, darunter Änderungen an der Registrierung und an lokalen Gruppenrichtlinien, aber keiner davon hat das Problem gelöst – zugeordnete Laufwerke wurden beim Booten immer noch mit „X“ markiert. Ein gpupdate würde das Problem jedes Mal beheben, aber das wäre ein zusätzlicher Schritt für den Benutzer.

Was das Problem letztendlich behoben hat, war die manuelle Zuordnung der Netzlaufwerke und das Ersetzen der GPO-Einträge auf jedem dieser Laufwerke. Es war nicht nötig, die Verbindung zu trennen und sie zu ersetzen, ich habe sie genauso zugeordnet, wie sie zugeordnet wurden, nur manuell.