[English]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 (Build 26200.7623) 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. Ergänzung: Aber es ist noch komplexer – obiger Screenshot zeigt den reduzierten Wert. Ich habe es nun in einer VM mit Windows 11 25H2 Pro (Build 26200.7623) erneut getestet. Jetzt bleibt der Dezimalwert "4294967295" im Feld erhalten (deckt sich mit dem Kommentar von Bolko weiter unten).
Eine mögliche Erklärung
Mark hat in seinem Beitrag hier eine mögliche Erklärung 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?
Hier kommt der Hinweis ebenfalls (Win11, 25H2).
Bist Du sicher, die korrekte Zahl — also eine zu große — eingegeben zu haben? Ich habe bewusst eine viel zu große eingegeben, einfach die '4'-Taste lange festgehalten und anschließend übernehmen geklickt. Dann kam der Hinweis, dass der Wert auf 2^31 – 1 zurückgesetzt wird.
Wenn das bei Dir nicht der Fall ist, dann … tja, entweder fällt Dein System in die Kategorie "nicht betroffen", oder aber die verursachende Bibliothek ist noch im alten Zustand oder bereits wieder gefixt — falls Fix vorhanden.
Schwierig, schwierig, ist bei dem System wie Glaskugel schauen und Teesatz lesen.
Ich habe den Wert von Mark per Copy & Paste übernommen und zur Sicherheit probiert, über das Drehfeld den Wert zu erhöhen, geht aber nicht.
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.
Danke. Das wäre sonst wirklich komisch geworden :-)
d.h. das der Fehler irgendwann nach 09.2025 als Update integriert wurde. :-(
Ich blicke nicht mehr durch (zu viele Bäume im Wald) – gerade noch auf einem Windows 11 25H2 in einer VM getestet. Nun wird der eingegebene Wert beibehalten – habe es oben im Text schon nachgetragen. Das Problem muss tiefer liegen – da Bolko es nicht nachstellen kann, bei mir auch nicht reproduzierbar ist, von anderen Lesern aber auch als Bug bestätigt wurde. Ich mache für heute mal Pause.
Irgendwann um November 2025 wurde ja ebenfalls das Hoppala von "Set-GPPrefRegistryValue" beim Schreiben von String Values "implementiert", wo das letzte Zeichen des Strings abgeschnitten wurde. Möglicherweise ist das ebenfalls bereits ab September passiert? "Set-GPPrefRegistryValue" wurde ja immerhin mit dem April Patchday 2026 gefixed.
Wer weiß, was in diesem "legacy Bereich" von Microsoft gerade getan wird. :-)
Der zweite Teil des Artikels von Mark Heitbrink ist ebenfalls beängstigend, weil Windows manchen GPO-Zustand "Aktiviert" mit dem Wert 4294967295 kodiert.
Wenn dieser Wert jetzt aber falsch ausgewertet oder falsch geschrieben wird aufgrund des signed-INT-Überlaufs, dann wird die GPO eben gar nicht aktiviert, obwohl sie so eingestellt worden ist.
Dann sieht man zwar im Gruppenrichtlinieneditor die aktivierten Richtlinien und fühlt sich sicher, aber die Richtlinien sind eventuell trotzdem aus.
2.
Ist das vielleicht ein Problem mit gewissen Versionen von NET Framework oder NET Desktop oder VisualC Runtimes, die durch die Datei gpedit.dll benutzt werden?
Welche Versionen davon haben denn diejenigen installiert, bei denen der Fehler auftritt?
Die gpedit.msc benutzt:
gpedit.dll und diese wiederum benutzt
mmc.exe und diese wiederum benutzt (laut Process Explorer, Properties von mmc.exe, Reiter ".NET Assemblies")
NET 4.0.30319.0 (NET Framework 4 x64, identisch bei meinen Win10 und Win11),
dort sieht man dann die kompilierten NET-Assemblies im Ordner C:\Windows\Assembly.
Bei Windows 10 sind es 5 Assemblies und bei Windows 11 sind es 11 Assemblies.
Eventuell wurden auf den betroffenen fehlerhaften Systemen diese Assemblies mit einer fehlerhaften NET Version kompiliert?
In meinem Win11 habe ich NET Framework 4.8.1 installiert (Release-Version-Code 533509 in der Registry).
In Windows 10 habe ich ebenfalls NET Framework 4.8.1 installiert (Release-Version-Code 533325 in der Registry).
steht dort in der Registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full