Der Server läuft, die Anmeldeseite nicht

Eine Mitarbeiterin sitzt im Homeoffice und ruft wie jeden Morgen die Webadresse des Terminalservers auf. Statt der gewohnten Anmeldeseite steht im Browser nur „Unable to display RD Web Access". Der Server läuft, das Passwort stimmt. Das Problem liegt im Browser.

RD Web Access (Remote Desktop Web Access) ist die Webseite, über die sich viele Betriebe von außen an ihrem Terminalserver anmelden. Ein Terminalserver ist ein Windows-Server, auf dem mehrere Personen gleichzeitig arbeiten, jede in ihrer eigenen Sitzung. Man öffnet die Seite, meldet sich an, klickt auf das Programm oder den Desktop und arbeitet.

Google und Microsoft schalten in ihren Browsern eine Technik namens XSLT ab. Auf genau diese Technik baut RD Web Access seine Seite auf. Microsoft hat das am 6. Oktober 2026 im Supportartikel KB5130994 beschrieben. Zwei Tage später, am 8. Oktober 2026, folgte ein Eintrag im Windows message center, Microsofts offiziellem Meldungskanal für Windows. Die Überschrift: „Take action to prevent RD Web Access rendering failures".

Was Microsoft bestätigt

Der Supportartikel KB5130994 trägt den Titel „RD Web Access fails to load when XSLT is disabled in Microsoft Edge or Google Chrome". Er gilt für Windows Server 2016, 2019, 2022 und 2025. Die Kernpunkte:

  • Das Symptom: Ist XSLT in Edge oder Chrome abgeschaltet, lädt die Seite nicht. Es erscheint die Meldung „Unable to display RD Web Access".
  • Die Ursache: RD Web Access baut seine Oberfläche mit XSLT im Browser auf. XSLT ist eine Technik, mit der der Browser selbst Daten in eine darstellbare Seite umformt.
  • Die Einordnung: Microsoft sieht darin keinen Fehler. Wörtlich: „The symptoms described here are not issues to be solved but necessary effects of this global hardening effort." Die Symptome sind also keine Probleme, die man beheben müsste, sondern notwendige Folgen einer weltweiten Härtung der Browser, einer Sicherheitsmaßnahme.
  • Die Korrektur: Microsoft arbeitet nach eigener Aussage an einer Lösung und will mehr mitteilen, sobald sie verfügbar ist. Einen Termin gibt es nicht.

Im Message Center wird Microsoft deutlicher: „Organizations using RD Web Access should review and adopt one of the documented workarounds before the browser change affects their users." Wer RD Web Access nutzt, soll also einen der dokumentierten Auswege umsetzen, bevor die Änderung im Browser bei den eigenen Leuten ankommt.

Wann es so weit ist

Der Supportartikel selbst nennt weder Browser-Versionen noch Termine. Die stehen bei Google und in Microsofts Unterlagen zu Edge.

Chrome: Ab Chrome 158 funktioniert XSLT in der regulären Chrome-Version (Stable) laut Google nicht mehr. Ausgenommen sind nur Teilnehmer eines sogenannten Origin Trial, eines Testprogramms für Website-Betreiber, und Geräte, auf denen eine Unternehmensrichtlinie XSLT wieder erlaubt.

Edge: In Microsofts Liste der Edge-Änderungen mit großer Auswirkung auf Websites steht die Abschaltung von XSLT bei Version 159. In den Vorabkanälen Canary, Dev und Beta gilt sie schon ab Version 157. Laut Microsofts Kalender erscheint Edge 159 in der Woche ab 10. Dezember 2026. Microsoft bezeichnet diese Termine selbst als ungefähr. Dazu kommt: Edge wird gestaffelt verteilt. Das Datum markiert den Beginn der Verteilung, nicht den Tag, an dem jedes Gerät die neue Version hat.

Auf den Kalender übertragen heißt Microsofts Aufforderung: Wer RD Web Access mit Chrome öffnet, braucht eine Lösung vor dem 17. November 2026. Wer Edge nutzt, braucht sie vor der Woche ab 10. Dezember 2026.

Die drei Auswege laut Microsoft

KB5130994 nennt drei Wege. Keiner passt für jedes Gerät, und einer ist ausdrücklich nur auf Zeit gedacht.

Ausweg 1: XSLT per Richtlinie wieder einschalten

Auf dem Gerät, das die Anmeldeseite öffnet, lässt sich XSLT über die Richtlinie XSLTEnabled mit dem Wert 1 wieder einschalten. Das geht per Gruppenrichtlinie oder per Registry-Eintrag, getrennt für Edge und für Chrome. Microsoft beschreibt das ausdrücklich als vorübergehend („temporarily re-enable XSLT processing on the client device").

Wie lange diese Brücke trägt, ist je Browser unterschiedlich belegt:

  • Edge: Die Richtlinie gibt es seit Edge 147. Microsoft nennt sie vorübergehend und kündigt an, dass sie in einer künftigen Edge-Version entfällt. Ein Datum steht nicht dabei.
  • Chrome: Die Richtlinie gibt es seit Chrome 146. Zu ihrem Ende machen zwei Google-Seiten unterschiedliche Angaben. Die Entwicklerseite „Removing XSLT" nennt Chrome 176 am 17. August 2027: Dann enden Origin Trial und Unternehmensrichtlinie, XSLT ist für alle aus. Die Richtlinienseite von Chrome Enterprise schreibt dagegen: „This policy is a temporary measure, and will be removed in M164." Gemeint ist Chrome-Version 164. Beim Abruf am 9. Oktober 2026 widersprachen sich die beiden Seiten. Welche Angabe gilt, lässt sich daraus nicht ablesen.

Wichtig für die Praxis: Die Richtlinie wirkt nur auf dem Gerät, auf dem sie gesetzt ist. Auf zentral verwalteten Firmengeräten lässt sie sich per Gruppenrichtlinie verteilen. Bei Rechnern, die niemand zentral verwaltet, etwa privaten Geräten im Homeoffice, ist zu klären, wer sie dort einrichtet und ob man das überhaupt möchte.

Für Edge gibt Microsoft noch einen zweiten Hinweis. Unternehmen sollen die Gegenrichtung vorab testen, also XSLTEnabled auf „Disabled" setzen, um herauszufinden, welche Anwendungen von XSLT abhängen. Auf einem einzelnen Testgerät zeigt das vor dem Stichtag, ob RD Web Access oder eine andere Webanwendung im Betrieb betroffen ist.

Ausweg 2: der Webclient

Als zweiten Weg nennt Microsoft den HTML5-Webclient von RD Web Access. Seine Adresse endet auf /RDWeb/webclient/index.html. Dort startet die Sitzung direkt im Browser. Alternativ lässt sich über die Einstellungen eine RDP-Datei herunterladen, also eine Verbindungsdatei für das Remotedesktop-Programm.

Der Haken: Der Webclient ist nicht einfach da. Laut Microsoft wird er separat installiert und veröffentlicht, über ein eigenes PowerShell-Modul. Microsoft setzt dafür unter anderem voraus:

  • eine Bereitstellung mit RD-Gateway (dem Zugangspunkt für Verbindungen von außen), RD-Verbindungsbroker (er verteilt die Anmeldungen) und RD Web Access;
  • Zugriffslizenzen pro Benutzer statt pro Gerät (Benutzer-CALs statt Geräte-CALs), denn sonst werden laut Microsoft alle Lizenzen verbraucht;
  • öffentlich vertrauenswürdige Zertifikate für Gateway und Web Access.

Hinzu kommt eine Pflegeaufgabe. Das Zertifikat des Verbindungsbrokers muss nach jeder Erneuerung neu importiert werden, sonst kommt beim Verbinden eine Fehlermeldung.

Für viele kleine Terminalserver ist der Webclient damit kein Ausweg für den nächsten Tag. Ob er bei Ihnen schon eingerichtet ist, weiß Ihr Dienstleister. Eines sagt KB5130994 übrigens nicht: ob der Webclient selbst von der XSLT-Abschaltung berührt ist. Microsoft führt ihn als Ausweg, mehr nicht.

Ausweg 3: Internet-Explorer-Modus in Edge

Laut Microsoft ist es in Edge möglich, die Adresse von RD Web Access im Internet-Explorer-Modus zu öffnen. Dazu wird die Adresse in die Liste der Seiten aufgenommen, die Edge in diesem Modus darstellt. Dieser Weg gilt nur für Edge, nicht für Chrome.

Was Sie Ihren Dienstleister fragen

Die Einstellungen selbst müssen Sie nicht kennen. Diese Fragen reichen, um den Stand zu klären:

  1. Nutzen wir RD Web Access, und wer meldet sich darüber an: Mitarbeitende im Homeoffice, Außendienst, externe Partner?
  2. Mit welchen Browsern und von welchen Geräten aus geschieht das: von verwalteten Firmengeräten oder auch von privaten Rechnern?
  3. Welchen der drei Auswege aus KB5130994 planen Sie für uns, und ist er für Chrome vor dem 17. November 2026 und für Edge vor der Woche ab 10. Dezember 2026 umgesetzt?
  4. Ist der Webclient bei uns eingerichtet? Falls nein: Erfüllt unsere Umgebung die Voraussetzungen, also RD-Gateway, Benutzer-CALs und öffentlich vertrauenswürdige Zertifikate, und was würde die Einrichtung kosten?
  5. Falls wir die Richtlinie nutzen: Mit welchem Enddatum planen Sie, und was ist der Weg danach?
  6. Wer sagt den Nutzern vorher Bescheid, was sie tun sollen, wenn statt der Anmeldeseite die Fehlermeldung erscheint?

Die letzte Frage geht leicht unter. Dabei sieht eine Fehlermeldung, mit der niemand gerechnet hat, für Nutzer aus wie ein Serverausfall. Ein kurzer Hinweis vorab kann Ihnen Rückfragen am ersten Morgen ersparen.

Was offen ist

Einige Punkte lassen Microsoft und Google offen. Stand 9. Oktober 2026:

  • Microsofts Korrektur: angekündigt, ohne Termin. Was sie ändert und ob sie die Auswege überflüssig macht, ist nicht bekannt.
  • Ende der Chrome-Richtlinie: Google nennt an zwei Stellen zwei verschiedene Versionen, 164 auf der Richtlinienseite und 176 (17. August 2027) auf der Entwicklerseite. Welche gilt, ist ungeklärt.
  • Ende der Edge-Richtlinie: Microsoft nennt sie vorübergehend, aber ohne Datum. Das Chrome-Datum lässt sich nicht auf Edge übertragen.
  • Edge-Termin: Die Woche ab 10. Dezember 2026 ist ein geplanter Termin. Microsoft nennt ihn ungefähr, die Verteilung läuft gestaffelt.
  • Webclient: Microsoft bietet ihn als Ausweg an, sagt in KB5130994 aber nicht, ob er von der Abschaltung betroffen ist.
  • Remotedesktop-Programm: Wer sich nicht über die Webseite, sondern direkt mit dem Remotedesktop-Programm verbindet, findet dazu in KB5130994 keine Aussage.

Bleiben Sie bei diesen Punkten mit Ihrem Dienstleister im Gespräch. Die Richtlinie verschafft Zeit, einen dauerhaften Weg ersetzt sie nicht.

Einordnung

Die Änderung kommt aus dem Browser, nicht vom Server. Microsoft arbeitet an einer Korrektur, nennt dafür aber keinen Termin. Bis dahin entscheidet sich die Sache am Arbeitsplatz: mit welchem Browser und von welchem Gerät aus Ihre Leute die Anmeldeseite öffnen. Ein anderes Remotedesktop-Problem aus dem September 2026 beschreiben wir im Artikel zum Remotedesktop-Notfallupdate für Windows Server.

Wir planen, migrieren und betreiben Serverumgebungen für kleine und mittlere Betriebe. Wenn Sie wissen möchten, welcher Weg für Ihren Terminalserver passt, sprechen Sie uns gern an.

Quellen

Alle Quellen abgerufen am 9. Oktober 2026.