Blog-Leser Martin F. hat mich in einer E-Mail auf ein Problem aufmerksam gemacht, in welches er bereits im Juni 2026 bei der Windows-Update-Installation gelaufen ist. Auf einigen Clients schlug die Update-Installation aus "unerfindlichen Gründen" fehl. Nach einer Analyse stellte sich heraus, dass die RSAT-Tools wohl der Verursacher sind. Ich nehme die Information mal kurz auf, vielleicht hilft es Betroffenen.
Martin schrieb mir (danke dafür) "Zuletzt sind bei ein paar Windows-Desktops die Windows-Updates fehlgeschlagen. Nur auf wenigen Computern, obwohl ja eigentlich alle identisch installiert sind." Nachfolgender Screenshots zeigt ein Juni 2026-Update für Windows 11 25H2 was nicht erfolgreich installiert werden konnte.
Der Leser hat sich dann die CBS.log angeschaut und konnte dort die RSAT-Tools ((Remote Server Administration Tools) als Verursacher ausmachen.
Martin schrieb mir dazu: "Die Programme sind auf dem Datenträger vorhanden und lassen sich ausführen."
Er hat dann die RSAT-Tools mittels eines PowerShell-Kommandos von den betreffenden Clients entfernt.
Nach der Deinstallation der RSAT-Tools wurde das Update dann ohne Fehler installiert.
Vielleicht hilft es Betroffenen, wobei ich mal davon ausgehe, dass die RSAT-Tools eher nicht breit auf Clients installiert werden, sondern eher bei Administratoren werkeln.
MVP: 2013 – 2016
I have these installed, both June & July updates installed fine for me on Win 11 25H2 Pro. But I install updates from Windows Update, not from WSUS.
Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0
Rsat.CertificateServices.Tools~~~~0.0.1.0
Rsat.Dns.Tools~~~~0.0.1.0
Rsat.FileServices.Tools~~~~0.0.1.0
Rsat.GroupPolicy.Management.Tools~~~~0.0.1.0
Rsat.NetworkController.Tools~~~~0.0.1.0
Rsat.RemoteAccess.Management.Tools~~~~0.0.1.0
Rsat.RemoteDesktop.Services.Tools~~~~0.0.1.0
Rsat.ServerManager.Tools~~~~0.0.1.0
Rsat.WSUS.Tools~~~~0.0.1.0
Habe keine Probleme trotz RSAT Tools. Update kam bei uns heute per WSUS.
Update zu:
https://borncity.com/blog/2026/05/08/windows-11-clients-die-gruppenrichtlinien-editoren-gpedit-msc-und-gpmc-sind-kaputt/
der Fehler besteht weiterhin, aber das Pop-up "Die Anzahl in diesem Feld war größer…" erscheint nicht mehr.
auch eine Möglichkeit der Korrektur :-D
Moin.
Mit dem genannten Problem schlage ich mich seit Anfang des Jahres jeden Monat mit mehreren Clients rum. Manchmal funktioniert die Installation der Updates, manchmal nicht. Dann hilft tatsächlich nur das Entfernen und anschließende Hinzufügen der RSAT Tools.
Falls hier jemand eine Lösung für das Problem kennt, wäre ich sehr dankbar, weil das jeden Monat wahnsinnig viel Zeit frisst.
Grüße
Ich hab den Blog auch nur mit meinem Einzelschicksal gefüttert. Wenn dir irgendwo der Schuh drückt, dann immer rein damit (gerne mit Lösung), dann spart sich der Nächste Zeit bei der Fehlersuche :-)
Die RSAT-Tools gehören auch nicht auf die lokale Admin-Workstation, wo der Admin Email empfängt und im Internet surft. Die RSAT-Tools gehören auf einen speziell gehärteten Admin-Terminalserver in Tier-Ebene 0 des AD.
Diese Aussage hätte ich jetzt übrigens vom allseits geschätzten Mark Heitbrink in seinem Kommentar erwartet.
Wie schrieb mir der Leser: "die folgende Information nimmst Du nicht in den Text, weil dann wieder zig Leute eine überflüssige Diskussion vom Zaum brechen, warum die RSAT-Tools nicht auf einen Client gehören …". Der Leser hat seine Gründe, die ich hier nicht erläutern möchte, kennt aber die Leserschaft so gut, dass er genau diesen Kommentar vorhergesehen hat. Das sollte also nicht weiter ausgeführt werden.
Gibt auch lesenden Zugriff für RSAT. Und würde keck behaupten 90% aller ADs kennen kein Tiering. Dürfen die nicht administrieren?
Und dann mit T0? Die "tägliche" Administration geschieht hoffentlich nicht in T0.
Als Entwickler brauche ich regelmäßig die RSAT Tools, alleine schon für meine ADAM Instanzen.
Welche zusätzlichen Rechte im AD oder auf Remoteservern verschafft einem Standardbenutzer das Vorhandensein der RSAT-Tools? Genau: gar keine.
Die RSAT Tools werden auf den Workstations dann wenigstens hoffentlich per "Ausführen als" mit einem zu der jeweiligen Aufgabe in der Domäne passenden Account ausgeführt (also nicht schweizer Taschenmesser Domain-Admin!), und hoffentlich hat nicht der normale Workstation-Benutzer die Rechte zur (bearbeitenden) Verwendung dieser Tools im AD (Normaler Nutzer == Domain-Admin anyone???), sonst kann man es gleich vergessen und das AD ist schon jetzt als seit Jahren kompromittiert anzusehen und jederzeit ist alles verschlüsselbar oder schon irgendwo hochgeladen. Denn wenn sich der Admin per Email oder Download einen Schädling eingefangen hat (Antivirus hilft nicht immer, insbesondere wenn der Schädling neu oder vor allem "taylored" (Siehe schlimmstensfalls z.B. Snowden) ist, greift der diese Zugangsgdaten ab (siehe Mimikatz & Co – das gibts auch "fileless" und ist dann vom AV kaum zu erkennen). Macht dieser Admin das dagegen auf einem dafür vorgesehenen gehärteten Terminalserver (Anmeldung ohne (lokale) Adminrechte , Applocker, Firewall, PS Constrained Language Mode, Signed PS-Scripte, …, Ausführen als dazu berechtigter Account, …, Tier 0, ESAE, ….), ist noch eine Ebene dazwischen, die erstmal von einem Angreifer verstanden und geknackt werden muss.
Ich dachte immer, das hier ist ein Blog, der auch bei IT-Sicherheit weiterbilden soll. IT-Sicherheit in der Windows-Welt erfordert eine strikte Account- und Systemtrennung zur Administrierung der Kronjuwelen (Active-Directory), das sollte jeder wissen, auch die, welche entsprechende Vorträge zur Windows-Härtung von Mark Heitbrink und anderen geschätzten Sicherheitsspezialisten z.B. bei der Troopers Sicherheitskonferenz, Schulungen bei Heise, Golem, Fastlane usw. noch nicht selbst gehört haben. Das sind die empfohlenen Basics seit rund 20 Jahren, ganz ohne Cloud und KI.
Nochmal: Das Vorhandensein der RSAT-Tools gibt dem ausführenden Benutzer keine Extra-Rechte!
Und wenn schon, dann nicht per "Ausführen als", sondern via UAC, wenigstens ein "sicherer" Anmeldebildschirm. Also so ein paar Basics sollten seit Vista doch wohl implementiert sein ;-) Selbst für ein Windows XP gab es SuRun.
Und zum Terminalserver/RDP: Juhuu, Kerberos-Tickets. Oder nur mit IP-Adresse statt Hostname, dann wirds halt NTLM. Besser wird das aber auch nicht.
Spaß beiseite. Grundsätzlich hat ein Benutzer nur Benutzerrechte, egal wie "wichtig" er ist (und die besonders wichtigen kriegen eher weniger Rechte). Und auch damit hat er egal ob mit oder ohne RSAT schon entsprechend Rechte in der Domäne, beispielsweise das eigene Konto zu bearbeiten. Passwortwechsel gibts auch bei Computerkonten.
Den LDAP-Zugriff zum Domänencontroller braucht jeder mit der Domäne verbundene Computer, dazu SMB, die RPC-Ports (geil, 16k Ports in der Firewall aufmachen). Selbst das Verweigern eines Logins an einem Domänencomputer als Clientrichtlinie hilft dir nicht, da ja immer noch die Netzwerkverbindung zum Domänencontroller vorhanden ist.
"Ausführen als" hat UAC zur Folge. Aber wenn dein normaler User schon die Rechte hat, in den RSAT-Tools Einstellungen zu verändern, mit oder ohne UAC davor, ist eh schon Hopfen und Malz verloren. AD bereits kompromittiert, davon kannst du ausgehen.
Bist du mit einem Admin-Konto unterwegs hast du lokal(!) erstmal kein Admin-Token (es sei denn, es ist der "Builtin"-Admin). Erst durch die UAC erhältst du das Token mit erhöhten Rechten. Bei der Verbindung mit Remote-Systemen könntest du aber schon erhöhte Berechtigungen haben (Dienste starten/stoppen).
Runas alleine startet erstmal nur einen Prozess mit einem anderen Benutzernamen, gibt dir aber noch nicht automatisch ein Token mit erhöhten Rechten.
"Aber wenn dein normaler User schon die Rechte hat, in den RSAT-Tools Einstellungen zu verändern […]"
Du fantasierst da gerade irgendwas von Berechtigungen, um irgendwas zu ändern. Haben Standardbenutzer doch gar nicht. Es ging *nie* darum, dass ein Standardbenutzer in irgendeiner MMC oder bei einem PowerShell-Modul irgendwelche Rechte hat.