PatchFactoryVeille
Menu
← Toutes les publications
RDS · Edge/ChromeMis à jour le 23 octobre 20267 min de lecture

RD Web Access : tester les portails avant de désactiver XSLT dans Edge ou Chrome

RD Web Access classique dépend de XSLT côté navigateur. Le calendrier annoncé par Microsoft pour Edge — désactivation par défaut en Stable 159, puis fin des exceptions temporaires prévue en 176 — impose de qualifier une alternative et de tester les portails avant ces changements.

Impact
Portails RD Web Access classiques ouverts dans Edge et dépendants de XSLT, y compris à terme lorsque la politique n’est pas configurée. Chrome reste concerné si XSLT y est désactivé, sans transposer le calendrier Edge.
Action
Inventorier les portails, tester leur rendu avec XSLT désactivé, puis qualifier l’alternative avec l’équipe RDS avant Edge Stable 159.
Statut
À planifier

Ce qui change

Microsoft a publié la KB 5130994, datée du 6 octobre 2026, pour expliquer un problème de rendu de RD Web Access. Le portail RDS utilise un traitement XSLT côté client pour afficher son interface. Si XSLT est désactivé par politique dans Microsoft Edge ou Google Chrome, la page RD Web Access ne se rend plus correctement. Microsoft précise que ce comportement est lié au durcissement des navigateurs autour de XSLT, pas à une panne ponctuelle du portail.

Le message visible côté utilisateur peut ressembler à Unable to display RD Web Access avec un texte indiquant qu'une erreur inattendue empêche l'affichage de la page. Le périmètre est donc étroit mais concret : ce n'est pas tout RDS, ni tous les navigateurs, ni tous les utilisateurs. Ce sont les accès RD Web Access classiques qui dépendent de XSLT, lorsque les politiques navigateur le bloquent.

La documentation Edge confirme l'existence de la politique XSLTEnabled. Sur Windows, elle est supportée à partir d'Edge 147 et peut être imposée via ADMX sous Administrative Templates/Microsoft Edge, avec la valeur de registre SOFTWARE\Policies\Microsoft\Edge\XSLTEnabled. Microsoft indique aussi que cette politique est temporaire et sera retirée dans une future version de Microsoft Edge. Cette mention limite fortement la valeur d'une exception permanente.

Les notes Edge 156 publiées le 22 octobre précisent le calendrier annoncé : XSLT natif sera désactivé par défaut dans Canary, Dev et Beta à partir d’Edge 157, puis dans Stable à partir d’Edge 159. Cela concerne XSLTProcessor et les instructions XML référençant une feuille XSLT, pas les feuilles CSS. Microsoft prévoit que la politique XSLTEnabled et l’origin trial temporaire cesseront de fonctionner avec Edge 176. Ce sont des jalons de version annoncés, pas des dates calendaires garanties ; ne pas les appliquer à Chrome par analogie.

Qui est concerné

Le sujet concerne les organisations qui exposent encore RD Web Access aux utilisateurs, notamment pour publier des bureaux ou RemoteApps, et qui appliquent des baselines navigateur strictes. Les parcs qui n'utilisent pas RD Web Access classique ne doivent pas transformer cette KB en chantier global Edge.

Les équipes Workplace sont concernées lorsque la politique navigateur est distribuée par Intune, GPO ou un autre outil de gestion poste. Les équipes infrastructure RDS sont concernées pour valider l'alternative côté service, notamment le Remote Desktop web client HTML5 documenté par Microsoft.

Actions recommandées

Commencer par l'inventaire : lister les URL RD Web Access encore publiées, les populations qui les utilisent, les navigateurs supportés et les politiques Edge/Chrome appliquées. Le résultat attendu est une matrice simple : portail utilisé ou non, XSLT désactivé ou non, alternative déjà disponible ou non.

Tester ensuite la politique dans un anneau représentatif. Si XSLT doit être désactivé pour durcissement, le test doit vérifier que le portail RD Web Access se charge, que les utilisateurs récupèrent bien leurs ressources et que le support sait reconnaître le message d'erreur. Si le portail échoue, Microsoft documente trois contournements : réactiver temporairement XSLT, utiliser le client web HTML5 pour accéder aux ressources ou télécharger les fichiers RDP, ou utiliser le mode IE dans Microsoft Edge.

La meilleure trajectoire à moyen terme est rarement de figer XSLT à enabled partout. La politique Edge est explicitement temporaire, et Microsoft travaille sur un correctif. Une exception peut être utile pour éviter une rupture utilisateur, mais elle doit être limitée aux postes ou profils qui utilisent le portail concerné, avec une revue prévue lorsque Microsoft publiera une résolution.

Sur un groupe de test utilisant un portail existant, comparer le rendu et l’accès aux ressources avant et après désactivation de XSLT. Si le portail échoue, ne pas étendre cette configuration aux utilisateurs concernés avant qualification de l’alternative. Une réactivation temporaire par politique peut maintenir l’accès, mais son retrait annoncé empêche d’en faire la solution durable.

Points de vigilance

Ne pas déployer aveuglément la commande de registre donnée dans la KB. Elle illustre une réactivation de XSLT depuis une invite élevée, mais le bon canal en production est la gestion de politique déjà utilisée : GPO, Intune ou outil navigateur. Le contrôle attendu est simple : ouvrir le portail RD Web Access depuis un poste ciblé, vérifier le chargement de la page, puis confirmer que l'utilisateur peut lancer ou récupérer la ressource attendue.

Le client web HTML5 n'est pas un simple bouton à activer côté poste. La documentation Microsoft décrit des prérequis côté déploiement RDS, notamment RD Gateway, RD Connection Broker, RD Web Access, certificats publics approuvés et configuration du package web client. Si cette alternative n'est pas déjà en place, elle doit être qualifiée avec l'équipe RDS avant d'être proposée comme contournement utilisateur.

Sources