2026: Was tun bei RDP-Ausfällen nach KB5122876 auf Windows Server 2019?

Der RDP-Client bleibt bei „Verbindung wird hergestellt“ stehen, oder eine RDS-Sitzung reagiert nicht mehr.

Schnellster Weg: Microsoft hat ein bekanntes RDS-Problem nach dem Windows-Server-2019-Sicherheitsupdate KB5122876 bestätigt; prüfen Sie KB5129238 oder ein anwendbares späteres Update und testen Sie danach die Anmeldung erneut. Die Korrektur ist dokumentiert. Das Sicherheitsupdate sollte nicht vorschnell deinstalliert werden. Microsoft führt das Problem und den behobenen Status in der Übersicht zu Windows Server 2019.

Dieser Ablauf ist für Administratoren gedacht, die noch Windows Server 2019 betreiben und einen möglichen Zusammenhang zwischen Update und RDP-Ausfall prüfen müssen.
Er hilft ebenso beim Überprüfen eines RDS-Sitzungshosts und beim Abgrenzen unabhängiger Netzwerk-, Anmelde- oder Anwendungsfehler.

Letzte Prüfung: 30.10.2026. Der bekannte Fehlerstatus und die Zuordnung der Korrektur wurden anhand der Microsoft-Übersicht zu behobenen Problemen, der KB5129238-Supportbeschreibung und der Microsoft-Anleitung zur RDS-Fehlerbehebung bei den Updates vom September 2026 abgeglichen. Prüfen Sie diese Seiten vor einer Änderung erneut: Microsoft kann den Status oder die Anwendbarkeit späterer kumulativer Updates aktualisieren.

RDP-Störung nach KB5122876 auf Windows Server 2019 einordnen

KB5122876 ist das Sicherheitsupdate vom September 2026 für Windows Server 2019, mit dem Microsoft ein mögliches Problem bei Remote Desktop Services (RDS) verknüpft hat. Die Formulierung „möglich“ ist wichtig: Die Dokumentation besagt nicht, dass jeder Server nach der Installation ausfällt. Sie bestätigt eine bekannte Fehlerklasse für bestimmte Umgebungen und beschreibt die Korrektur durch KB5129238 sowie spätere Updates. Die Microsoft-Seite zum behobenen Problem ist deshalb die maßgebliche Referenz, nicht ein einzelner ähnlicher Fehlerbericht.

Das sichtbare Symptom kann unterschiedlich ausfallen: Eine RDP-Verbindung kommt nicht zustande, die Anmeldung bleibt hängen oder der Verbindungsaufbau wird während der Sitzungskonfiguration nicht abgeschlossen. Keines dieser Symptome beweist für sich allein einen Zusammenhang mit KB5122876. Auch ein längerer Anmeldevorgang, eine Meldung über einen beschäftigten Remotedesktopdienst oder ein unerreichbarer Sitzungshost kann durch andere Ursachen entstehen.

Für die erste Einordnung sind drei Fragen entscheidend:

• Trat die Störung nach der Installation des betreffenden Updates auf, oder bestand sie schon vorher?
• Ist nur ein Benutzer betroffen, oder scheitern Verbindungen zu mehreren Konten und Sitzungshosts?
• Ist KB5129238 oder ein späteres, für den Server anwendbares kumulatives Update bereits installiert?

Eine Diskussion im Systemadministratoren-Forum zu hängenden RDS-Sitzungshosts nach den September-Updates zeigt, dass Administratoren ähnliche Symptome erörtern. Das ist ein Hinweis auf eine aktuelle Fragestellung, aber weder ein Beleg für die Ursache eines konkreten Ausfalls noch eine Bestätigung durch Microsoft. Für die Diagnose zählt die Microsoft-Dokumentation zusammen mit den lokalen Update- und Ereignisdaten.

Installierten Update-Stand nachvollziehen

Wie lässt sich erkennen, ob KB5122876 installiert ist?

Prüfen Sie den Updateverlauf direkt auf dem betroffenen Server und halten Sie die vollständige Betriebssystemversion fest. Die grafische Oberfläche eignet sich für eine schnelle Sichtprüfung; eine PowerShell-Abfrage kann ergänzend die sichtbaren Hotfix-Einträge erfassen. Keiner der beiden Wege sollte isoliert als Nachweis dafür gelten, dass ein späteres kumulatives Update die Korrektur enthält.

Grafische Prüfung

1. Öffnen Sie Einstellungen und wechseln Sie zu Update und Sicherheit.
2. Wählen Sie Windows Update und anschließend Updateverlauf anzeigen.
3. Prüfen Sie die Einträge für Qualitätsupdates auf KB5122876, KB5129238 und nachfolgende Updates.
4. Erfassen Sie zusätzlich die Betriebssystemversion. Sie finden diese beispielsweise über winver; notieren Sie die angezeigte Edition und den Build für das Änderungsprotokoll.

Je nach Verwaltungsrichtlinie oder installierter Serveroberfläche kann der Updateverlauf anders dargestellt werden. Eine zweite Sichtprüfung ist über Systemsteuerung > Programme > Programme und Features > Installierte Updates anzeigen möglich. Vergleichen Sie dabei die Update-Kennungen, nicht allein das Installationsdatum: Das Datum sagt nicht zuverlässig aus, ob ein Update installiert, ersetzt oder durch ein späteres Paket abgelöst wurde.

Optionale PowerShell-Prüfung

Starten Sie PowerShell mit ausreichenden Rechten und lassen Sie die sichtbaren Einträge filtern:

Get-HotFix |
  Where-Object { $_.HotFixID -in 'KB5122876','KB5129238' } |
  Select-Object HotFixID, InstalledOn, Description

Für eine Bestandsaufnahme der sichtbaren Hotfixes können Sie auch Folgendes ausführen:

Get-HotFix | Sort-Object InstalledOn -Descending |
  Select-Object -First 20 HotFixID, InstalledOn, Description

Diese Abfragen zeigen Einträge, die Windows über Get-HotFix bereitstellt. Sie ersetzen weder den Updateverlauf noch die Prüfung der Microsoft-Angaben zu einem späteren kumulativen Update. Ein fehlender Treffer beweist nicht automatisch, dass die Korrektur fehlt: Ein Update kann durch ein späteres Paket ersetzt worden sein oder in der Abfrage nicht in der erwarteten Form erscheinen. Prüfen Sie daher Paketstand, Updateverlauf und Microsoft-Hinweise zusammen. Die Microsoft-Informationen zu Windows-Server-Versionen und Wartungsständen helfen, den erfassten Build in den Veröffentlichungszusammenhang einzuordnen.

KB5129238 und spätere Updates im Wartungsfenster prüfen

Kann KB5129238 den RDP-Fehler beheben?

Ja, KB5129238 ist laut Microsoft die zugehörige Korrektur für das bekannte RDS-Problem. Auch spätere kumulative Updates können die Korrektur enthalten. Entscheidend ist nicht, dass der Server genau eine bestimmte KB-Kennung anzeigt, sondern dass ein für die installierte Windows-Server-Version anwendbares Update mit der Korrektur erfolgreich installiert wurde. Prüfen Sie dafür sowohl die KB5129238-Supportbeschreibung als auch den aktuellen Status in der Microsoft-Übersicht zu Windows Server 2019.

Gehen Sie im geregelten Änderungsprozess vor:

1. Ausgangslage dokumentieren: Notieren Sie Servername, Edition, Build, installierte Updates, betroffene Benutzer, Fehlerzeitpunkte und den letzten bekannten funktionierenden Zustand.
2. Anwendbarkeit verifizieren: Lesen Sie die Microsoft-Beschreibung der Korrektur und der nachfolgenden kumulativen Updates. Vergewissern Sie sich, dass das ausgewählte Update für genau diesen Server geeignet ist.
3. Änderung freigeben: Stimmen Sie Installation und Neustart mit dem Wartungsfenster und den betroffenen Fachbereichen ab. Berücksichtigen Sie abhängige Dienste und geplante RDS-Sitzungen.
4. Update installieren: Verwenden Sie den in Ihrer Organisation freigegebenen Updateweg. Halten Sie Installationsstatus und eventuelle Fehlermeldungen fest.
5. Neustartbedarf prüfen: Folgen Sie der Updateanzeige und der betrieblichen Freigabe. Ein abgeschlossener Download oder Installationsvorgang ist noch keine erfolgreiche RDS-Abnahme.
6. Verbindung funktional testen: Prüfen Sie die Admin-Verbindung und anschließend die Anmeldung eines repräsentativen Benutzers. Kontrollieren Sie dabei nicht nur den Verbindungsaufbau, sondern auch die nutzbare Sitzung und die benötigte Geschäftssoftware.

Wichtig: Deinstallieren oder pausieren Sie das Sicherheitsupdate nicht als Standardmaßnahme. Ein Rückbau kann Sicherheits- und Betriebsfolgen haben und beseitigt die Ursache nicht zwingend. Falls ein Rollback wegen konkreter Auswirkungen erwogen wird, muss er über den internen Änderungs- und Sicherheitsprozess bewertet und freigegeben werden.

Community-Beiträge können kurzfristig praktikable Vermutungen enthalten, ersetzen aber keine Prüfung der Korrektur und keine kontrollierte Änderung. Ein Update ohne vorherige Bestandsaufnahme zurückzunehmen erschwert außerdem den Vergleich: Danach ist oft unklar, ob die Ursache das Update, eine gleichzeitige Richtlinienänderung oder eine andere Störung war.

Wiederherstellung getrennt nach Verbindung und Sitzung prüfen

Was ist nach KB5129238 zu testen?

Führen Sie nach der Installation die Abnahme in der Reihenfolge vom Zugang bis zur Anwendung durch. Eine erreichbare TCP-Verbindung oder ein laufender Dienst zeigt nur einen Teil des Zustands; sie beweist nicht, dass Anmeldung, Sitzungsaufbau und Geschäftssoftware funktionieren.

Zuerst den administrativen Zugriff testen. Verbinden Sie sich von einem freigegebenen Administratorarbeitsplatz mit dem Server. Halten Sie fest, ob die Verbindung abgewiesen wird, ob die Anmeldung scheitert oder ob der Bildschirm erst während der Sitzungsinitialisierung hängen bleibt. Wenn möglich, vergleichen Sie denselben Serverzugriff über einen zweiten, bereits autorisierten Zugangspfad, ohne dabei Sicherheitsregeln zu umgehen.

Dann eine reguläre Sitzung prüfen. Melden Sie einen tatsächlichen Benutzer über den vorgesehenen RDP- oder RDS-Weg an. Prüfen Sie, ob das Profil geladen wird, die benötigte Anwendung startet und die Sitzung Eingaben annimmt. Bei einem RDS-Szenario muss der Test auf dem betroffenen Sitzungshost erfolgen; ein erfolgreicher Admin-Zugang auf einem anderen Server ist kein Nachweis für die Wiederherstellung des Hosts.

Dienste und Protokolle auswerten. Kontrollieren Sie den Status der für die jeweilige Rolle relevanten Remotedesktopdienste, darunter den Remotedesktopdienste-Dienst und gegebenenfalls Sitzungskonfiguration oder Umleitungsdienste. Die Rolle und konkrete Dienstabhängigkeiten unterscheiden sich je nach Aufbau; starten Sie daher nicht pauschal alle Dienste neu. Suchen Sie im Ereignisprotokoll nach Einträgen zum Zeitpunkt des Fehlers und korrelieren Sie diese mit Anmeldeversuch, Benutzer und Sitzungshost.

Microsoft empfiehlt für RDS-Verbindungsprobleme eine systematische Trennung von Verbindungsweg, Sitzungshost und Anmeldung. Verwenden Sie die Microsoft-Anleitung zur RDS-Sitzungsverbindung, statt aus einer einzelnen Ereignis-ID eine allgemeingültige Ursache abzuleiten. Bei der Meldung, dass der Remotedesktopdienst derzeit ausgelastet ist, beschreibt Microsoft außerdem, welche Informationen für die Diagnose gesammelt werden sollten: Anleitung zur Meldung „Remote Desktop Services is currently busy“.

Verbleibende RDP-Fehler außerhalb des Updates abgrenzen

Was ist zu untersuchen, wenn RDP nach dem Update weiter hängt?

Wenn KB5129238 oder ein anwendbares späteres Update installiert ist und sich der Fehler nicht verändert, behandeln Sie das Problem zunächst als eigenständige Störung. Prüfen Sie die folgenden Fehlergrenzen getrennt:

• Netzwerkpfad: Vergleichen Sie den Zugriff aus einem erlaubten Netz mit dem Zugriff aus dem betroffenen Standort. Prüfen Sie Namensauflösung, Routing, Firewallregeln und Verbindungsabbrüche anhand Ihrer freigegebenen Netzwerkkonfiguration. Ein offener RDP-Port allein bestätigt keine funktionierende Anmeldung.
• Konto und Authentifizierung: Prüfen Sie Kontostatus, Anmeldebeschränkungen, Gruppenrichtlinien und die verwendete Authentifizierung. Vergleichen Sie einen betroffenen Zugang mit einem berechtigten Testkonto, ohne bestehende Sicherheitsrichtlinien zu lockern.
• Sitzungshost und RDS-Rolle: Ermitteln Sie, ob der Fehler nur einen Host oder mehrere Hosts betrifft. Prüfen Sie die Rollenkomponenten und Ereignisse auf dem tatsächlichen Sitzungshost und ordnen Sie die Zeitstempel den fehlgeschlagenen Sitzungsversuchen zu.
• Profil oder Geschäftssoftware: Wenn die Sitzung geöffnet wird, aber während der Profil- oder Anwendungsinitialisierung stehen bleibt, prüfen Sie Profilzugriff, Anmeldeskripte und die betroffene Software separat. Ein RDP-Verbindungsproblem und ein Anwendungsstartfehler sind nicht automatisch dieselbe Störung.
• Änderungen außerhalb des Updates: Vergleichen Sie den Fehlerbeginn mit Änderungen an Richtlinien, Zertifikaten, Netzwerkregeln, Konten oder Anwendungen. Dokumentieren Sie zeitliche Überschneidungen, statt sie als Ursache vorauszusetzen.

Die Microsoft-Anleitung zu RDS-Instabilität nach den September-Updates gibt Hinweise, wie Updatebezug und Diagnose voneinander abgegrenzt werden können. Bei unklarer Ursache oder wachsender Geschäftsauswirkung eskalieren Sie anhand Ihrer internen Incident-Regeln und stellen Ereignisprotokolle, Updateverlauf, betroffene Konten und reproduzierbare Schritte bereit. Vermeiden Sie parallele Änderungen, die den Befund verwischen.

Patch-Prüfung als wiederholbaren Ablauf festlegen

Für künftige Wartungsfenster sollte die RDP-Abnahme als Bestandteil der Änderung dokumentiert werden. Vor der Installation erfassen Sie den Systemstand, prüfen die Microsoft-Problemseite und informieren die betroffenen Benutzer über das geplante Fenster. Testen Sie das Update, sofern vorhanden, zunächst in einer geeigneten nicht produktiven Umgebung. Vor der Freigabe für den Produktivbetrieb müssen Verantwortliche wissen, welche Anmeldung und welche Geschäftssoftware nach dem Neustart geprüft werden.

Nach der Installation gehören Updatekennung, Build, Installationsstatus, Neustartstatus und Testergebnis in dasselbe Änderungsprotokoll. Bewahren Sie außerdem die relevanten Ereignisse und die genaue Fehlerbeschreibung auf. So lässt sich später nachvollziehen, ob die Störung mit dem Update behoben wurde oder ob ein unabhängiger Fehler weiter besteht. Die RDS-Zugriffshinweise von CloudUDP können ergänzend helfen, den vorgesehenen Zugangsweg zu prüfen; sie ersetzen nicht die lokale RDS-Diagnose.

Für die Entscheidung zwischen nächster Maßnahme und Eskalation gilt: Ist die Korrektur nicht nachweisbar, zuerst Anwendbarkeit und Installationsstatus klären. Ist sie bestätigt, aber der Test weiterhin fehlerhaft, Netzwerk, Konto, Sitzungshost und Anwendung einzeln untersuchen. Ist die Wirkung nicht reproduzierbar oder sind mehrere Systeme betroffen, Änderungen stoppen und den Fall mit den gesammelten Belegen eskalieren.

Wenn Windows Server 2019 weiterhin zum Anwendungsbestand gehört, sollte eine Neuinstallation oder Migration nicht mit dem RDS-Fehler verwechselt werden: Zuerst müssen Updatezustand und Geschäftsanwendung sauber geprüft sein. Für einen länger laufenden Dienst kann eine dedizierte AMD-Physikmaschine gegenüber einer geteilten VPS-Instanz besser passen, wenn gleichzeitige Ressourcennutzung durch andere Mandanten, eingeschränkte Kontrolle über die Hostumgebung oder wechselnde Instanzbedingungen die Betriebsplanung erschweren. Sie ist dagegen keine sinnvolle Abkürzung für einen kurzfristigen Test oder eine leichte, nur gelegentlich genutzte Last. CloudUDP führt Windows Server 2019, 2022 und 2025 in den verfügbaren Systemoptionen sowie englische, traditionell chinesische und vereinfachte chinesische Sprachfassungen; Windows wird per RDP genutzt. Prüfen Sie die für Ihre Anwendung passende Auswahl und die Abrechnungsbedingungen auf der CloudUDP-Übersicht der Serverpläne. RDS-CALs, SQL-Server-Lizenzen und Migrationsbetrieb sind damit nicht eingeschlossen.