Windows 10: Gruppenrichtlinie wird nicht direkt nach dem Start angewendet und ist später erfolgreich

Mein Problem ist, dass Gruppenrichtlinien nicht angewendet werden, wenn ein Client neu gestartet wird. Direkt nach dem Start sendet 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 ist nicht nur ein kosmetisches Problem: Die Richtlinien werden wirklich 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 Netzlaufwerke werden angezeigt.

Das einfachste Szenario, in dem ich das Problem reproduzieren konnte: Neu erstellte Domäne auf frisch installiertem Windows Server 2012R2, Client ist ein frisch installierter Windows 10 64-Bit-Computer. Die Domäne besteht nur aus dem einen Domänencontroller und hat keine Beziehung zu anderen Domänen.

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

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

Nach ein oder zwei Minuten Wartezeit wird durch Ausführen des gleichen Befehls eine Verzeichnisliste angezeigt. Das Ausführen von gpupdate zu diesem Zeitpunkt funktioniert einwandfrei.

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: In demselben Richtlinienobjekt wird eine Registrierungseinstellung angegeben, und wenn ich die Registrierung überprüfe Auf dem Client ist die angegebene Einstellung vorhanden.

Andere Faktoren, die relevant sein könnten:

• NTLM ist in der Domäne eingeschränkt, dies scheint jedoch keine Rolle zu spielen: Auch nach dem Aktivieren, Aktualisieren von Richtlinien und Neustarten aller Computer bleiben die Symptome gleich.
• Es spielt keine Rolle, ob der Server über DHCP oder mit einer statischen Konfiguration konfiguriert ist.
• Der DNS-Server für die Domäne unterstützt keine dynamischen Updates. Die erforderlichen Datensätze wurden manuell hinzugefügt (aus C: \ Windows \ System32 \ config \ netlogon.dns).
• Der Ruhezustand ist auf dem Client (mithilfe powercfg /h off) deaktiviert, sodass jeder Start ein vollständiger Start und kein Schnellstart ist
• Die Wartezeit für die Richtlinienstartverarbeitung ist auf 120 Sekunden festgelegt
• Die Verbindung zum DC funktioniert einwandfrei. Pings werden funktionieren. Wenn Sie den Client deaktivieren, mein Konto in AD deaktivieren und den Client aktivieren, meldet sich der Client nicht bei mir an. Er merkt sofort, dass das Konto deaktiviert ist.
• Abgesehen von diesem Problem bemerke ich nichts Außergewöhnliches.

Dies scheint eher ein KMU-Problem als ein Gruppenrichtlinienproblem zu sein. Das Abhören 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 zu Port 445 des DC her, und eine ComNegotiation wird erfolgreich durchgeführt (DialectRevision: 0x02FF).
2. Unmittelbar danach wird ein Verhandeln 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 erteile und den Fehler erhalte, werden die Schritte 2 und 3 ausgeführt.

Wenn der Befehl zu arbeiten beginnt, werden die Schritte 1 und 2 ausgeführt. Statt dass der Client eine TCP-RST sendet, wird ein SessionSetup ausgeführt, dann ein TreeConnect und dann eine ganze Menge (scheinbar normaler) SMB-Chatter.

Es sieht also so aus, als würde der Client SMB erst ein oder zwei Minuten nach dem Start ordnungsgemäß mit dem DC kommunizieren. Dies führt dazu, dass die Gruppenrichtlinienverarbeitung fehlschlägt.

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

Ab Windows 8 führte Microsoft diesen Begriff des "Schnellstarts" ein, bei dem beim Herunterfahren des Betriebssystems der Speicherbedarf des Betriebssystems genau wie im Ruhezustand in normalen Ruhezustandszenarien in den Ruhezustand versetzt wird. Dies führt dazu, dass das Betriebssystem schneller gestartet wird, hat aber auch den Nebeneffekt, dass die GP-Verarbeitung pro Computer beim Start deaktiviert wird. Dies ist wahrscheinlich das, was Sie sehen, und dies kann deaktiviert werden, indem Sie die Richtlinie unter Computerkonfiguration \ Richtlinien \ Administrative Vorlagen \ System \ Herunterfahren \ Schnellstart erfordern

Wenn das Problem dadurch nicht behoben wird, handelt es sich höchstwahrscheinlich um ein Problem mit dem Netzwerkstapel-Timing, bei dem die GP-Verarbeitung für den Computer gestartet wird, 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 die Verarbeitung von Startrichtlinien eine Richtlinie hinzugefügt, mit der Sie die Wartezeit des GP vor dem Start verlängern können. Versuchen Sie es auf 60 Sekunden einzustellen und prüfen Sie, ob dies hilft.

Darren

Ich habe es geschafft, dieses Problem selbst zu lösen. Als Referenz hier ist, was mein Problem gelöst hat:

Erstens habe ich mich geirrt, dass das Deaktivieren aller Blockierungen von NTLM zu denselben Symptomen führte. Es ergab sich ein anderes Symptom, das zufällig den gleichen Effekt hatte. Ohne geltende NTLM-Blockierungsrichtlinien führte der dirBefehl nun zu einem Fehler , bei dem der Zugriff verweigert wurde. Gruppenrichtlinien gelten immer noch nicht, was sinnvoll ist: Auf SYSVOL war immer noch nicht zugegriffen.

Ein bisschen Websuche hat mir gesagt, dass ich weiß, dass ich ein häufigeres Problem habe. obwohl. 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 den Zugriff auf diese Freigaben geändert, was zu Problemen führen kann. Die Problemumgehung besteht darin, die UNC-Pfad-Härtung auf dem Client für diese Freigaben zu deaktivieren, indem Sie die Gruppenrichtlinie "Gehärtete UNC-Pfade" für die Windows 10-Clients wie folgt festlegen:

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

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

Weitere Informationen finden Sie im Artikel von Microsoft zu MS15-011 . 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 Einstellungen einige oder alle Schutzmaßnahmen gegen das Sicherheitsproblem deaktivieren, für das MS15-011 erstellt wurde! Kopieren / fügen Sie sie nicht nur blind ein, sondern treffen Sie eine fundierte Entscheidung, die auf den damit verbundenen Risiken basiert. Außerdem wird dieses Problem wahrscheinlich irgendwann in der Zukunft behoben. Vergessen Sie in diesem Fall nicht, diese Richtlinie auf die empfohlenen Werte festzulegen, wie in MS15-011 beschrieben.

Ich habe verschiedene Vorschläge ausprobiert, einschließlich Änderungen an der Registrierung und Änderungen an lokalen Gruppenrichtlinien, von denen keiner das Problem löste. Zugeordnete Laufwerke wurden beim Booten immer noch nicht ausgeführt. Ein gpupdate würde es jedes Mal beheben, aber das war ein zusätzlicher Schritt für den Benutzer.

Am Ende wurde das Problem behoben, indem die Netzwerklaufwerke manuell zugeordnet und die Gruppenrichtlinienobjekteinträge auf jedem von ihnen ersetzt wurden. Ich muss sie nicht trennen und ersetzen, sondern habe sie genauso zugeordnet, wie sie zugeordnet wurden, nur manuell.

Nur zu Ihrer Information für alle anderen, 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 das gleiche Problem mit Win7-Clients, und ich habe versucht, mit Microsoft daran zu arbeiten. Sie sagten mir, dass es sich um einen Fehler handelt, haben mir aber bisher keine Möglichkeit gegeben, zu verfolgen, wann der Fehler behoben wird.

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