[English]Nachtrag vom Oktober 2024-Patchday (8.10.2024). Das Update KB5044281 für Windows Server 2022 (21H2) verursacht womöglich Probleme bei Failover-Clustern. Ein Leser hat im Blog einen Kommentar hinterlassen, dass bei ihm in seiner Umgebung die Remotedesktop-Dienste zerschossen werden.
Anzeige
Windows Server 2022 Update KB5044281
Das kumulative Update KB5044281 wurde zum 8. Oktober 2024 für Windows Server 2022 freigegeben. Das Update adressiert laut Support-Beitrag eine Reihe Probleme unter diesem Server-Betriebssystem. Angeblich wurde auch ein bekanntes Problem mit dem Remotedesktop korrigiert, bei dem Remotedesktopverbindungen im gesamten Unternehmen unter Windows-Server 2022 unterbrochen wurden.
Dieses Problem könne auftreten, wenn ein Legacyprotokoll (z.B. Remoteprozeduraufruf über HTTP) im Remotedesktopgateway verwendet wird, hieß es bei Microsoft. Dann gehen Remote-Desktop-Sitzungen sporadisch, z. B. alle 30 Minuten, verloren. Nutzer müssen dann erneut eine Verbindung mit dem Server herstellen. IT-Administratoren können dies an Abstürzen des TSGateway-Diensts nachverfolgen. Es reagiert nicht mehr, wobei der Ausnahmecode 0xc0000005 ausgelöst wird. Nun will Microsoft diesen Fehler korrigiert haben.
Remotedesktop-Dienste weiterhin gestört
Blog-Leser ChristophH hat sich vor einigen Tagen in diesem Kommentar gemeldet und berichtet, dass bei Windows Server 2022 (21H2) das KB5044281 die Probleme mit den Remotedesktop-Diensten in einem Failover-Cluster anhalten.
Die Dienste würden weiterhin zerschossen. Das Update beschädigt laut Leser wiederum eine (unbekannte) Komponente der Remodedesktop-Dienste, welche mit den Hyper-V Diensten und/oder dem Failover-Clustermanager kommuniziert. Da es keine Rückmeldungen zum Kommentar gab, stellt sich die Frage, ob es weitere Betroffene gibt.
Ein Workaround
Blog-Leser ChristophH hatte bereits im September 2024 in diesem Kommentar einen Workaround beschrieben.
Anzeige
1. Update installieren und booten
2. RD-Sessionhost-Rolle installieren (nur die Rolle über Rollen und Features
hinzufügen, nicht die Installation über die RDS-Verwaltungsdienste !!)
3. Booten und testen – Fehler sollte behoben sein
4. RD-Sessionhost-Rolle deinstallieren und booten
5. Problem sollte dauerhaft behoben sein
Der beschriebene Workaround repariert die defekte oder fehlende Komponente wieder. Der Vorgang ist auf jedem Cluster-Node zu wiederholen.
Ähnliche Artikel:
Patchday: Windows 10/Server-Updates (8. Oktober 2024)
Patchday: Windows 11/Server 2022-Updates (8. Oktober 2024)
Patchday: Windows 11/Server 2022-Updates (10. September 2024)
Anzeige
Leider sehr ungenau die Beschreibung. Meint er den RDP-Zugriff (Admin) auf einen W2022-Failovercluster (Hyper) selbst, oder eine RD-Farm 2022 als VMs auf einem W2022-Cluster? Wurde alle W2022 gepatcht oder nur ein Teil. Vlt. mag ChristophH hier noch weitere Infos geben. Danke
Hallo RalphAndreas
Es geht nicht um den RDP-Zugriff selber, sondern es ist die Vermutung da, dass durch durch das fixen von Fehlern in den Remotedesktop-Diensten, auch im Zusammenhang mit den bekannten RDP-Zugriffproblemen, ein weiterer Fehler nicht gefixt oder neu entstanden ist.
Im diesem Kommentar zu den September-Update habe ich den Fehler erstmalig beschrieben:
https://www.borncity.com/blog/2024/09/11/patchday-windows-11-server-2022-updates-10-september-2024/#comment-193510
Im Kern geht es um folgendes Problem:
"Installiert sind bei uns RD-Virtualisierungshost für VDI (keine RD-Sessionhost) in einem Failover-Cluster auf 2 Nodes, Windows Server 2022 21H2, direkt auf Metall.
Nach der Installation wird der Status der virtuellen Desktop im Server-Manager > Remotedesktop-Dienste > Sammlungen mit "unbekannt" angezeigt.
Ebenso werden unter Verbindungen keine aktiven Session mehr von VMs auf diesen RD-Virtualisierungshost gelistet.
Die Anzahl der virtuellen Host pro RD-Virtualisierungshost wird mit 0 angezeigt auch wenn sich Hyper-V VMs auf dem Host befinden.
Schiebt man die VMs auf die noch ungepatchte Node-2 wird alles richtig angezeigt.
Das Update blockt irgendwie die Kommunikation zwischen Cluster-Dienst, Hyper-V und RDS-Diensten (wer da mit wem kommunizieren muss weiss ich auch nicht so genau)."
Ansonsten läuft aber alles, Hyper-V und Failover-Cluster an sich sind in Ordnung.
Nur anmelden an den einzelen VM kann man sich nicht, weil auch der Broker irgendwie nicht mehr weiss was da auf dem Cluster vorhanden ist.
Das Update von 05/2024 hatte diesen Fehler noch nicht erzeugt. 06-08 haben wir ausgelassen, die kummulativen Update von 09+10/2024 erzeugen den beschriebenen Fehler.
Mit dem Workaround können die RDS-Dienste dann repariert werden, sind dann aber nach dem nächsten Update wieder kaputt (November wird dann zeigen ob es noch ein 3. Mal passiert).
sorry verstehe immer noch nicht, was der Cluster mit den RD-Rollen zutun haben sollen, oder habt Ihr auf den Clusterservern selbst eine RD-Rolle aktiviert?
ja, die Rollen sind auf den Cluster-Server aktiviert:
Cluster-Architektur:
Node#1 Rollen (R) und Feature (F):
-Dateiserver (R)
-Speicherdienste (R)
-Hyper-V (R)
-Remotedesktop-Verbindungsbroker (R)
-Remotedesktop-Virtualierungshost (R)
-Web Access für Remotedesktop (R)
-Webserver (R)
-Failover-Clustering (F)
Node#2 Rollen (R) und Feature (F):
-Dateiserver (R)
-Speicherdienste (R)
-Hyper-V (R)
-Remotedesktop-Lizenzierungsserver (R)
-Remotedesktop-Virtualierungshost (R)
-Web Access für Remotedesktop (R)
-Webserver (R)
-Failover-Clustering (F)
In den Remotedesktop-Diensten erstellt man 1-n Sammlungen virtueller Desktop. Damit wird ein Vorlage-VM, welche man vorgängig auf dem Hyper-V vorbereitet und "sysprept" hat, deployed (erstellt 1-n VM pro Sammlung). Dabei legt man fest ob die VMs innerhalb der Sammlung fix einem bestimmten (AD-)User zugeteilt werden oder die Benutzer beim Login über WebAccess-Portal oder RDP (mstsc.exe mit Zieladresse Cluster-DNS) die VM dynamisch zugeteilt bekommt. Die einzelnen VM sind dann Rollen im Failover-Clustermanager und laufen unter dem Hyper-V-Dienst. Auf welchem Node die VM angelegt werden bestimmt man bei erstellen der Sammlung. Kann später über den Failerover-Clustermanger beliebig angepasst werden (nur laufende VM moven oder VM inkl. VHDX).
Danke für die ausfühl. Beschreibung.
Dann muss ich mir keine Sorgen machen, da unser 3 Knoten Cluster nur Hyper macht, nichts mehr. Alles andere ist in VMs umgesetzt.
Ich denke, dass es ist leider ein individuelles Problem bei Euch. Man findest sonst nichts dergleichen im Netz, weder heute noch damals.
Ihr solltet den MS Support mit hohen Prio kontaktieren und ggf. eskalieren, die sollen sich das bei Euch anschauen.
Es hört sich aber schlicht nach möglichen kaputten Systemfiles an.
Sowas wie sfc /Scannow oder DISM Prüfungen schon mal probiert (ist zwar immer das gleiche blabla aber vielleicht hilfts). Ich würde einfach MS in die Mangel nehmen…
Was ggf. noch helfen könnte, dass ihr einfach das gleiche OS "drüberinstalliert" also quasi wie ein Upgrade und alle Settings beim Setup übernehmt. Sowas hatten wir bei einzelnen Server, die z.B. keine Rollen/Features mehr nachinstallieren liesen, damit konnte man den Server "reparieren" und seitdem waren die auch immer okay, auch nach Updates.
Danke für die Rückmeldung!
Wir haben jetzt auf einer Node die Systemdateien und Image überprüft:
sfc /scannow
> reparierte C:\\Windows\\System32\\SysFxUI.dll
> reparierte C:\\Windows\\System32\\WMALFXGFXDSP.dll
> meldete C:\\Windows\\System32\\LServer_PKConfig.xml als defekt, kann es nicht reparieren.
> meldete C:\\Windows\\System32\\tls_branding_config.xml als, defekt, kann es nicht reparieren.
Dann mit DISM Image erfolgreich repariert.
sfc /scannow
> repariert C:\\Windows\\System32\\LServer_PKConfig.xml
> repariert C:\\Windows\\System32\\tls_branding_config.xml
Die beiden Dateien hatten vor der Reparatur ein Änderungsdatum von 01/2024. Nach der Reparatur 06.10.2024. Der 06.10.2024 war der Sonntag vor dem 10/2024 Patch-Day.
Neustart des Server wird dann heute Abend gemacht. Anschliessend prüfen ob alles noch läuft.
Ab 11.11. installieren wir dann die kummulativen Update 11/2024 und sind gespannt ob die Remotedesktop-Dienste dann nicht mehr beschädigt werden.
Das Problem ist gelöst. Siehe https://www.borncity.com/blog/2024/11/15/patchday-nachlese-office-windows-fuer-12-november-2024/#comment-199299
Irgendwas muss da aber insgesamt faul sein. Seit dem Update spinnen unsere Clusterdienste auch unnormal.
Erstmal sind des nachts als das Update lief alle VM´s auf 2 Knoten nicht mehr erreichbar gewesen – weder per RDP noch per Hyper-V Konsole – nachdem die auf andere Knoten evakuiert wurden liefen die auf einmal wieder (ohne Neustart) als wäre nichts gewesen.
Hinzukommt noch eine kaputte Clusterreplikation. Diese funktioniert per TLS nicht mehr. Das haben wir noch nicht näher untersucht.
Es lässt sich aber konstituieren, dass es seit der Installation der letzte Patches massive Probleme in Clusterumgebungen gibt die nicht nur auf RDP begrenzt sind.
Wie ist es nach dem Zurückrollen des Updates?
Zumindest für 2019er Cluster kann ich das nicht bestätigen, muss dann exklusiv bei Win2022 sein.
Habe keine Möglichkeit das Replikationsproblem mit unserem Windows Server 2022 Cluster zu prüfen. Wenn der Failover-Clusterdienst aktiv ist, kann die Replikation auf Ebene Hyper-V nicht konfiguriert werden. Die Replikations-Rolle im Failover-Clusterdienst braucht zum replizieren ein anderes Failover-Cluster, steht hier aber keines zur Verfügung.
Bei uns sah das ganze jetzt ähnlich, aber ein bisschen anders aus – Node1 im Cluster hat zwar weiterhin die VMs gehostet und die meisten waren auch per RDP erreichbar (einige wenige überhaupt gar nicht mehr), allerdings konnten wir nicht evakuieren, dh wir mussten die Node neustarten und die VMs hart killen dabei. Nach dem Neustart war auf der Node und im Cluster wieder alles paletti. Ein paar Tage später war es dann die nächste Node… Mal schauen wann es wieder vorkommt
Ich habe seit 1-2 Monaten immer wieder Probleme mit dem Zugriff von W10 RDP clients auf W11 RDP Server.
Man sieht nur den Anmeldebildschirm und ab dort hängt es dann.
https://i.imgur.com/ihm9UZN.png
Manchmal hilft es sich mehrmals zu verbinden, manchmal aber nur, sich einmal lokal am PC anzumelden um die RDP Verbindung wieder zum Laufen zu bekommen.
Hat sonst noch jemand solche Probleme bemerkt?