Am Montag haben wir an dieser Stelle geraten, beim September-Update auf die Server gesondert zu schauen. Am selben Tag hat Microsoft ein ausserplanmässiges Update nachgeschoben — weil genau dieses Server-Update die Remotedesktopdienste lahmgelegt hatte.
Das ist keine Randnotiz für Rechenzentren. Wer einen Terminalserver betreibt — verbreitet in Treuhandbüros, Praxen, Kanzleien, überall dort, wo alle auf derselben Maschine arbeiten —, hat in so einem Fall nicht einen Arbeitsplatz mit einem Problem. Er hat alle Arbeitsplätze mit demselben Problem.
Was ausgefallen ist
Die Sicherheitsupdates vom 8. September haben die Remotedesktopdienste instabil gemacht. Microsoft beschreibt es in der Korrektur selbst so: RDP-Verbindungen und Anmeldungen schlagen fehl, oder Server reagieren während der Remotedesktop-Konfiguration nicht mehr.
Dazu kam etwas, das die Lage verschärft: Auch Werkzeuge hörten auf zu antworten, mit denen man so etwas normalerweise untersucht — die Microsoft Management Console, die Diagnose für die RDS-Lizenzierung, der Explorer und ausgerechnet die Windows-Update-Seite selbst.
Verursacht haben es KB5122882 auf Windows Server 2022 und KB5122871 auf Windows Server 2025. Am 14. September kam die Korrektur: KB5129237 für Server 2022, KB5129235 für Server 2025, KB5129238 für Server 2019 und KB5129195 für Windows 11.
Im selben Paket stecken zwei weitere Nachbesserungen: Hyper-V konnte freigegebene Ordner des Hosts nicht mehr in Linux-Maschinen durchreichen, und USB-Audiogeräte der Klasse 1.0 verloren ihre Mehrkanalausgabe. Nicht alle Tonprobleme sind damit erledigt; Microsoft führt weitere weiterhin als bekannte Fehler.
Der Unterschied, der in den Meldungen untergeht
Hier wird es praktisch — und hier lohnt sich das Nachlesen an der Quelle.
Für Windows 11 schreibt Microsoft: Das Update lädt und installiert sich selbständig über Windows Update.
Für die Serverfassungen steht auf denselben Seiten dreimal das Gegenteil. Bei Windows Update: nicht verfügbar. Bei Windows Update for Business: nicht verfügbar. Bei den WSUS-Diensten, über die grössere Betriebe ihre Updates verteilen: nicht verfügbar. Dazu jedes Mal derselbe Satz — dieses Update ist ausschliesslich über den Microsoft Update Catalog erhältlich.
Das heisst im Klartext: Jemand muss eine Datei von Hand herunterladen und einspielen. Von selbst passiert nichts.
Die Verteilung ist also genau umgekehrt zum Schaden. Auf dem Arbeitsplatzrechner, wo der Remotedesktopdienst keine Rolle spielt, kommt die Korrektur automatisch. Auf dem Server, wo er die Grundlage des Arbeitstags ist, kommt sie gar nicht.
Und noch etwas, das beim Lesen auffiel: Mehrere Fachmeldungen schreiben, die Updates würden über Windows Update und WSUS ausgeliefert. Für die Windows-11-Fassung stimmt das. Für die Server stimmt es nicht. Wer sich darauf verlässt, wartet auf etwas, das nicht kommt.
Sofort einspielen oder lieber warten?
Diese Frage steht jetzt im Raum, und beide üblichen Antworten sind als Faustregel falsch.
«Sofort» hätte genau in diesen Fall geführt. Wer das September-Paket am Erscheinungstag auf den Terminalserver gelegt hat, sass womöglich am Mittwoch vor einer Maschine, die keine Anmeldungen mehr annahm.
«Warten» ist trotzdem keine Lösung. Im selben Paket steckten zwei Lücken, die bereits angegriffen wurden, bevor es den Patch gab — eine davon ausgerechnet im Update-Mechanismus. Wer Wochen wartet, tauscht ein Ausfallrisiko gegen ein Einbruchsrisiko.
Die brauchbare Regel staffelt nicht nach Kalender, sondern nach Rolle des Geräts.
Arbeitsplätze zuerst. Dort kommt die Gefahr an — über Anhänge, über den Browser. Und wenn dort etwas schiefgeht, betrifft es einen Menschen, nicht den ganzen Betrieb.
Server einige Tage später, nicht Wochen. Zwei bis fünf Tage reichen, um mitzubekommen, ob ein Update Ärger macht. Genau dieses Fenster hätte hier gereicht.
Vor dem Server-Update einen Rückweg anlegen. Ein Prüfpunkt in Hyper-V, ein Snapshot unter Proxmox, ein Sicherungsstand, von dem Sie wissen, dass er sich zurückspielen lässt. Der Unterschied zwischen einer Stunde Ärger und einem verlorenen Tag liegt fast immer hier.
Nach dem Update einmal selbst anmelden. Nicht nur schauen, ob der Server läuft, sondern sich tatsächlich per Remotedesktop verbinden — bevor am Montagmorgen zwölf Leute dasselbe versuchen.
Was heute zu tun ist
Wenn bei Ihnen seit letzter Woche Verbindungen abbrechen oder Anmeldungen scheitern: Das ist mit einiger Wahrscheinlichkeit dieser Fehler, und die Korrektur liegt bereit — sie muss nur geholt werden.
Wenn alles unauffällig läuft: Keine Hektik, aber einplanen. Das Update ist kumulativ, enthält also den September-Stand vollständig; es ersetzt das fehlerhafte Paket, statt es zu ergänzen.
Wenn Sie nicht wissen, welche Updates auf Ihrem Server liegen: Das ist die eigentlich wichtige Frage, und sie ist in einer halben Stunde beantwortet.
Bei den Servern in unserer Wartung sehen wir das in dieser Woche ohnehin durch. Wenn Sie einen Terminalserver betreiben und unsicher sind, ob die Korrektur bei Ihnen angekommen ist: Sie ist es vermutlich nicht — automatisch kommt sie dort nicht.