RD Web Access non si carica in Edge e Chrome: XSLT rimosso, KB5130994 e soluzioni

Articolo aggiornato al 14 ottobre 2026. La situazione è ancora in evoluzione: lo aggiornerò se Microsoft rilascia una correzione per RD Web Access.

Gli utenti aprono il portale di Accesso Web Desktop remoto come tutte le mattine e, invece dell’elenco delle RemoteApp, si trovano davanti una pagina bianca con “Unable to display RD Web Access” e “An unexpected error has occurred that is preventing this page from being displayed correctly”. Il server è a posto, IIS risponde, i certificati sono validi: il problema è nel browser.

La pagina classica di RD Web Access (/RDWeb/Pages/) viene disegnata lato client con XSLT, una tecnologia di trasformazione XML che Google sta togliendo da Chromium per motivi di sicurezza. Con Chrome 158, previsto per il 17 novembre 2026, XSLT smette di funzionare per tutti, ed Edge segue lo stesso percorso. Microsoft ha già pubblicato l’articolo KB5130994 e l’avviso MC1491832 nel Message Center di Microsoft 365: c’è circa un mese per prepararsi, e conviene usarlo.

Chi è coinvolto

Chi ha un’infrastruttura Remote Desktop Services su Windows Server 2016, 2019, 2022 o 2025 con il ruolo Accesso Web Desktop remoto e lo usa dal portale web classico.
Utenti che aprono il portale con Chrome, Edge o altri browser basati su Chromium.
Chi ha già disattivato XSLT con una policy del browser (ad esempio applicando baseline di sicurezza recenti): in quel caso l’errore si vede già oggi.

Chi si collega solo con file RDP, con il feed RemoteApp configurato nel client o con il client web HTML5 non è toccato dal problema.

Perché succede

Secondo Google, l’XSLT lato client riguarda una frazione minima del traffico web e si appoggia a librerie vecchie, con un passato di vulnerabilità di memoria. La tabella di marcia di Chrome è chiara: dalla versione 158 XSLT è spento nel canale Stable, tranne per chi lo riattiva con la policy aziendale XSLTEnabled o con l’origin trial. Dalla versione 176, prevista per agosto 2027, anche la policy smetterà di funzionare e XSLT sparirà del tutto. Microsoft dice di essere al lavoro su una correzione per RD Web Access, ma al momento non c’è una data.

Prima di iniziare

Il mio consiglio è di non aspettare che arrivino le chiamate degli utenti il 18 novembre. Su un PC di prova potete simulare già adesso il comportamento futuro impostando la policy al contrario (valore 0) e aprendo il portale:

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

Riavviate Edge, verificate in edge://policy che la policy sia applicata e aprite https://rdweb.example.com/RDWeb/. Se vedete l’errore, siete tra i coinvolti. Finito il test, cancellate il valore con reg delete "HKLM\SOFTWARE\Policies\Microsoft\Edge" /v XSLTEnabled /f.

Le tre soluzioni indicate da Microsoft

1. Riattivare XSLT con la policy del browser. È la via più rapida e la meno invasiva per gli utenti: si imposta XSLTEnabled a 1. Da prompt dei comandi con privilegi amministrativi:

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

Su più di due o tre PC io non lo farei a mano: in dominio usate una GPO con le Preferenze di Criteri di gruppo (Configurazione computer → Preferenze → Impostazioni di Windows → Registro di sistema) oppure la policy dei modelli ADMX, se la versione che avete in archivio centrale è abbastanza recente da includerla; con Intune un profilo con le stesse chiavi. Dopo il riavvio del browser controllate in edge://policy o chrome://policy che il valore sia arrivato.

Attenzione: è una pezza a tempo. Riaccendete una funzione che Google spegne per motivi di sicurezza, e su tutti i siti, non solo sul vostro portale. Inoltre da Chrome 176 la policy non avrà più effetto. Va bene per guadagnare tempo, non come soluzione definitiva.

2. Passare al client web HTML5. È la soluzione che preferisco, perché non dipende da XSLT né da componenti legacy. Se l’avete già pubblicato, gli utenti trovano tutto su https://rdweb.example.com/RDWeb/webclient/index.html: possono lavorare direttamente nel browser oppure, dalle impostazioni del client, scegliere di scaricare il file RDP e usare il client Desktop remoto di Windows. Se invece il client web non è mai stato installato sul server RD Web, va prima distribuito e collegato al certificato del broker: fatelo e provatelo con calma, non la mattina in cui il portale smette di funzionare.

3. Aprire il portale in modalità Internet Explorer di Edge. In Edge: Impostazioni → Browser predefinito → “Consenti il ricaricamento dei siti in modalità Internet Explorer” su Consenti, poi aggiungete l’indirizzo del portale tra le pagine in modalità IE e riavviate il browser. Al primo accesso può comparire la richiesta di consenso per il controllo ActiveX, che serve anche per l’accesso Single Sign-On. Per più postazioni conviene distribuire l’elenco siti in modalità aziendale tramite policy invece di configurare ogni PC a mano.

Lo sconsiglio come strada principale: significa rimettere in gioco il motore di Internet Explorer per tenere in vita un portale. Lo terrei come piano di riserva per chi ha davvero bisogno del Single Sign-On del portale classico.

Come mi organizzerei

Verificate quali clienti o sedi usano ancora il portale /RDWeb/ classico: i log di IIS sul server RD Web sono il posto più veloce dove guardare.
Prima di metà novembre distribuite la policy XSLTEnabled a 1 dove serve, così nessuno resta fermo.
Nel frattempo pubblicate e testate il client web HTML5, oppure configurate il feed RemoteApp (https://rdweb.example.com/RDWeb/feed/webfeed.aspx) in “Connessioni RemoteApp e desktop” sui PC, così le applicazioni compaiono nel menu Start senza passare dal browser.
Quando gli utenti sono migrati, togliete la policy: meno eccezioni restano in giro, meglio è.

Se il problema persiste

Se avete impostato la policy ma il portale continua a non caricarsi, controllate prima in edge://policy o chrome://policy che XSLTEnabled compaia con valore 1 e senza errori: una GPO filtrata male che non arriva al computer o un valore scritto come stringa invece che REG_DWORD sono gli intoppi più comuni. Ricordate anche che altri browser basati su Chromium hanno le proprie chiavi di policy e vanno gestiti a parte. Se l’errore compare solo con alcuni utenti, verificate quale browser stanno usando davvero: spesso c’è qualcuno con una versione Beta o Canary, dove XSLT è già disattivato per impostazione predefinita. Infine tenete d’occhio KB5130994: quando Microsoft rilascerà la correzione per RD Web Access, sarà lì che verrà annunciata.

Vi è capitato di trovare il portale RD Web Access bianco dopo un aggiornamento del browser? Raccontate nei commenti quale soluzione avete scelto e come è andata con gli utenti: possono essere utili ad altri.