RD Web Access: Fast ein Jahr Vorlauf, drei Notlösungen – Grams IT

Wer RD Web Access betreibt, also das Webportal der Remotedesktopdienste von Windows Server, bekommt Mitte November ein Problem. Google will XSLT mit Chrome 158 für alle Nutzer der Stable-Version abschalten, geplant ist der 17. November 2026. Das Portal braucht genau diese Browserfunktion, um seine Oberfläche aufzubauen. Ohne sie sehen Ihre Nutzer eine Fehlermeldung statt ihrer RemoteApps.

Microsoft hat dazu am 6. Oktober den Supportartikel KB5130994 veröffentlicht und zwei Tage später über das Message Center nachgelegt. Einen Fix gibt es noch nicht, nur drei Umgehungen. Ich gehe sie hier durch und sage, welche ich nehmen würde.

Was Microsoft in KB5130994 und im Message Center mitteilt

Der Supportartikel KB5130994 gilt für Windows Server 2016, 2019, 2022 und 2025. Betroffen ist damit jede noch unterstützte RDS-Umgebung, in der das mitgelieferte Webportal läuft. Die Fehlermeldung im Browser lautet Unable to display RD Web Access.

Am 8. Oktober folgte die Message-Center-Meldung MC1491832, eingestuft als „Major change“ mit Auswirkung für Admins. Sie sagt im Kern dasselbe: Nutzer könnten nicht mehr auf ihre Remote-Ressourcen zugreifen, Organisationen sollen sich vorbereiten. Einen Termin nennt Microsoft nicht, in der Meldung steht nur „in the short term“.

Unter „Lösung“ steht im Supportartikel, Microsoft arbeite daran und werde sich melden. Im selben Artikel heißt es aber auch, die Symptome seien kein Problem, das gelöst werden müsse, sondern eine notwendige Folge der branchenweiten Härtung. Beides zusammen passt nicht recht. Ich lese es so: Der Fix kommt irgendwann, einen Termin sollte man nicht einplanen.

Warum RD Web Access ohne XSLT nicht lädt

XSLT ist eine Sprache, die XML-Daten in andere Formate umwandelt, im Browser meist in HTML. RD Web Access liefert seine Inhalte als XML aus und überlässt die Umwandlung dem XSLT-Prozessor des Browsers. Fehlt der, bleibt es bei der Fehlermeldung.

Dass der Prozessor verschwindet, hat einen guten Grund. Google begründet den Schritt in seiner Ankündigung zur XSLT-Entfernung vom 29. Oktober 2025 mit der Bibliothek libxslt, einer alten C-Codebasis mit wiederholt schweren Speicherfehlern. Als Beispiele nennt Google CVE-2025-7425 und CVE-2022-22834. Genutzt werde XSLT nur noch bei etwa 0,02 Prozent aller Seitenaufrufe. Laut Google haben auch die Firefox- und WebKit-Projekte angekündigt, XSLT zu entfernen.

Fairerweise: Aus Sicht eines Browserherstellers ist das die richtige Entscheidung. Eine kaum genutzte Funktion, die regelmäßig Lücken für Codeausführung liefert, gehört nicht in ein Programm, das ungeprüfte Inhalte aus dem Internet verarbeitet. Nur stecken in den 0,02 Prozent eben auch Portale, über die ganze Belegschaften an ihre Arbeitsumgebung kommen.

Der Zeitplan: XSLT in Chrome 158 und Edge

Google hat den Ablauf früh veröffentlicht. Die Stationen laut Chrome-Dokumentation:

Chrome 142 (28. Oktober 2025): erste Warnungen in der Konsole
Chrome 143 (2. Dezember 2025): offizielle Abkündigung
Chrome 146 (10. März 2026): Unternehmensrichtlinie XSLTEnabled verfügbar
Chrome 152 (25. August 2026): Origin Trial für Websites startet
Chrome 158 (17. November 2026): XSLT in Stable aus, außer mit Richtlinie oder Origin Trial
Chrome 176 (17. August 2027): Richtlinie und Origin Trial enden

Für Edge gibt es keine eigene Zusage. Laut Edge-Veröffentlichungsplan ist Version 158 für die Woche des 19. November 2026 im Stable-Kanal vorgesehen, und Edge-Hauptversionen folgen dem jeweiligen Chromium-Release. Dass Edge 158 XSLT abschaltet, ist deshalb naheliegend, von Microsoft aber nicht ausdrücklich bestätigt.

Bei der Laufzeit der Richtlinie widersprechen sich Googles eigene Seiten. Die Entwicklerdokumentation nennt Chrome 176, die Richtlinienbeschreibung bei Chrome Enterprise dagegen eine Entfernung in M164. Microsoft schreibt zur Edge-Richtlinie nur, sie sei temporär. Ich plane mit dem früheren Wert.

Drei Workarounds für RD Web Access im Vergleich

XSLT per Richtlinie XSLTEnabled wieder einschalten

Das ist der schnellste Weg. Die Richtlinie XSLTEnabled mit dem Wert 1 hält XSLT am Leben, unabhängig vom Standard des Browsers. Microsoft nennt im Supportartikel diese Befehle für eine Eingabeaufforderung mit erhöhten Rechten:

reg add "HKLM\SOFTWARE\Policies\Microsoft\Edge" /v XSLTEnabled /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Policies\Google\Chrome" /v XSLTEnabled /t REG_DWORD /d 1 /f

In der Domäne setzen Sie das besser per Gruppenrichtlinie. Die Edge-Richtlinie XSLTEnabled liegt unter „Administrative Templates/Microsoft Edge“ und wird ab Edge 147 unterstützt. Danach den Browser neu starten.

Die Richtlinie hat zwei Schwächen. Sie schaltet XSLT für alle Websites wieder ein, nicht nur für Ihr Portal, und damit auch die Angriffsfläche, die Google gerade entfernen will. Und sie erreicht nur verwaltete Geräte. Der private Rechner im Homeoffice oder das Notebook eines externen Dienstleisters bekommt Ihre GPO nicht.

Der HTML5-Webclient als Ersatz

Der Remotedesktop-Webclient ist eine eigene Webanwendung auf dem RD-Web-Access-Server und kommt ohne XSLT aus. Er liegt unter https://<Server-FQDN>/RDWeb/webclient/index.html. Nutzer starten ihre Sitzung dort direkt im Browser oder laden die RDP-Datei herunter.

Installiert wird er per PowerShell aus der PowerShell Gallery, die Schritte stehen in Microsofts Anleitung zum Remotedesktop-Webclient. Die Voraussetzungen sind nicht in jeder Umgebung erfüllt: RD-Gateway, Verbindungsbroker und RD Web Access, Lizenzierung pro Benutzer statt pro Gerät sowie öffentlich vertrauenswürdige Zertifikate für Gateway und Web Access. Hinter einem Web Application Proxy wird der Client laut Microsoft nicht unterstützt.

Wer seinen Nutzern weiter RDP-Dateien geben will, kann das erzwingen:

Set-RDWebClientDeploymentSetting -Name "LaunchResourceInBrowser" $false

Edge im Internet-Explorer-Modus

Der dritte Weg: die Portal-URL in Edge in die Liste der Seiten für den IE-Modus aufnehmen. Beim ersten Aufruf fragt Edge laut Microsoft nach der Erlaubnis für ActiveX, damit das einmalige Anmelden funktioniert.

Ich halte das für die schwächste der drei Optionen. Eine Sicherheitshärtung mit dem Internet-Explorer-Modus und ActiveX zu umgehen, ist ein seltsamer Tausch. Chrome-Nutzern hilft es ohnehin nicht.

Was das für Kommunen und kleine IT-Abteilungen bedeutet

RD Web Access ist in vielen Verwaltungen der Einstieg für alle, die nicht am Büroarbeitsplatz sitzen: Homeoffice, Außenstellen, Bereitschaftsdienste, externe Dienstleister. Fällt das Portal aus, landen die Anrufe bei Ihnen, und zwar am Morgen nach dem Browserupdate. Browser aktualisieren sich gestaffelt, die Meldungen kommen also über Tage verteilt.

Das Verhalten lässt sich schon heute nachstellen. Setzen Sie XSLTEnabled auf einem Testrechner auf 0, dann ist XSLT dort abgeschaltet und Sie sehen, was Ihre Nutzer im November sehen. Prüfen Sie dabei auch, wer von unverwalteten Geräten kommt, denn für diese Gruppe scheidet die Richtlinie aus.

Meine Reihenfolge wäre: jetzt den Webclient einrichten und testen, die Richtlinie als Überbrückung für verwaltete Geräte verteilen und den Nutzern die neue Adresse rechtzeitig mitteilen. Die Richtlinie allein verschiebt das Problem nur. Ob der Webfeed für „RemoteApp- und Desktopverbindungen“ ebenfalls betroffen ist, sagt Microsoft nicht. Ich habe es nicht getestet.

Ein Wort zu Microsoft. Google hat die Abschaltung am 29. Oktober 2025 angekündigt, der Supportartikel erschien am 6. Oktober 2026. Zwischen dem Artikel und dem Stichtag in Chrome liegen sechs Wochen. Für eine Komponente, die seit Server 2016 in jedem RDS-Deployment steckt, ist das zu knapp, zumal das Ergebnis drei Notlösungen sind und kein Update.

Fazit

RD Web Access hängt an einer Browserfunktion, die Chrome am 17. November 2026 abschaltet und Edge voraussichtlich in derselben Woche. Die Abschaltung ist sicherheitstechnisch begründet, wurde früh angekündigt und kommt trotzdem für viele überraschend, weil Microsoft erst im Oktober reagiert hat. Die Richtlinie XSLTEnabled verschafft Zeit, der HTML5-Webclient löst das Problem.

Stellen Sie diese Woche auf einem Testclient XSLTEnabled auf 0 und rufen Sie Ihr Portal auf. Danach wissen Sie, wie viel Arbeit bis zum 17. November vor Ihnen liegt.

Quellen: