[English]Im Windows 10 November 2019 Update (Version 1909) scheint es ein Problem mit der Auslieferung von Gruppenrichtlinien zu geben, da diese nicht zuverlässig aktiviert werden können. Hatte ich vor einigen Tagen bereits angesprochen. Nun sind mir neue Informationen von einem betroffenen Blog-Leser zugegangen. Möglicherweise ist der Windows Defender, der über die ISO-Installationsmedien für Windows 10 Version 1909 verteilt wird, an den Problemen beteiligt.
Anzeige
Worum geht es?
Blog-Leser Markus K. hatte mich Ende 2019 über eine merkwürdige Beobachtung im Zusammenhang mit Windows 10 November 2019 Update (Version 1909) und Gruppenrichtlinien informiert. Einige Testsysteme mit dem Windows 10 November 2019 Update (Version 1909) zeigen das merkwürdige Verhalten, dass Gruppenrichtlinien nicht immer greifen.
Markus K. schrieb mir, dass auf Rechnern mit Windows 10 Version 1909 es einfach Zufall sei, ob eine Gruppenrichtlinie greife oder nicht. Weder die Ereignisprotokolle (Eventlog) noch GPSVC Log liefern besonders viel sinnvolles, so seine Aussage. Ich hatte das Ganze am 30. Dezember 2019 im Beitrag Windows 10 V1909 und ein mögliches GPO-Problem hier im Blog angesprochen. In den Diskussionen zum Beitrag kristallisierte sich heraus, dass andere Leser das Verhalten auch beobachten konnten.
Neue Informationen zum Problem
Die letzten Stunden hat mich Blog-Leser Markus K. über weitere Erkenntnisse informiert. In den Kommentaren zu obigem Blog-Beitrag angegebene Tipps (wie Caching oder Richtlinie Configure security policy processing setzen) scheinen nichts zu bringen. Dazu schrieb mir Markus: Allen im Blog gegebenen Hinweisen gefolgt, leider ergebnislos. Das Log sieht übrigens so aus:
GPSVC(4dc.62c) 08:47:18:084 ProcessGPOs(Machine): Processing extension Registrierung
GPSVC(4dc.62c) 08:47:18:084 ReadStatus: Read Extension's Previous status successfully.
GPSVC(4dc.62c) 08:47:18:084 ReadGPOList:++
GPSVC(4dc.62c) 08:47:18:084 CheckGPOs: ReadGPOList count = 0
GPSVC(4dc.62c) 08:47:18:085 CompareGPOLists: One list is empty
GPSVC(4dc.62c) 08:47:18:085 GPLockPolicySection: Sid = (null), dwTimeout = 30000, dwFlags = 0x40
GPSVC(4dc.62c) 08:47:18:085 bMachine = 1
GPSVC(4dc.62c) 08:47:18:085 Global Sync Lock Called
GPSVC(4dc.62c) 08:47:18:086 Writer Lock got immediately.
GPSVC(4dc.62c) 08:47:18:086 Global Lock taken successfully
GPSVC(4dc.62c) 08:47:18:086 ProcessGPOList:++ Entering for extension Registrierung
GPSVC(4dc.62c) 08:47:18:086 MachinePolicyCallback: Setting status UI to Richtlinie "Registrierung" wird übernommen…
GPSVC(4dc.62c) 08:47:18:090 LogExtSessionStatus: Successfully logged Extension Session data
GPSVC(4dc.62c) 08:47:18:091 GPLockPolicySection: Sid = (null), dwTimeout = 60000, dwFlags = 0x42
GPSVC(4dc.62c) 08:47:18:091 Registry Sync Lock Called
GPSVC(4dc.62c) 08:47:18:091 Writer Lock got immediately.
GPSVC(4dc.62c) 08:47:18:091 Registry Lock taken successfully
GPSVC(4dc.62c) 08:47:18:094 ResetPolicies: Entering.
GPSVC(4dc.62c) 08:47:18:094 SetPolicyOwnerOnKey: Setting owner on reg key on <Software\Policies>.
GPSVC(4ec.66c) 08:58:41:299 SetPolicyOwnerOnKey: Setting owner on reg key on <Software\Policies>.
GPSVC(4ec.66c) 08:58:41:299 SetPolicyOwnerOnKey: Setting owner on reg key on <Software\Microsoft\Windows\CurrentVersion\Policies>.
GPSVC(4ec.66c) 08:58:41:299 SetPolicyOwnerOnKey: Setting owner on reg key on <System\CurrentControlSet\Policies>.
GPSVC(4ec.66c) 08:58:41:300 ParseRegistryFile: Entering with <C:\ProgramData\ntuser.pol>.
GPSVC(4ec.66c) 08:58:41:300 DeleteRegistryValue: Deleted Software\Policies\Microsoft\SystemCertificates\EFS\EFSBlob
GPSVC(4ec.66c) 08:58:41:301 DeleteRegistryValue: Deleted Software\Policies\Microsoft\SystemCertificates\EFS\Certificates\
13A2741223481A329363D0BDCEAA9995FED85A70\Blob
GPSVC(4ec.66c) 08:58:41:301 DeleteRegistryValue: Deleted Software\Policies\Microsoft\SystemCertificates\EFS\CRLs\
….
GPSVC(4dc.62c) 08:47:18:098 DeleteRegistryValue: Deleted Software\Policies\Microsoft\Windows\System\EnableSmartScreen
GPSVC(4dc.62c) 08:47:18:099 DeleteRegistryValue: Deleted Software\Policies\Microsoft\Windows\System\ShellSmartScreenLevel
GPSVC(4dc.62c) 08:47:18:099 RegCleanUpKey: Failed to delete value <DisableAntiSpyware> with 5.
GPSVC(4dc.62c) 08:47:18:099 DeleteRegistryValue: Failed to delete Software\Policies\Microsoft\Windows Defender\DisableAntiSpyware
GPSVC(4dc.62c) 08:47:18:099 ParseRegistryFile: Callback function returned false.
…
GPSVC(4dc.62c) 08:47:18:238 ProcessGPOs(Machine): Extension Registrierung ProcessGroupPolicy failed, status 0x80004005.
Am Ende des Logs gibt es plötzlich einen Zugriffsfehler 0x80004005. Das ist zumindest eine Spur.
Anzeige
Der Windows Defender spuckt mit rein
In weiteren Tests ging Markus dann der Sache nach und kam auf eine mögliche Ursache. Dazu schrieb er in einer Folgemail:
Starkes Ding! Der Windows Defender (wird bei uns als AV-Lösung eingesetzt) ist schuld!
Es gibt bei uns eine GPO mit security filtering mit Computergruppe, in die man einen Rechner geben kann, um den Defender abzudrehen. Installiert man den Rechner mit deaktiviertem Windows Defender, werden alle GPOs angewendet!
Installiert man selbes Gerät erneut mit aktiviertem Defender ist Ende im Gelände!
Markus hat den Testrechner mit Windows 10 Version 1909 [und abgedrehtem Defender] wieder in die Computergruppe gegeben und zwei mal neu gestartet. Hier ein neuer Log-Auszug:
GPSVC(4ec.66c) 08:58:41:281 ProcessGPOs(Machine): —————
GPSVC(4ec.66c) 08:58:41:281 ProcessGPOs(Machine): Processing extension Registrierung
GPSVC(4ec.66c) 08:58:41:282 ReadStatus: Read Extension's Previous status successfully.
GPSVC(4ec.66c) 08:58:41:282 ReadGPOList:++
GPSVC(4ec.66c) 08:58:41:282 CheckGPOs: ReadGPOList count = 0
GPSVC(4ec.66c) 08:58:41:282 CompareGPOLists: One list is empty
GPSVC(4ec.66c) 08:58:41:283 GPLockPolicySection: Sid = (null), dwTimeout = 30000, dwFlags = 0x40
GPSVC(4ec.66c) 08:58:41:283 bMachine = 1
GPSVC(4ec.66c) 08:58:41:283 Global Sync Lock Called
GPSVC(4ec.66c) 08:58:41:283 Writer Lock got immediately.
GPSVC(4ec.66c) 08:58:41:283 Global Lock taken successfully
GPSVC(4ec.66c) 08:58:41:283 ProcessGPOList:++ Entering for extension Registrierung
GPSVC(4ec.66c) 08:58:41:283 MachinePolicyCallback: Setting status UI to Richtlinie "Registrierung" wird übernommen…
GPSVC(4ec.66c) 08:58:41:284 GetWbemServices: CoCreateInstance succeeded
GPSVC(4ec.66c) 08:58:41:288 ConnectToNameSpace: ConnectServer returned 0x0
GPSVC(4ec.66c) 08:58:41:297 LogExtSessionStatus: Successfully logged Extension Session data
GPSVC(4ec.66c) 08:58:41:297 GPLockPolicySection: Sid = (null), dwTimeout = 60000, dwFlags = 0x42
GPSVC(4ec.66c) 08:58:41:297 Registry Sync Lock Called
GPSVC(4ec.66c) 08:58:41:297 Writer Lock got immediately.
GPSVC(4ec.66c) 08:58:41:297 Registry Lock taken successfully
GPSVC(4ec.66c) 08:58:41:299 ResetPolicies: Entering.
GPSVC(4ec.66c) 08:58:41:299 SetPolicyOwnerOnKey: Setting owner on reg key on <Software\Policies>.
GPSVC(4ec.66c) 08:58:41:299 SetPolicyOwnerOnKey: Setting owner on reg key on <Software\Microsoft\Windows\CurrentVersion\Policies>.
GPSVC(4ec.66c) 08:58:41:299 SetPolicyOwnerOnKey: Setting owner on reg key on <System\CurrentControlSet\Policies>.
GPSVC(4ec.66c) 08:58:41:300 ParseRegistryFile: Entering with <C:\ProgramData\ntuser.pol>.
GPSVC(4ec.66c) 08:58:41:300 DeleteRegistryValue: Deleted Software\Policies\Microsoft\SystemCertificates\EFS\EFSBlob
GPSVC(4ec.66c) 08:58:41:301 DeleteRegistryValue: Deleted Software\Policies\Microsoft\SystemCertificates\EFS\Certificates\
13A2741223481A329363D0BDCEAA9995FED85A70\Blob
GPSVC(4ec.66c) 08:58:41:301 DeleteRegistryValue: Deleted Software\Policies\Microsoft\SystemCertificates\EFS\CRLs\
GPSVC(4ec.66c) 08:58:41:301 DeleteRegistryValue: Deleted Software\Policies\Microsoft\SystemCertificates\EFS\CTLs\
GPSVC(4ec.66c) 08:58:41:302 DeleteRegistryValue: Deleted Software\Policies\Microsoft\MicrosoftEdge\PhishingFilter\EnabledV9
GPSVC(4ec.66c) 08:58:41:302 DeleteRegistryValue: Deleted Software\Policies\Microsoft\Windows\System\EnableSmartScreen
GPSVC(4ec.66c) 08:58:41:303 DeleteRegistryValue: Deleted Software\Policies\Microsoft\Windows\System\ShellSmartScreenLevel
GPSVC(4ec.66c) 08:58:41:308 DeleteRegistryValue: Deleted Software\Policies\Microsoft\Windows Defender\DisableAntiSpyware
GPSVC(4ec.66c) 08:58:41:308 DeleteRegistryValue: Deleted Software\Policies\Microsoft\Windows Defender\AllowFastServiceStartup
GPSVC(4ec.66c) 08:58:41:309 DeleteRegistryValue: Deleted Software\Policies\Microsoft\Windows Defender\ServiceKeepAlive
GPSVC(4ec.66c) 08:58:41:309 DeleteRegistryValue: Deleted Software\Policies\Microsoft\Windows Defender\RandomizeScheduleTaskTimes
GPSVC(4ec.66c) 08:58:41:310 DeleteRegistryValue: Deleted Software\Policies\Microsoft\Windows Defender\Exclusions\Exclusions_Paths
GPSVC(4ec.66c) 08:58:41:310 DeleteRegistryValue: Deleted Software\Policies\Microsoft\Windows Defender\Exclusions\Paths\c:\empirumagent
GPSVC(4ec.66c) 08:58:41:311 DeleteRegistryValue: Deleted Software\Policies\Microsoft\Windows Defender\Quarantine\PurgeItemsAfterDelay
GPSVC(4ec.66c) 08:58:41:311 DeleteRegistryValue: Deleted Software\Policies\Microsoft\Windows Defender\Real-Time Protection\DisableOnAccessProtection
GPSVC(4ec.66c) 08:58:41:311 DeleteRegistryValue: Deleted Software\Policies\Microsoft\Windows Defender\Real-Time Protection\DisableIOAVProtection
GPSVC(4ec.66c) 08:58:41:311 DeleteRegistryValue: Deleted Software\Policies\Microsoft\Windows Defender\Real-Time Protection\DisableScanOnRealtimeEnable
GPSVC(4ec.66c) 08:58:41:312 DeleteRegistryValue: Deleted Software\Policies\Microsoft\Windows Defender\Real-Time Protection\DisableBehaviorMonitoring
GPSVC(4ec.66c) 08:58:41:312 DeleteRegistryValue: Deleted Software\Policies\Microsoft\Windows Defender\Real-Time Protection\DisableRawWriteNotification
.
GPSVC(4ec.66c) 08:58:42:062 ProcessGPOList: Extension Registrierung was able to log data. RsopStatus = 0x0, dwRet = 0, Clearing the dirty bit
Der Fehlercode 0x80004005 kommt im Log nicht mehr vor. Markus schreibt, dass er das Ganze eindeutig reproduzieren kann. Seine erste Mutmaßung war, dass es möglicherweise an den Defender-Einstellungen liegen könnte. Bei Tests in den letzten Tagen mit diversen Szenarien gab es aber ein krudes Fehlerbild.
- Direkt nach der Installation eines Windows 10 V1909-Clients greifen die GPOs nicht.
- Lässt er nach dem Setup eines Windows 10 V1909-Clients den Windows Defender über die security filtering-Richtlinie für die Maschine wieder zu, scheint alles normal zu funktionieren.
Irgendwann ist er dann auf die Idee gekommen, den Windows Defender auf einem Client per 'Hand' zu aktualisieren, indem er nach Updates suchen ließ. Das Ergebnis: Die GPOs werden wieder (wie erwartet) angewendet!
Irgend eine Signatur/Engine ist verbuggt
Markus schließt daraus, dass die in der ISO-Installationsdatei für die Windows 10 Version 1909 verteilten Signaturdateien und/oder die Defender-Engine schlicht kaputt sind. Das würde die Probleme bei frisch installierten Testsystemen und das plötzliche Funktionieren der GPOs zu einem späteren Zeitpunkt erklären. Ihm ist aber nicht klar, warum die Aktualisierung des Defender nicht umgehend nach der Installation eines Clients passiert. Sein abschließender Kommentar:
Ich scripte mal schnell ein update via PowerShell in unser Deployment und schau ob das Problem damit wegzubekommen ist.
Mal sehen ob das cmdlet Update-MpSignature Abhilfe schafft.
Ergänzend wies mich Markus noch darauf hin, dass im Eventlog vom Defender nichts zu Problemen zu finden sei und zog folgendes Fazit: Kranke Sache kann ich da nur sagen schade um die Wochen Zeit und Nerven!
Die Frage an die Betroffenen wäre jetzt, ob diese Erkenntnisse bestätigt werden können. Wenn es am ISO-Installationsmedium liegt, könnte ich Microsoft einen Hinweis geben. Danke an Markus, dass er die bisherigen Erkenntnisse zur Veröffentlichung im Blog bereitgestellt hat – so profitieren Dritte davon.
Ähnliche Artikel:
Windows 10 V1909 und ein mögliches GPO-Problem
Anzeige
Könnte das vielleicht an der Tamper Protection liegen, die eine Deaktivierung des Defender verhindert?
https://www.borncity.com/blog/2019/03/28/potentielle-gpo-probleme-mit-windows-defender-tamper-protection/
Im ersten Logauszug oben steigt der Prozess genau beim Löschen des Registrywerts zur Deaktivierung des Defenders (DisableAntiSpyware) aus.
Grüße
Witziger weise is im ersten Logauszug der Defender aktiv und es können irrsinnig viele Registry Werte (auch Werte nicht den Defender betreffend) nicht geändert werden.
Gehe ich nun her und deaktiviere den Defender (GPO mit niederer Link order), wird alles Fehlerfrei angewendet.
Ist der Defender aktiviert und aktualisiert, dann werden die GPOs auch einwandfrei angewendet, sprich der einzige Unterschied zwischen funktioniert oder funktioniert nicht besteht in der Windows Defender Engine/Signatur Version.
Seitdem wir direkt nach dem domainjoin und vor dem reboot den Defender aktualisieren sind die GPO Probleme nicht wieder aufgetreten.
Wie löst ihr das im Deployment? Spielt ihr ein bestimmtes KB ein?
Wir verwenden dazu einfach das vorhandene PowerShell cmdlet
Update-MpSignature.
Unmittelbar nach dem domain join ziehen dann die GPOs sofort.
War der Rechner bereits "vergeigt", dann braucht es nach dem Update 2 reboots.
Was sagt MS dazu?
Ich kann das soweit bestätigen, als dass ich festgestellt habe, dass zuindest eine GPO bei uns so lange nicht angewendet wurde, bis der mit 1903 (nicht 1909!) installierte PC zum ersten Mal Windowsupdates bekommen hat und danach neu gestartet wurde. Auch hier wird der Defender verwendet.
Andere GPOs (die große Mehrzahl) wurden jedoch definitiv sofort angewendet.
Zum englischsprachigen Blog-Beitrag gibt es diesen Kommentar von abbodi1406, der Supportbeiträge zu Tamper Protection verlinkt. Erklärt aber nicht, warum der Effekt nach einem Defender-Update plötzlich funktioniert.
Einfach mal DANKE !
Heißt es nicht immer, der Defender ist so eine super Security-Lösung und wer einen Fremdhersteller einsetzt, sei einfach bescheuert? Weil sich Microsoft viel besser mit Microsoft auskennt?
SCNR :-D
Na sagen wir mal so, die Halbjahres-Upgrades, bspw. von 1809 auf 1903, oder auch 1909 wurden in der Vergangenheit immer wieder von Produkten wie die von Avast, oder Trendmicro WFBS erfolgreich verhindert.
Ja, das ist es.
Wir wundern uns seit Monaten, warum beim Deployment zufällig einige clients die GPOs nicht verarbeiten oder nur einige davon. Später nach etlichen Updates und Neustarts sind sie plötzlich da.
Das doofe daran ist, dass es auch die WSUS GPOs betrifft die nicht gezogen werden. Und damit zieht sich der Client wieder fröhlich bei Microsoft :(
Hoffe auf eine simple Lösung per Script o.ä.
Danke schon Mal für den Artikel
Ich hab mich auch gewundert und hatte Gott sei Dank einen Laptop bei dem es nie ging!
Auf andere Hardware trat das Problem nur gelegentlich auf, oder in ca. 50% der Fälle.
Bei uns hängt halt an den GPOs so ziemlich alles. Da merkt man sehr rasch wenn nichts mehr geht :)
Um welches ISO handelt es sich denn?
Windows 10 (consumer editions), version 1909 (x64) – DVD (German)
de_windows_10_consumer_editions_version_1909_x64_dvd_b55d1390.iso
bff5dbffce66e2bde1a3c4b61ee963832a961923
Gruss
Alitai
VLSC iso.
Ich kann mir allerdings nicht vorstellen, dass sich die Engine/Signaturen des Windows Defenders in der ISO unterscheiden (würde meiner Meinung nach keinen Sinn machen).
Wir haben unter 1909 dasselbe Problem. Die Verarbeitung der Registry-CSE wird plötzlich mit 0x80004005 abgebrochen. Wir haben das Problem aber nur auf neuer/schneller HW (mit SSD). Auf alter HW (mit HD) tritt es NICHT auf.
Vielen, vielen Dank!
Innentisches Setup für zwei Kunden bereitgestellt. Den ersten mit 1903 (kein Problem) den zweiten mit 1909 und sämtliche Registry GPOs zogen nicht oder erst nach einem willkürlich erscheinendem Zeitraum.