Windows Server 2022: Probleme mit RDS, WebView2-Runtime und FXLogix

Ein Leser informiert mich kürzlich, dass bei ihm diverse lokale Drucker, die per RDS an einem Terminalserver unter Windows Server 2022 angebunden waren, plötzlich nicht mehr funktionieren. Er verortet dies zuerst in der WebView2 Runtime-Version 129.0.2792.79. Beim Leser waren mehrere Kunden betroffen, wie er schrieb. Später kam er auf die Ursache: Eine durch einen Administrator vorgenommene Manipulation der Registrierungseinträge wegen eines Konflikts mit FSLogix, ein Fix, der aber nur Windows Server 2019 gilt. Ein Lehrbeispiel, wie man bei der Fehlerdiagnose in die Irre geführt werden kann.

Blog-Leser Axel hatte mich bereits am 9. Oktober 2024 per Mail kontaktiert – dass Ganze ist aber unter dem Schwall an Mails, die ich täglich bekomme, etwas „versumpft“. Ich hole es aber mal hoch und stelle es hier im Blog ein, weil der Fall zeigt, dass der Teufel manchmal „im Detail steckt“.

RDS-Problem auf Windows Server 2022

Der Leser schrieb, dass er „gerade“ ein massives Problem habe, welches nach der Installation des Microsoft WebView2 Runtime-Version 129.0.2792.79 auftrat. Auf den Terminalservern funktionieren die per Remote Desktop-Dienste angebunden lokalen Drucker wie beispielsweise „Microsoft print  to pdf“ oder Etikettendrucker welche eine  bidirektionale Verbindung benötigen, nicht mehr.

Update WebView2 Runtime auf Version 129.0.2792.79 im Verdacht

Aufgefallen ist dem Leser, dass ein Update ab dem 03.10. 2024, bzw. meist am 04.10.2024, die Microsoft WebView2 Runtime auf die Version 129.0.2792.79 aktualisiert hat. Beim Recovery der Terminalserver VM auf einen Tag davor 02.10. klappt wieder alles.

Krudes Fehlerbild: Neustarts können helfen

Der Leser schrieb mir in seiner Mail, dass es, wenn man sich nach mehreren Neustarts anmeldet, mit der Druckeranbindung wieder funktioniert. Das ist aber keine Dauerlösung, denn der Terminalserver macht über Nacht, um 04:30 Uhr, ein Reboot. Danach funktioniert die Druckeranbindung plötzlich wieder nicht mehr. Die Drucker stehen dann alle wieder auf „nicht verbunden“.

Fast alle Kunden betroffen

Axel schriebt in der ersten Mail dazu, dass er in seiner Umgebung nicht genau definieren könne, ob bereits vor dem Update der WebView2 Runtime etwas im System passierte. Das Problem ziehe sich nach seiner Aussage über nahezu alle Kunden mit Windows Server 2022 mit aktivierter RDS/Terminalserver Rolle hin.

Warum nicht alle Kunden betroffen waren, war beim Auftreten unklar. Aber bei einer solchen Aussage stellt sich spontan die Frage: „Was ist bei betroffenen Kunden anders als beim Rest“. Oder anders ausgedrückt: Die WebView2-Runtime löst zwar den Fehler aus, ist aber nicht die Ursache

Lösung: FXLogix „Fix“ funkt mit rein

In einem Nachtrag hat Axel sich dann nochmals gemeldet und schrieb, dass man die Ursache für das merkwürdige Verhalten gefunden habe. Das Problem lag in diesem Fall an einem PowerShell-Script, welches von einem internen Admin für eine gut gemeinte Verbesserung verwendet wurde.

Hintergrund war, dass am 03.10.2024 ein Kunde mit einer Terminalserverfarm auf FSLogix-Profile umgestellt wurde. Darauf hin war festzustellen, dass die Performance schlecht war. Der Administrator erinnerte sich an den Artikel FSLogix slow sign-in (fix), und setzte die Informationen um.

Der Administrator hat dann ein PowerShell-Script laufen lassen, welches wohl in der Registrierung herum fuhrwerkte und folgende Befehle verwendet.

Remove-Item "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Notifications" -Recurse

New-Item "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Notifications"

Das Problem: Der oben erwähnte Artikel stammt aber aus dem Jahr 2021 und bezog sich auf Windows Server 2016. Axel schrieb, dass der Administrator nicht weiter gelesen habe, dass es unter Windows Server 2019 Probleme gab und das Script nicht für Windows Server 2022 galt. Unter Windows Server 2022 waren die Vorschläge aus dem Artikel am Ende des Tages daher kontraproduktiv, führten sie doch zum oben skizzierten Druckerproblem.

Nachdem die Leute der Ursache für das oben skizzierte Problem auf die Schlichte gekommen waren, begannen sie, die Registrierung der letzten Tage auf den betroffenen Maschinen zurück zu lesen.

Da ist er wieder, der klassische Fall von „Koinzidenz ist kein Beweis für Kausalität“ – zwei Ereignisse, die gleichzeitig passierten, zu einem Fehlerbild führten, aber zuerst die Leute in die Irre führten und nach Problemen in der WebView2-Runtime suchen ließen. Auch die Rücksicherung auf den 2. Oktober 2024 ergab ein falsches Bild, weil da sowohl WebView 2 als auch die Änderungen durch das Script zurückgenommen wurden.

Vermutlich hat man die WebView 2 Runtime wieder installieren lassen und als alles gut war, erinnerte sich der Administrator „da war doch was“. Kleine Ursache, große Wirkung. Daher habe ich die Geschichte im Hinblick auf spannende IT-Probleme „als Wort zum Freitag“ einfach mal online gestellt. Vielleicht kann jemand mal zukünftig in einem ähnliche Szenario mal „Heu“ daraus machen.