Der Gruppenrichtlinien-Editor (gpedit.msc oder gpmc aus den RSAT Tools) ist in Windows 11 "kaputt", macht er doch auf Grund eines Bugs nicht, was ihm vom Administrator aufgetragen wird. Eingetragene Werte werden nicht übernommen, sondern wegen eines Überlauffehlers reduziert und dann gespeichert. Mark Heitbrink hat es im März 2026 an Microsoft gemeldet, ist bisher ohne Reaktion geblieben.
Leserhinweis von Mark Heitbrink
Mark hatte mich zum 5. Mai 2026 per Mail mit dem Betreff "Warum die PAW ein Server ist (sein sollte)" kontaktiert und mich darauf hingewiesen, dass sowohl gpedit.msc als auch die gpmc aus den RSAT Tools einen gravierenden Fehler auf einem Windows Client OS zeigen.
Mark hat es auf Windows 11 24H2 und 25H2 reproduzierbar getestet, und ich habe eben einen Test auf Windows 10 IoT 2019 Enterprise LTSC, Windows 10 22H2 Pro sowie auf Windows 11 25H2 Pro gefahren. Der Gruppenrichtlinien-Editor gpedit.msc verändert unter Windows 11 24H2/25H2 beim Speichern die vom Administrator vorgegebenen Werte.
Der Fehler tritt wirklich nur auf Windows 11-Clients auf, auf einem Windows Server wird der Testwert korrekt gesetzt, wie Mark bei Tests festgestellt hat. Ich habe es unter unter Windows 10 IoT 2019 Enterprise LTSC und 22H2 nicht reproduzieren können (hoffe, mir ist auf die Schnelle kein Fehler unterlaufen und ich habe vor lauter Bäumen den Wald nicht mehr gesehen).
Dazu schreibt Mark, dass er den Bug Ende März 2026 bei MS Research ("Submission number: VULN-180447, Case number: 111952") gemeldet. Aber außer einer automatischen Antwort "Wir haben es erhalten, Danke schön" gab es bis jetzt keine weitere Rückmeldung.
Den Fehler reproduzieren
Mark hat das Ganze inzwischen auf gruppenrichtlinien.de im Beitrag Kaputt: GPEdit und GPMC am Client – Stand 05.2026 beschrieben. Um das Problem zu reproduzieren, ruft man entweder gpedit.msc des Clients oder gpmc aus den RSAT Tools unter Windows 10 bzw. Windows 11 auf. Dann navigiert man im Gruppenrichtlinien-Editor zu folgendem Zweig:
Computer Configuration\ Administrative Templates\ Windows-Komponenten\ Übermittlungsoptimierung\
oder in Englisch zu
Computer Configuration\ Administrative Templates\ Windows Components\ Delivery Optimization\
Dann wählt man die Gruppenrichtlinie Vordergrunddownload von HTTP verzögern (in Sekunden) (Englisch Delay Foreground download from http (in seconds)) an.
Im Anschluss versucht man im Richtlinieneditor den Dezimalwert "4294967295" (FFFF FFFF) im betreffenden Feld der aktivierten Gruppenrichtlinien einzutreten.
Bei mir schließt sich das Dialogfeld des Richtlinieneditors kommentarlos und die Richtlinie wird aktiviert. Kontrolliere ich anschließend diese Richtlinie unter Windows 10 IoT 2019 Enterprise LTSC, findet sich der eingetragene Dezimalwert "4294967295" in der Anzeige (siehe obiges Dialogfeld). Unter Windows 11 25H2 wird mir allerdings das in nachfolgendem Screenshot gezeigte Ergebnis angezeigt.
Der Richtlinien-Editor hat den Wert auf "2147483647" dezimal (7FFF FFF) reduziert. Mark hat in seinem Beitrag hier eine mögliche Ursache angegeben. Dennis Lange und Stefan Kanthak vermuten, dass der Windows Cient den Datentyp INT statt unsigned INT verwendet. Dann kommt es beim Wert2**31 – 1 = 2147483647 zu einem Überlauf. Beim Lesen der *.ADMX nach LONG alias INT statt DWORD alias "unsigned INT" konvertiert der Richtlinien-Editor den Wert und verändert diesen.
Abweichend zur Beschreibung von Mark bekomme ich aber keinen Dialog mit einem entsprechenden Hinweis angezeigt. Markt schreibt "Es gibt über 50 Richtlinien mit dem MaxValue problem, verteilt über OS, Defender und Office Richtlinien." und erläutert in seinem Artikel weitere Details. Kann das jemand von Euch nachstellen?
MVP: 2013 – 2016
Die Vermutung ist sehr wahrscheinlich richtig.
Was fraglich ist, ist wie man dazu kommt ein funktionierenden Code mit einem verbeugtem zu ersetzen.
Ich meine wer setzt sich hin, vor funktionierenden Code, sieht oh das ist ein DWORD machen wir doch ein LONG daraus.
Das muss doch so ein AI misst sein die haben eine AI über die ganze Codebasis laufen lassen und dann alle Empfehlungen ohne nach zu denken übernommen, vermute ich mal.
Ich denke, der Fehler liegt nicht direkt im Gruppenrichtlinieneditor, sondern in irgend einer Bibliothek, (möglicherweise C Runtime). die völlig unabhängig bei Windows 11 verschlimmbessert wurde und jetzt diesen Seiteneffekt hat.
Von diesem Dialogfeld bis hin zum Registry-Value, der damit beeinflußt werden soll ist es doch ein recht weiter Weg mit vielen beteiligten Softwarekomponenten und letztendlich ist auch das Design der Registry schuld, die nur REG_DWORD als 32-bittigen Wert kennt und keinen direkten Unterschied beim Vorzeichen macht.
DWORD ist 32bittig, ja.
Wenn du einen 64bittigen Wert in der Registry brauchst, dann ist QWORD der richtige Wert.
Workarround für das Verhalten:
Registry-Key direkt in den GPOs setzen.
Win 25H2 aktueller Updatestand
Wie bei Marc – Hinweis im Dialog wird angezeigt.
Hast Du das mit gpedit.msc getestet – als Administrator? Ich habe den Hinweisdialog in der VM nicht zu Gesicht bekommen – was mache ich falsch?
Wenn ich meine fertige Dateien in der aktuellen 25h2 Pro nach:
C:\Windows\System32\GroupPolicy (Machine und User) kopiere
(ohne alte die Datei: C:\Windows\System32\GroupPolicy\gpt.ini)
und dann einmal: gpedit und gpupdate /force "laufen lasse",
tritt dann auch dieser Bug auf? (hier nicht)
Nein. Es geht um den Schreibvorgang des Editors in das C:\Windows\System32\GroupPolicy\Machine\registry.pol File. Werte die drin sind, bleiben wie sie sind. Du müsstest einen der betroffenen Werte erneut editieren, danach sind sie falsch.
"Windows 10 IoT Enterprise LTSC 2021 Build 19044.7184" funktioniert korrekt.
"Windows 11 Pro – Version 25H2 – Build 26200.6584" (09.September 2025) funktioniert hier ebenfalls korrekt.
Der eingegebene Wert 4294967295 bleibt erhalten, nach Klick auf OK, schließen des Gruppenrichtlinieneditors und Neustart des Gruppenrichtlinieneditors.
Test mit gpedit.msc als Administrator.
Jetzt könnte man noch herauszufinden versuchen, ab welchem Patchlevel Windows 11 versagt.
Automatische Updates habe ich mittels deaktiviertem Netzwerkadapter der VM verhindert.
Schau mal in die Registry, wie der Wert am Client ankommt. Rein interesse halber. Er sollte stimmen, da der Editor ihn schon richtig anzeigt.
2 gute "Übersetzer" von Policy to Registry und ViceVersa
https://gpsearch.azurewebsites.net/
https://admscope.com/admx/ *neu*
Key: HKLM\SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimization
Value: DODelayForegroundDownloadFromHttp
Registry:
hex: ffffffff
dez: 4294967295
alles ok.