11月17日。この日に配られるChrome 158で、RD Web Accessの画面は開かなくなります。RD Web Accessはブラウザーの「XSLT」という機能で画面を組み立てていて、Chromeがこの機能を158で止めるからです。
Microsoftは10月6日、この影響をサポート技術情報KB5130994で説明し、8日にはWindowsのメッセージセンターで管理者に備えを求めました。対象はWindows Server 2016〜2025のリモートデスクトップサービス（RDS）です。修正の時期は、まだ示されていません。
KB5130994の日本語版。表示されないのは強化の「必要な効果」と説明している出典: Microsoft「Microsoft Edge または Google Chrome で XSLT が無効になっていると、RD Web Access の読み込みに失敗する」（KB5130994）(引用)
KBは、表示されないことを不具合として扱っていません。「ここで説明する症状は、解決すべき問題ではなく、このグローバルな強化努力の必要な効果です」という説明です。つまり、待っていても元には戻らない変更なのです。
ChromeとEdgeが止める日
止まる日は、ブラウザーによって違います。
| ブラウザー |
XSLTが止まる版 |
安定版の予定 |
一時的に戻す方法 |
| Chrome |
158 |
2026年11月17日 |
XSLTEnabledのポリシー（176で削除の予定） |
| Edge |
159（既定でオフ） |
2026年12月10日の週 |
XSLTEnabledのポリシー（176で止める計画） |
Chrome Enterpriseのリリースノートによると、158の安定版では、オリジントライアルとエンタープライズポリシーの参加者を除くすべての利用者でXSLTが機能しなくなります。XSLTEnabledのポリシーはChrome 146から使えますが、176で削除する予定です。176の安定版は、2027年8月17日の予定。
Edgeは157でベータ版などのチャンネルのXSLTを先に切り、159の安定版で既定をオフにします。Edgeのリリースノートは、XSLTEnabledとオリジントライアルという2つの逃げ道も、Edge 176で止める計画だとしています。Edgeのほかの変更は、Edge 156の公開と157以降の変更の記事にまとめました。
XSLTが止まる日程と、Microsoftが示した3つの回避策作成: 編集部 / 出典: Microsoft（KB5130994・Windows message center・Microsoft Edgeのリリースノート）、Chrome Enterpriseのリリースノート、Chromium Dash
回避策は3つ、長く使えるのは1つ
KB5130994の回避策は、次の3つです。
まず、XSLTEnabledのポリシーを1にして、ブラウザーのXSLTを戻す方法があります。グループポリシーのほかレジストリでも設定でき、KBはEdge用とChrome用のコマンドを載せています。
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
設定したらブラウザーを再起動し、RD Web Accessのページが出るかを見ます。もっとも、この設定はブラウザー全体に効くうえ、176で使えなくなります。
次に、HTML5のWebクライアントに移る方法です。https://<サーバーのFQDN>/RDWeb/webclient/index.htmlにサインインすると、RDPファイルの一覧が出ます。ブラウザーの中でそのままつなぐことも、設定の画面からRDPファイルを落とすこともできます。ただし、Webクライアントはサーバー側で別に設定しておく必要があります。
最後が、EdgeのIEモードでRD Web Accessを開く方法。IEモードで開くページにRD WebのURLを登録します。初めて開くときにActiveXの許可を求められることがあり、KBは「許可」を選ぶよう案内しています。サインインしている利用者の資格情報で、シングルサインオンするためです。
3つを比べると、長く使えるのはWebクライアントでしょう。XSLTを戻す設定は176までのつなぎにすぎず、IEモードは古い仕組みに入口を預けることになります。来年の8月より前に、RD Web Accessの入口をWebクライアントへ移す計画を立てておきたいところです。
影響を受ける会社と受けない会社
- 影響を受ける: RDSのRD Web Accessのページから、社員がリモートアプリやデスクトップを開いている会社です。ChromeかEdgeで開いていれば、11月17日から順に表示できなくなります。
- すでに影響を受けている: ブラウザーのポリシーでXSLTを無効にしている会社です。KBの症状が、もう出ているはずです。
- 影響を受けない: RD Web Accessを使わず、リモートデスクトップ接続（mstsc）や配ったRDPファイルでつないでいる会社です。
- 影響を受けない: HTML5のWebクライアントだけを使っている会社です。KBは、これを回避策に挙げています。
11月17日までの段取り
- RD Web Accessのサーバーと、使っている部署を洗い出します。IISのアクセスログで /RDWeb/ への要求を数えると、使っている人の見当がつきます。
- 検証用のPCでXSLTEnabledを0（無効）にして、RD Web Accessを開きます。11月17日以降の状態を、先に再現できます。
- /RDWeb/webclient/ を開いて、Webクライアントが動いているかを見ます。まだなら、Microsoft LearnにあるWebクライアントの設定の手順で入れます。
- つなぎにXSLTEnabledを1にするなら、配る相手をRD Web Accessを使う人のPCに絞り、176で使えなくなることを台帳に書いておきます。
- 利用者への案内を用意します。「RD Web Accessの画面が出なくなったら、こちらのWebクライアントから入ってください」と、新しいURLを添えて伝えます。
RD Web Accessは、一度作ると何年も同じ画面のまま使われる入口です。それだけに、ブラウザーの側の変更で急に開かなくなると、問い合わせが一度に情シスへ集まります。11月17日の前に、検証用のPCで一度開いてみること。それだけで、当日の混乱はかなり減らせるはずです。
