Windows-Patchday September 2026: RDS läuft wieder – aber den Fix müssen Sie sich selbst holen

Der September-Patchday war der größte, den Microsoft je ausgeliefert hat – und er hat prompt getan, was große Patchdays tun: Er hat Dinge zerlegt, die vorher funktioniert haben. Seit dem 8. September melden Administratoren weltweit abbrechende RDP-Sitzungen, hängende Terminalserver und Anmeldungen, die ins Leere laufen. Microsoft hat am 14. September mit Out-of-Band-Updates nachgelegt und das Problem als behoben markiert. Für alle, die Windows Server betreiben, steckt der eigentliche Aufwand allerdings im Kleingedruckten: Diese Pakete werden weder über Windows Update noch über WSUS verteilt. Wer nichts tut, bleibt auf dem defekten Stand sitzen.

Was am 8. September passiert ist

Microsoft hat am September-Patchday je nach Zählweise zwischen 964 und 974 Schwachstellen geschlossen – ein Rekord, der die bisherigen Monatswerte deutlich übertrifft und der auch deshalb zustande kommt, weil Microsoft inzwischen KI-gestützt im eigenen Code sucht. Zwei der geschlossenen Lücken wurden zum Zeitpunkt der Veröffentlichung bereits aktiv ausgenutzt: CVE-2026-85880 im Advanced Local Procedure Call und CVE-2026-81963 im Windows Update Stack. Beide erlauben einem Angreifer, der bereits lokalen Zugriff hat, die Ausweitung auf SYSTEM-Rechte – also genau den Schritt, der aus einem kompromittierten Nutzerkonto eine kompromittierte Domäne macht.

Diese Größenordnung ist der Kontext für alles, was danach kam. Ein Update, das Hunderte Komponenten gleichzeitig anfasst, lässt sich nicht mehr vollständig gegen jede Kombination aus Profil-Technologie, Session-Broker und Sicherheitsagent testen. Das ist keine Entschuldigung, aber es ist die operative Realität, auf die sich IT-Verantwortliche einstellen müssen: Der Patchday ist von einer Routineaufgabe zu einem Change mit Ausfallrisiko geworden.

Behoben: die RDS-Instabilität

Microsoft hat das Problem am 11. September in Windows Release Health eröffnet und am 14. September als gelöst markiert. Das Fehlerbild ist tückisch, weil es nicht sofort auftritt: Die Umgebung läuft nach dem Neustart zunächst normal, nach einigen Minuten beginnen RDP-Verbindungen zu scheitern, Anmeldungen schlagen fehl, und Server bleiben unbegrenzt bei „Please wait for the Remote Desktop Configuration“ stehen. Betroffen sind nicht nur die Sitzungen selbst – auch die Microsoft Management Console, der RDS-Lizenzdiagnose-Dienst, der Datei-Explorer und die Windows-Update-Seite reagieren auf den betroffenen Maschinen nicht mehr. Das ist der unangenehme Teil: Genau die Werkzeuge, mit denen man den Fehler diagnostizieren und beheben würde, fallen mit aus.

Die Liste der betroffenen Plattformen ist breit. Auf Client-Seite reicht sie von Windows 11 26H1, 25H2, 24H2 und 23H2 über Windows 10 22H2 und 21H2 bis zu den Enterprise-LTSC-Ständen 2019 und 2016. Auf Server-Seite sind Windows Server 2025, 2022, 2019, 2016, 2012 R2 und 2012 betroffen – also praktisch jede Version, die in mittelständischen Rechenzentren noch produktiv läuft.

Die Out-of-Band-Updates vom 14. September 2026

Betriebssystem

Update

Build

Windows Server 2025

KB5129235

26100.33451

Windows Server 2022

KB5129237

20348.5631

Windows Server 2019 / Win 10 LTSC 2019

KB5129238

17763.9247

Windows Server 2016 / Win 10 LTSB 2016

KB5129239

14393.9514

Windows Server 2012 R2

KB5129243

Monthly Rollup

Windows Server 2012

KB5129244

Monthly Rollup

Windows 11 26H1

KB5129194

28000.2956

Windows 11 25H2 / 24H2

KB5129195

26200.9457 / 26100.9457

Windows 11 25H2 / 24H2 (Hotpatch)

KB5129241

26200.9448 / 26100.9448

Windows 11 23H2

KB5129242

22631.7584

Windows 10 22H2 / LTSC 2021

KB5129236

19045.7727 / 19044.7727

Alle Pakete sind kumulativ und enthalten den Stand vom 8. September vollständig. Wer den September-Rollup in der Not deinstalliert hat, um den Betrieb wiederherzustellen, kann das Out-of-Band-Update also direkt installieren, ohne vorher nachzuziehen. Die einzige Ausnahme ist die Hotpatch-Variante KB5129241, die KB5124008 als Basis voraussetzt – dafür kommt sie ohne Neustart aus. Wer den von Microsoft vorab bereitgestellten Known Issue Rollback per Gruppenrichtlinie ausgerollt hat, muss vor der Installation nichts zurückbauen.

Der Haken: Für Server liefert Windows Update nicht aus

Das ist der Punkt, an dem dieser Vorgang vom Routine-Patch zur Aufgabe wird. Öffnet man die Release Notes zu KB5129235 oder KB5129237 und sieht sich die Tabelle „How to get this update“ an, steht dort für Windows Update, Windows Update for Business und WSUS jeweils: nicht verfügbar. Nur der Microsoft Update Catalog liefert die Pakete aus. Die Client-Updates für Windows 10 und Windows 11 werden hingegen regulär über Windows Update angeboten.

Die praktische Konsequenz
Ausgerechnet dort, wo Remote Desktop Services tatsächlich läuft – auf den Session-Hosts, den Lizenzservern, den Jump-Hosts – muss das Paket manuell aus dem Katalog geladen und über DISM, ein Deployment-Werkzeug oder die eigene RMM-Plattform ausgerollt werden. Wer diesen Weg nicht automatisiert hat, verbringt damit einen halben Arbeitstag pro Standort.

Den aktuellen Stand einer Maschine prüfen Sie am schnellsten über die Registry, ohne sich durch die Update-Historie klicken zu müssen – was ohnehin schwierig wäre, solange die Windows-Update-Seite auf betroffenen Systemen hängt:
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion" | Select-Object CurrentBuild, UBR

Noch offen: schwarzer Bildschirm nach der Anmeldung in VDI-Umgebungen

Parallel zum RDS-Problem läuft ein zweites Fehlerbild, das Microsoft bislang nicht offiziell dokumentiert hat. Nach der Anmeldung startet explorer.exe nicht – der Nutzer sieht einen schwarzen Bildschirm ohne Desktop, ohne Taskleiste, ohne Startmenü. Die Sitzung selbst ist dabei gesund: Wer über Strg+Alt+Entf den Task-Manager öffnet und den Explorer von Hand startet, bekommt seinen Desktop sofort. Der Fehler liegt also im automatischen Start der Shell, nicht in der Sitzung.

Die Berichte konzentrieren sich auf virtuelle Desktop-Umgebungen mit Profil-Containern: FSLogix, Citrix UPM, Omnissa Horizon und ProfileUnity ProfileDisks, jeweils unter Windows 11 24H2 und 25H2. Erste Meldungen gab es bereits nach dem optionalen August-Preview-Update KB5120998; mit dem Rollout von KB5124008 ist die Zahl deutlich gestiegen. Physische Endgeräte und Umgebungen ohne Profil-Container sind nach bisherigem Stand nicht betroffen.

Wichtig für die Erwartungshaltung
Das Out-of-Band-Update KB5129195 behebt dieses Problem nicht. Microsoft untersucht die Berichte und hat öffentlich um Speicherabbilder gebeten, führt den Fehler zum Redaktionsschluss am 17.09.2026 aber weiterhin nicht als Known Issue in Windows Release Health. Es gibt damit keinen Rollback, keinen offiziellen Workaround und keinen zugesagten Termin.

Wenn Sie betroffen sind, ist ein Support-Case bei Microsoft – und parallel beim VDI-Hersteller – momentan der wirksamste Hebel. Ohne belastbare Reproduktionsdaten aus produktiven Umgebungen wird es keinen offiziellen Fix geben.

Ebenfalls offen: die Vertrauensstellung zur Domäne

Am 16. September ist ein weiteres Problem hinzugekommen, das in der bisherigen Berichterstattung untergegangen ist und gerade für klassische Mittelstandsumgebungen mit On-Premises-Active-Directory unangenehm werden kann. Nach der Installation von KB5124008 können Credential-Guard-geschützte Computerkonten ihren sicheren Kanal zur Domäne verlieren. Nutzer können sich dann trotz gültiger Anmeldedaten nicht mehr interaktiv anmelden und erhalten die Meldung, die Vertrauensstellung zwischen Arbeitsstation und Domäne sei fehlgeschlagen. Die Anmeldung über zwischengespeicherte Anmeldedaten funktioniert weiter, AD-Replikation und die Dienste auf den Domänencontrollern sind nicht betroffen.

Die Ursache liegt darin, dass das Update dazu führt, dass Windows bestehende oder per Richtlinie gesetzte Konfigurationen für Machine Identity Isolation erstmals tatsächlich durchsetzt. Das Feature setzt Domänencontroller auf dem Funktionsebenen-Stand von Windows Server 2025 voraus – wer es früher aktiviert hat, ohne diese Voraussetzung zu erfüllen, läuft jetzt in den Fehler. Der Workaround besteht darin, Machine Identity Isolation auf demselben Weg wieder zu deaktivieren, auf dem es aktiviert wurde – per Intune, per Gruppenrichtlinie oder direkt in der Registry, indem der Wert MachineIdentityIsolation von 2 auf 0 gesetzt wird –, das Gerät neu zu starten und anschließend den sicheren Kanal mit Test-ComputerSecureChannel -Repair zurückzusetzen. Microsoft will die Durchsetzung in einem künftigen Update vorübergehend wieder unterbinden. Betroffen sind Windows 11 26H1, 25H2 und 24H2; Server-Systeme stehen nicht auf der Liste.

Und was mit den Kopfhörern ist

Ein drittes Problem betrifft USB-Audio-Class-1.0-Geräte, die nach dem September-Update nicht mehr starten oder keinen Ton ausgeben. Das Out-of-Band-Update hat hier nur teilweise geliefert: Geräte, die in Stereo funktionierten, aber im 8-Kanal- oder 3D-Modus ausfielen, laufen wieder. Geräte, die mit dem Fehlercode 10 im Geräte-Manager stehen, bleiben defekt – eine Lösung steht aus. Für Service-Desks, Callcenter-Arbeitsplätze und Besprechungsräume ist das kein Randthema, sondern ein Ticket-Treiber.

Warum Deinstallieren die schlechteste der verfügbaren Optionen ist

Der erste Reflex in einer laufenden Störung ist verständlich: Update raus, Betrieb wieder her. In diesem Fall wiegt dieser Reflex besonders schwer, weil der September-Rollup zwei Schwachstellen schließt, die zum Zeitpunkt der Veröffentlichung bereits aktiv ausgenutzt wurden. Wer deinstalliert, tauscht ein Verfügbarkeitsproblem gegen ein Sicherheitsproblem – und öffnet dabei ausgerechnet den Pfad zur lokalen Rechteausweitung, den Angreifer nach einem erfolgreichen Phishing oder einem gestohlenen Anmeldedatensatz als Nächstes suchen.

Falls ein Rollback als Notfallmaßnahme unumgänglich war, gehört er mit einer Frist und einer kompensierenden Maßnahme versehen: verschärfte Überwachung auf den betroffenen Systemen, eingeschränkter Netzwerkzugriff, dokumentierte Wiedervorlage. Und der Weg zurück führt in diesem Fall direkt über das Out-of-Band-Paket, nicht über den Umweg des September-Rollups.

Was dieser Monat über Patch-Management aussagt

Der eigentliche Lerneffekt liegt nicht in den KB-Nummern, sondern in der Frage, wie belastbar der eigene Prozess ist, wenn ein Patchday dieser Größenordnung zur neuen Normalität wird. Vier Punkte, die sich aus diesem Monat ableiten lassen:

• Ringbasiertes Ausrollen ist keine Kür mehr. Entscheidend ist dabei weniger die Zahl der Ringe als die Zusammensetzung des ersten. Er muss die Konfigurationen enthalten, die statistisch brechen: RDS-Session-Hosts, Lizenzserver, VDI-Pools mit Profil-Containern, Jump-Hosts, Entwickler-Arbeitsplätze und Systeme mit tief integrierten Sicherheitsagenten. Ein Pilotring aus zehn Standard-Notebooks hätte in diesem Monat nichts gefunden.
• Out-of-Band-Fähigkeit ist eine messbare Größe. Die ehrliche Frage lautet: Wie lange brauchen Sie, um ein Katalog-Paket auf vierzig Server zu bringen, wenn Windows Update ausfällt? Wenn die Antwort „von Hand, über mehrere Tage“ ist, dann ist das kein Sicherheitsproblem, sondern ein Kostenproblem, das sich bei jedem weiteren Vorfall wiederholt.
• Ein zweiter Verwaltungsweg neben RDP gehört zur Grundausstattung. Hypervisor-Konsole, iLO oder iDRAC, Cloud-Portal, Out-of-Band-Management: Wer seine Server ausschließlich über RDP erreicht, verliert den Zugriff genau in dem Moment, in dem er ihn am dringendsten braucht. In diesem Monat war das keine theoretische Übung.
• Patch-Entscheidungen gehören dokumentiert – auch die, gegen das Einspielen. Wer unter NIS2 fällt oder über Lieferkettenanforderungen in die Nachweispflicht gerät, braucht eine nachvollziehbare Begründung für jede bewusste Verzögerung samt kompensierender Maßnahme. Ein Ticket mit Zeitstempel und Freigabe ist dafür ausreichend – aber es muss existieren.

Was jetzt zu tun ist

1. Bestand feststellen. Prüfen Sie Build und UBR aller RDS-Session-Hosts, Lizenzserver und Jump-Hosts. Alles, was auf dem Stand vom 8. September steht, ist ein Kandidat.
2. Out-of-Band-Updates einspielen. Für Server über den Microsoft Update Catalog, für Clients regulär über Windows Update. Die Pakete sind kumulativ, ein vorheriges Nachziehen des September-Rollups ist nicht nötig.
3. VDI-Umgebungen gesondert bewerten. Wo FSLogix, Citrix UPM, Horizon oder ProfileUnity im Einsatz sind, bleibt das Blackscreen-Risiko bestehen. Halten Sie den Task-Manager-Workaround im Service-Desk bereit und eröffnen Sie bei aktiver Betroffenheit einen Support-Case.
4. Machine Identity Isolation prüfen. Wenn das Feature per Intune, Gruppenrichtlinie oder Registry gesetzt ist und Ihre Domänencontroller nicht auf Windows Server 2025 laufen, deaktivieren Sie es, bevor die Anmeldeprobleme auftreten.
5. Notfallzugang verifizieren. Testen Sie aktiv, ob Sie jeden produktiven Server auch ohne RDP erreichen – nicht theoretisch, sondern mit einer echten Anmeldung.
6. Dokumentieren. Betroffene Systeme, eingespielte Pakete, offene Risiken und getroffene Entscheidungen – kurz, aber nachvollziehbar.

Wenn Sie Ihren Windows-Server- und VDI-Bestand bisher ohne durchgängig automatisiertes Patch-Management betreiben, ist dieser Monat ein guter Anlass, das zu ändern. Nicht, weil der nächste Patchday zwangsläufig schiefgeht, sondern weil der Aufwand für den Fall, dass er es tut, planbar werden sollte.

Sprechen Sie uns für weitere Details, eine Beratung oder ein Expertengespräch gerne auch direkt an oder wenden Sie sich formlos an hallo@enthus.de.

← Alle Beiträge