[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. Zumindest hat ein Blog-Leser diese Erfahrung in einer Testumgebung gemacht. Nachtrag: Es gibt einen Hinweis, wie sich das korrigieren lässt.
Anzeige
Blog-Leser Markus K. betreibt an einer Uni in Österreich einige Testsysteme mit dem Windows 10 November 2019 Update (Version 1909) und wollte sich mit dem Thema Gruppenrichtlinienbereitstellung für die Windows-Clients befassen. Dabei ist ihm ein Problem aufgefallen. Markus schrieb mir vor Weihnachten:
Wir versuchen seit geraumer Zeit 1909 in unserer Testumgebung auszurollen.
Da wir jede Menge GPOs haben ist es essenziell, dass diese auch greifen.
Nun kommt der lustige Teil, manchmal klappt es und manchmal nicht :).
Markus gibt dazu an, das die Windows 10 Version 1809 Rechner nie Probleme mit der Verteilung der GPOs haben. Bei den Rechnern mit Windows 10 Version 1909 sei es einfach Zufall, ob eine Gruppenrichtlinie greife oder nicht.
Markus schrieb mir, dass weder die Ereignisprotokolle (Eventlog) noch GPSVC Log da besonders viel sinnvolles aussagen. Im GPSVC-Log sieht Markus allerdings, dass gleich mal die CSE Registry in die Hose geht und eine Art Fehler (permission denied?) gemeldet wird. Und es kommt noch doller, wie Markus festgestellt hat:
Lustig, dass wenn man manuell irgendwann nach geraumer Zeit "gpudate /force" anwirft, klappt nach dem nächsten reboot die Anwendung der Gruppenrichtlinien.
Das Problem betrifft auch nicht alle Windows 10 Version 1909-Clients. Markus schreibt dazu folgendes:
Anzeige
Andere [Windows 10] V1909 [Clients] werden installiert und sind nach einem marginalem delay prompt brauchbar.
Markus meint dazu: Für mich schaut das nach Random Bug aus, was die Diagnose besonders angenehm gestaltet. Die haben alleine in der Testumgebung allerdings an die 700 GPO Objekte, was das das ganze Debugging nicht gerade einfacher macht. An der Stelle fragt er, ob etwas bekannt ist, oder jemand was in diese Richtung gehört hat. Dann wäre er und wohl der Rest der Blog-Leser dankbar für jeden Tipp. Danke für den Hinweis.
Nachtrag: Es gibt einen Hinweis, wie sich das korrigieren lässt. Blog-Leser Carsten Vollrath hat im englischsprachigen Beitrag diesen Kommentar mit einem Link auf diese Azure-Webseite gepostet. Carsten hat die dort aufgeführte Richtlinie Configure security policy processing gesetzt und die Probleme sollen weg sein.
Auflösung in: Windows 10 V1909 und ein mögliches GPO-Problem – Teil 2
Anzeige
Hallo zusammen,
dieser Fehler kommt bei uns genau so vor.
Upgrades von 1809/1903 auf 1909 waren noch nicht betroffen ausschließlich neu Installationen.
Hat jemand hierzu einen Workaround?
Mit freundlichen Grüßen
CS
Hallo! Ja, mir ist das schon im Juli aufgefallen, als ich mich kurz mit Windows 10 1903 gespielt habe (https://twitter.com/DHaimann/status/1156254728042553345). Leider habe ich keine Antwort bekommen. Habe das im Feedback Hub gemeldet, aber das dürfte umsonst sein.
Den unten erwähnten Hybrid-Start deaktivierst du mit POWERCFG.exe /H OFF.
Mit 1909 ist mir jetzt noch nichts untergekommen. Allerdings fangen wir gerade an zu testen. Ich dachte eigentlich, dass das eine Eintagsfliege war… :-(
Hallo DHaimann.
Vielen Dank.
Werde ich nach meinem Urlaub jedenfalls ausprobieren.
Mit freundlichen Grüßen
Christian
Ich konnte bis jetzt nichts feststellen. Arbeite aber auch mit gpupdate /force. Die PolicyDefinitions sind schon die von 1909?
https://www.microsoft.com/en-us/download/100591
Falls ich was testen soll, schreibe mir mal ein Beispiel.
Gruss
Alitai
Ist der Server ein 2019er? Falls nicht liegt's sicher daran (system requirements).
Die neuen ADMX templates sollte man nur brauchen, wenn man neue Funktionalität von 1909 konfigurieren will.
Sollten alte GPOs ein neues OS kaputt machen wird es lustig :)
Wieso sollte man einen Server 2019 brauchen und für was?
https://www.microsoft.com/en-us/download/100591
Schau da mal unter System Requirements.
Da du aber mit 1903 admx Dateien arbeitest, bist du davon nicht betroffen. Ob dies nun die Probleme verursacht, weiss ich nicht.
Gruss
Alitai
Das heisst, dass diese ADMX Templates auch für den Server 2019 funktionieren. Es heisst ja Supported…
Supported Operating System
Windows 10, Windows Server 2019
Dann schau bitte hier auch noch…
https://www.microsoft.com/en-us/download/details.aspx?id=58495
Es scheint nicht "auch" sondern "nur" zu sein.
Also ich sehe dort kein "nur". Davon abgesehen: Was machen denn ADMX-Templates? Die machen nichts anderes, als dem Admin eine GUI bereitzustellen, um verschiedenste Registry-Keys auf den Zielmaschinen auszurollen. Es gibt keinerlei Grund, warum zum Setzen von Registry-Werten ein 2019er Server benötigt werden sollte.
Bei einem Clientupgrade dreht Microsoft (leider) gerne den Hybrid/Fast(oder ähnlich)-Boot wieder auf, was dazu führt, daß die Clients nur selten (meist erst nach Windowsupdates) rebooten. Dann ziehen erst einige GPOs wie z.B. Softwareinstallationen via GPO.
Mal auf den unterschiedlichen Rechnern die Uptime vergleichen. Denn wenn ein gpupdate /force /boot den Reboot erzwingt wär das eine Erklärung.
Viel Glück!
Dietmar
@Dietmar
Danke, schau mir das setting im BIOS mal an, ob das mal gekippt ist.
Prinzipiell machen wir in unserer Testumgebung keine Upgrades.
Ein gpupdate /force klappt leider auch nur bedingt und das oft erst nach 2 Tagen :).
Ich habe noch nie mit dem switch /boot gespielt, aber ich berichte.
Hallo Markus,
was mir zu dem Thema einfällt (Prüfe hier mal die Einstellungen, bzw. setzte den Wert auf "deaktiviert"):
Computerkonfiguration Administrative Vorlagen system gruppenrichtlinie "Zwischenspeichern von Gruppenrichtlinien konfigurieren"
Vielleicht hilfts ja weiter… Gruß Markus B.
Hallo Markus,
ist ein Versuch Wert.
Für mich immer wieder schön zu sehen, dass Microsoft an bereits funktionierenden Sachen "schraubt" und diese kaputt macht. Gott sei Dank müssen wir 1909 erst im Sommer 2020 einsetzen :)
LG, Markus K.
Ich bin ganz bei Dietmar, glaube aber NICHT, dass das was mit 1909 zu tun hat. Das gleiche Probleme haben wir auch bei 1809 LTSC, mal geht's, mal geht's nicht. Manche Clients haben das Problem gar nicht, manchen bekommen gar keine GPOs mehr. Ich suche deswegen schon seit Monaten im Netz und habe unendliche Stunden deswegen verbracht.
Ich kann euch nur empfehlen, schaut euch mal die Netzwerkkarten an. Bei Intel Karten gibt's Wait on LAN bzw. Auf Verbindung warten. Das muss explizit auf Aktiv gestellt werden.
Die Clients booten durch SSDs und M2 Karten einfach zu schnell, Windows ist deswegen viel zu schnell da, die Netzwerkarte aber noch gar nicht. Deswegen hagelt es immer wieder GPO Ladefehler im Eventlog. Baut man in den gleichen Rechner eine alte HDD ein, sind die Probleme weg! Das kann man natürlich nicht ständig machen, ist ja auch quatsch, aber die Netzwerkkarten Einstellungen sollten helfen. Dummerweise gibt's das nicht bei Realtek und Broadcom. Aber irgendwas mit Green Ethernet, Energiespar Modi usw., die man besser abschalten sollte, helfen leider aber nicht immer.. Aktuell experimentiere ich mit dem Haken "Computer kann das Gerät ausschalten, um Energie zu sparen" ebenfalls im Geräte Manager. Ich kann aber noch nichts genaueres dazu sagen.
Richtig hart wirds bei Tablets und Notebooks, welche nur über WLAN angebunden sind. Da gibt's diese Optionen im WLAN Modul gar nicht und das WLAN ist IMMER zu spät verbunden und der Client spricht nicht mehr mit der Domäne. Da habe ich immer noch keine Lösung.
Bitte bitte bitte, wenn jemand irgendeine gute Idee hat, immer her damit. Mich macht das Problem wahnsinnig. Vielleicht finden wir ja endlich gemeinsam eine richtige Lösung dafür.
1. Powershell script (gpupdate /force) per gpo ausrollen
2. Bei MS beschweren
3. In die Cloud wechseln ;)
Hoffen wir auf Besserung in 2020. Habe fertig.
Gruss
Alitai
Das klappt leider nicht. Die werden trotzdem nicht geladen, weil der Client nicht mit der Domäne plaudert
Das Problem "zu schnell" ist kein Problem aus GPO Sicht. Deswegen laufen GPOs ja im Hintergrund per Default alle 90 Minuten +-30.
Es braucht nur für 3 CSEs einen Vordergrundprozess (Scripts, GPSI, Ersteinrichtung Folder Redirection) und damit eine Netzwerkverbindung.
Der Fehler ist nur in eurem Kopf. Ihr wollt "JETZT", aber das braucht es nicht, Es reicht, wenn die GPO "im Laufe des Tages" ankommt. JETZT ist ein reines Adminproblem.
Verlagere die Scripte in die Aufgaben Planung, verwende eine Softwareverteilung, Problem erledigt.
Hallo Mark und Heiko,
Danke für eure Antworten. Mark ich weiß worauf du hinauswillst, aber leider müssen unsere GPOs laufen. Ich kann die auch nirgendwo anders "einbauen".
Ich weiß nicht ob du Drivelock kennst, damit verschlüsseln wir die Platten der Rechner. Damit die User sich daran auch amelden können, müssen sauber die GPOs geladen werden, damit die User Zugangsdaten lokal gesynct werden können. Ändern die ihr Kennwort wird das erst bei einer sauberen Domänenverbindung übernommen. Ansonsten müssen die User ständig ihr altes Kennwort eingeben, das versteht ja keiner, einfach furchtbar.
Oder wir nutzen VMware UEM/DEM. Das ist unsere Profillösung. Diese MUSS bei der Anmeldung laufen, sonst fehlt dem User seine Umgebung, das bringt nichts wenn die GPO erst 30min später geladen wird.
Natürlich ist auch die Policy gesetzt, das auf die Netzwerk Verbindung gewartet wird und das die GPOs synchron abgearbeitet werden. Interessiert aber wie gesagt nicht alle Rechner. Ich werd trotzdem mal den Defender ausprobieren. Wir haben auch die Firewall aktiviert, die ist mir gerade noch in den Sinn gekommen.
Meine Kollegen meinten, vielleicht kann man irgendwie eine Pause oder irgendwas einbauen, das der Rechner erstmal eine Aufgabe etc abarbeitet? Mir ist aber nichts bekannt, wie man das machen soll. Das erste was geladen wird sind die GPOs, alles anderer kommt erst danach.
Hallo Soda.
Hast du zufällig GPOs gesetzt, die den Defender oder dessen Komponenten in irgendeiner weise abschalten?
Wenn ja, dann entferne die GPOs mal und schaue ob es geht.
Erklärung: Die GPOs, die den Defender abschalten, legen unter bestimmten Bedingungen den Grouppolicy-Client lahm. (Siehe mein Kommentar weiter unten!) – Microsoft ist das Problem schon länger über den Feedback-Hub bekannt. (Wie meistens.)
@Soda:
Hallo Soda.
Ich glaube mein Kommentar war hier doch nicht ganz passend. Ich hatte vorhin nur schnell deinen Kommentar überflogen.
Ich beobachte das auch, aber nur bei GPOs, die per Sicherheitsfilter auf bestimmte AD-Gruppen angewendet werden sollen. Mal gehts, mal nicht. Erschwerend kommt bei diesen GPOs hinzu, dass sie sowieso schwierig überprüfbare Settings durchführen, Applocker-Regeln die nur für bestimmte Gruppen gelten sollen und per rsop.msc ohnehin nicht angezeigt werden. :(
Laut GPSVC Log passiert beim security filtering bei uns nichts seltsames.
Die erste CSE die verarbeitet wird ist der Registry und hier haben wir schon das Problem, das sich dann durch und durch fortsetzt.
Jedenfalls schön zu lesen, dass wir nicht die einzigen mit 1909 und special effects sind :)
Übrigens, bei focus.de läuft gerade wieder Beschiss, Windows 7 auf 10 Upgrade-Lizenzen über so einen Lizenz-Dealer für 19 Euro… Dabei gehts immer noch kostenlos…
https://www.focus.de/deals/shopping-deal-mit-focus-online-windows-10-pro-key-aktuell-fuer-nur-19-99-euro-denn-support-fuer-windows-7-endet_id_11179663.html
Es gibt 4 Probleme seit Windows 8.1: Fastboot, Fastboot, Fastboot und GPO Caching.
Das ist das der größte Mist und zeigt genau das beschriebene Verhalten. Der Fastboot cached die alten GPO Settings. Zusätzlich kann das OS seit 8.1 die GPO lokal cachen.
Wird beides deaktiviert geht es sofort. Fastboot sollte schon in der Installation per "Preference" Registry Key verteilt werden, es geht auch als GPO, aber die kommt ja gerade nicht an ;-)
Wobei Fastboot die größte Fehlerquelle ist. Ich habe ihn seit 8.1 in keiner Installation mehr aktiv und es ist das erste was ich abschalte.
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Power" /v "HiberbootEnabled" /t REG_DWORD /d 0 /f
GPO Caching:
http://matthiaswolf.blogspot.com/2014/01/group-policy-caching-sinnvoll-oder.html
Der Cache ist sinnvoll, wenn ihr Techniken wie DirectAccess/AlwaysOn nutzt, da es sonst zu einer online GPO Anfrage über die Verbindung bei Start kommt und das kann aus Performance Sicht schlimm werden. Stichwort Datenmenge und Latenz.
Fastboot ist bei uns im deployment deaktiviert => nur Probleme.
Das GPO caching war bis jetzt nicht explizit abgedreht, aber nächste Woche werde ich es mir ansehen.
Ich finde es in unserem Fall etwas seltsam, dass das Problem genau nur mit 1909 auftritt, aber die Vorbereitungen auf ein Featureupgrade waren noch nie problemlos, da sich Microsoft leider nicht nur bei den "features" zu spielen scheint.
Ich berichte, sobald ich neue Erkenntnisse habe.
Habe nun "Configure Group Policy Caching" auf disabled gesetzt, das hat allerdings keinen Einfluss. Fastboot ist bei allen Geräten im BIOS abgedreht.
Ich werde nun schauen ob es etwas bringt, wenn man das "policy processing" der entsprechenden CSE konfiguriert. Bei mir ist ja bereits in der Registry aus => nichts funktioniert wie es soll.
PS: der Rechnern war nun 2 Wochen ausgeschalten => eingeschalten, etwas laufen gelassen, Windows Updates installiert und nach dem reboot griffen die GPOs!
Also total logisch :)
… und ganz nebenbei: Könntet ihr bitte mit dem Quatsch aufhören "gpupdate /force" als Lösung anzubieten?
FORCE ist nur notwendig, wenn man per Hand dran herumgefummelt hat.
/Force Wendet alle Richtlinieneinstellungen erneut an. Standardmäßig werden nur geänderte Richtlinien angewendet.
… und im Gegensatz zum normalen gpupdate ist es nicht "silent", d.h. es sagt, wenn es neustarten/abmelden möchte.
Hallo.
Das erinnert mich an ein ähnlich gelagertes Problem bei uns mit Win10 1903. (Mit 1909 habe ich da keine Erfahrung, da nicht getestet.)
Hier hatten die Clients keine GPOs, nur einen Teil der GPOs oder reichlich verzögert erst die GPOs angewandt. Laut Ereignisanzeige war alles okay. GPRESULT sagte auch es sei alles okay, zeigte aber keine Einstellungen an. Lediglich RSOP zeigte einen unbekannten Registry-Fehler.
Ursache: Sobald eine Konponente des Defender (3 GPOs so oder ähnlich: Defender deaktivieren, Echtzeitschutz aktivieren, Scan aktivieren) deaktiviert ist, kann der GPO-Client die Richtlinien nicht korrekt verarbeiten.
=> Lösung war, den Defender nicht abzuschalten.
Soweit ich weiß, passiert das insbesondere wenn Application-Guard aktiv ist. Es gibt auch im Feedback-Hub Einträge hierzu. (Schon unter 1809 glaube ich.)
Vielleicht hilft mein Kommentar ja einigen.
Frohes neues Jahr.
Danke für den Tipp. Das Deaktivieren der drei genannten Einstellungen alleine hat zwar bei mir (W10 1903) nicht direkt funktioniert, allerdings werden alle Defender-Einstellungen bei mir über eine dedizierte GPO verteilt. Nachdem ich diese temporär deaktiviert hatte, wurden plötzlich wieder alle anderen GPOs angewendet.
Das Problem ist auf meinem Testsystem reproduzierbar, d.h. sobald ich die Defender-GPO wieder _aktiviere_, werden die GPOs nicht mehr korrekt angewendet. Das Spielchen lässt sich wiederholen mit den jeweiligen Ergebnissen.
Im GroupPolicy-Eventlog taucht dann mehrfach die ID 7016 auf, gpresult /h zeigt mehrere Fehler sowie im Komponentenstatus, dass die Komponente Registrierung "aufgrund des unten aufgeführten Fehlers fehlgeschlagen" ist, wobei der "unten aufgeführte Fehler" ein "Unbekannter Fehler" ist.
Das Problem dürfte somit tatsächlich an den Defender-Einstellungen liegen, nur welche (Kombination) dafür ausschlaggebend ist, habe ich bislang nicht rausfinden können.
Es sind ja viele Kommentare zum Thema hier eingeschlagen. Zum englischsprachigen Blog hat sich Carsten Vollrath gemeldet. Er hatte einen Support-Case bei Microsoft eröffnet und den Hinweis erhalten, die Richtlinie Configure security policy processing zu setzen (siehe auch meine Nachträge im obigem Text). Danke an Carsten und Alle, die hier beigetragen haben.
Danke Günter.
Wobei ich dazu sagen muss, dass dies "gpupdate /force" gleichkommt oder dann halt nur noch beim an und abmelden die GPOs übernommen werden. Es geht auch beides.
Die Richtlinie scheint also irgendwo einen Bug zu umgehen.
Bin auf Rückmeldungen gespannt.
Die Richtlinie in Deutsch heisst: "Sicherheitsrichtlinienverarbeitung konfigurieren".
Gruss
Alitai
Danke Günter!
Wobei ich dazu sagen muss, dass dies "gpupdate /force" gleichkommt oder dann halt nur noch beim anmelden oder neustarten die GPOs übernommen werden. Es geht auch beides.
Die Richtlinie scheint also irgendwo einen Bug zu umgehen.
Bin auf Rückmeldungen gespannt.
Die Richtlinie in Deutsch heisst: "Sicherheitsrichtlinienverarbeitung konfigurieren".
Gruss
Alitai