WindowsでRemoteAppのファイル関連付けが壊れたときは、最初に「ローカルアプリが開くのか」「RemoteAppは起動するのにファイルが開かないのか」「そもそも拡張子候補が出ないのか」を切り分けるのが最短です。RemoteAppの文書関連付けは、Windowsの通常の既定アプリ設定だけで完結せず、RemoteApp and Desktop Connections のフィード、RDS側で公開されたファイル関連付け、そしてローカルファイルにサーバー側から到達できるかどうかに左右されるからです。(Microsoft Learn)
この記事では、WindowsでRemoteAppのファイル関連付けが壊れたときに、どこを見ればよいか、何から直すべきか、そして再発しにくい運用にどう寄せるかまで、実務目線でまとめます。
RemoteAppのファイル関連付けは、普通の既定アプリ設定とは別に見る
Microsoftの現行ポリシー定義では、RemoteApp and Desktop Connections の既定接続URLは、文書ファイルの種類をRemoteAppに関連付けるための仕組みとして説明されています。RDSのRD Web Accessは、Webポータルだけでなく feeds を通じて、ユーザーに許可されたアプリやデスクトップを配布します。つまり、RemoteAppのファイル関連付けは「クライアントPCの既定アプリ」だけの問題ではなく、「正しいフィードを受け取っているか」が前提です。(Microsoft Learn)
ここで迷いやすいのがURLの書式です。古い検証ガイドでは GPO の例として https://サーバー名/RDWeb が載っていますが、現行の Policy CSP では既定接続URLを https://contoso.com/rdweb/Feed/webfeed.aspx 形式で説明しています。環境が古い資料を参考に構築されていると、この違いで切り分けが止まりやすいので、まずクライアントに実際に登録されているURLを確認するのが安全です。(Microsoft Learn)
もう1つ重要なのは、RDSがサーバー側アプリの拡張子情報を参照している点です。MicrosoftのWMIドキュメントでは、アプリの現在のファイル関連付けをレジストリからスキャンし、アプリが扱う拡張子一覧を取得する仕組みが示されています。RemoteAppのファイル関連付けが空になるとき、原因がクライアント側ではなく、RD Session Host上のアプリ登録にあることが多いのはこのためです。(Microsoft Learn)
さらに、配布されるアプリはユーザーに許可されたものに限られます。ShowInWebAccess や UserGroups の設定次第で、同じRemoteAppでも見えるユーザーと見えないユーザーが分かれます。あるユーザーだけ関連付けが消えたときは、個人端末の故障より先に、公開範囲を疑ったほうが早いケースがあります。(Microsoft Learn)
症状別の当たりを最短でつける
| 症状 | まず疑う場所 |
|---|---|
| ダブルクリックでローカルアプリが開く | フィードか公開関連付け。既定接続URLと IsPublished を先に確認します。(Microsoft Learn) |
| RemoteAppは起動するが、対象ファイルだけ開かない | ドライブリダイレクトかパス到達性。クライアントドライブがサーバー側で見えているかを確認します。(Microsoft Learn) |
| 拡張子候補が空、または一部だけ出ない | RD Session Host上のアプリ登録。RDSはサーバー側の関連付けと扱える拡張子を参照します。(Microsoft Learn) |
| 一部ユーザーだけ起きる | 公開範囲、フィード、証明書信頼。feeds は認可済みアプリを配り、RDSはTLS/証明書にも依存します。(Microsoft Learn) |
ダブルクリックでローカルアプリが開くときの直し方
まずはクライアントのフィードを疑う
RemoteAppの文書関連付けを使うなら、クライアント側に正しい既定接続URLが入っていることが重要です。GPOやMDMで配る場合も、現在のMicrosoftドキュメントでは .../rdweb/Feed/webfeed.aspx 形式が前提です。URLが古い、壊れている、別環境のものに差し替わっていると、関連付けだけが外れたように見えることがあります。(Microsoft Learn)
実務では、Windowsの既定アプリ画面を先に触るより、RemoteApp and Desktop Connections の接続自体を確認し、必要なら再登録したほうが早いことが多いです。特に「アプリのショートカットは残っているのに、拡張子だけローカルアプリに戻った」という症状は、クライアントのフィード情報が古くなっているときによく起きます。これは、文書関連付けが feed ベースで成り立つ設計だからです。(Microsoft Learn)
サーバー側で、その拡張子が本当に公開されているか確認する
RDS側では、Get-RDRemoteApp で公開アプリを、Get-RDFileTypeAssociation で関連付け済み拡張子を確認できます。Set-RDFileTypeAssociation の -IsPublished $True は、ユーザーがその拡張子のファイルをダブルクリックしたときに対応RemoteAppを開けるようにする設定です。逆に -IsPublished $False なら、ローカルアプリで開く挙動になります。(Microsoft Learn)
Import-Module RemoteDesktop
# まず公開アプリを確認
Get-RDRemoteApp -CollectionName "Session Collection"
# 対象拡張子の公開状態を確認
Get-RDFileTypeAssociation `
-CollectionName "Session Collection" `
-AppAlias "YourAppAlias" `
-FileExtension ".xlsx"
# 関連付けを再公開
Set-RDFileTypeAssociation `
-CollectionName "Session Collection" `
-AppAlias "YourAppAlias" `
-FileExtension ".xlsx" `
-IsPublished $Trueここで見落としやすいのが AppAlias です。Alias は公開アプリごとに一意で、既定では実行ファイル名ベースです。Display Name と違うことがあるので、先に Get-RDRemoteApp で確認してから Set-RDFileTypeAssociation を打つのが安全です。(Microsoft Learn)
一部ユーザーだけなら、公開範囲も見る
RemoteAppは、公開されていても ShowInWebAccess が無効だったり、UserGroups から対象ユーザーが外れていたりすると、そのユーザーの feed に出ません。アプリが feed から見えなければ、関連付けもクライアントに入りません。異動やADグループ整理のあとに一部ユーザーだけ壊れるなら、端末より先にここを見てください。(Microsoft Learn)
RemoteAppは起動するのに、対象ファイルだけ開けないときの直し方
ドライブリダイレクトが止まっていないか確認する
RD Session Host は既定でクライアントドライブを自動マップし、セッション内では <driveletter> on <computername> の形で見えます。一方で、ポリシーで drive redirection を禁止すると、そのマップ自体が作られません。結果として、RemoteAppは起動しても、ローカルPC上のファイルだけ開けない、という症状になります。(Microsoft Learn)
確認は簡単です。RemoteApp側で「ファイルを開く」を実行し、ローカルPCのCドライブやDドライブが見えるかを見てください。見えなければ、まず Do not allow drive redirection 系のポリシーやMDM設定を確認します。関連付けが壊れたように見えても、実際は「ファイルを渡す経路」が止まっているだけ、ということは珍しくありません。(Microsoft Learn)
外部接続なら、証明書とGatewayも見る
外部から使っている環境では、RD Gateway の接続フローに証明書信頼が絡みます。Microsoftは、RDSが RD Web、Connection Broker、Gateway の接続を TLS/SSL で保護し、クライアントがサーバー証明書を信頼している必要があると説明しています。RD Gatewayについても、エンドユーザー端末が認識する証明書が必要です。(Microsoft Learn)
ファイル関連付けの不具合に見えても、実際には feed 更新や接続再確立の段階で証明書エラーが起き、結果として関連付け更新が反映されていないことがあります。VPN外利用や新端末だけで起きるなら、証明書配布と信頼チェーンの確認は後回しにしないほうが安全です。(Microsoft Learn)
安定性を優先するなら、ローカル保存前提を減らす
ローカルPCの文書を直接ダブルクリックしてRemoteAppに渡す運用は便利ですが、feed、公開関連付け、drive redirection の3つがそろわないと崩れます。業務的に重要な文書なら、サーバー側から確実に見える共有フォルダや、RemoteApp側からアクセスできる保存場所に寄せたほうが、トラブルは減りやすいです。これはMicrosoftの仕様から見た運用判断です。(Microsoft Learn)
拡張子候補が空、または一部だけ出ないときの考え方
RDSは、RD Session Host上のアプリが現在どの拡張子を扱うか、どのファイル関連付けを持つかをサーバー側から取得します。つまり、RemoteAppの「ファイル関連付け」画面が空だったり、期待した拡張子だけ出なかったりする場合、まず見るべきはクライアントではなく、そのアプリのサーバー側登録状態です。(Microsoft Learn)
特にマルチホスト構成では、アプリの実行ファイルパスがコレクション内のすべての RD Session Host で有効である必要があります。Microsoftの New-RDRemoteApp ドキュメントも、セッションコレクションでは FilePath が全RD Session Hostで有効なローカルパスであることを求めています。バージョン差やインストール先のズレがあると、あるホストでは見えるのに別ホストでは壊れる、という面倒な症状になりやすいです。(Microsoft Learn)
実務でよく詰まるのは、ポータブルアプリ、ユーザー単位インストール、独自ランチャー型のアプリです。RDSが見ているのは「サーバー側の登録情報」なので、サーバーで普通のアプリとしてきれいに登録されないソフトは、RemoteAppのファイル関連付け運用と相性がよくありません。こういうアプリは、無理に関連付けへ載せるより、「アプリを先に開いて共有フォルダから文書を開く」運用に寄せたほうが安定します。(Microsoft Learn)
一部ユーザーだけ壊れるときの見方
一部ユーザーだけで起きるなら、まず「そのユーザーに同じ feed が見えているか」を確認します。RD Web Access の feeds は、ユーザーに許可されたアプリを一覧表示する仕組みですし、UserGroups でも閲覧可否が制御されます。サーバー設定を変えていないつもりでも、権限グループの整理で見え方が変わることがあります。(Microsoft Learn)
次に見るのがクライアントごとの証明書信頼です。RDSはWeb/Broker/GatewayでTLS/SSLを使うため、信頼された証明書が前提です。同じユーザーでも「社給PCでは動くが、新規セットアップ端末では壊れる」なら、関連付けそのものではなく、接続基盤の信頼関係を疑うべきです。(Microsoft Learn)
ログを見るなら、RD Session Hostのイベントビューアーで次を確認します。接続やRemoteApp周りの異常をまとめて追いやすい場所です。(Microsoft Learn)
- Applications and Services Logs > Microsoft > Windows > RemoteApp and Desktop Connections
- Applications and Services Logs > Microsoft > Windows > TerminalServices-LocalSessionManager
- Applications and Services Logs > Microsoft > Windows > TerminalServices-RemoteSessionManager
RemoteApp内で別アプリが開くなら、クライアント側ではなくセッション側を疑う
「関連付けが壊れた」と言っても、症状が“RemoteAppを起動した後”にだけ出ることがあります。たとえば、RemoteApp内でPDFや画像を開いたときだけ別アプリになる場合です。これはクライアントの feed 関連付けではなく、RemoteAppセッション内の既定アプリ挙動を見たほうがよい場面です。(Microsoft Learn)
Microsoftは新しめの環境向けに、RemoteApp向けの enhanced shell experience を用意しており、これが既定のファイル関連付けなどをサポートします。ポリシーを無効化すると legacy shell behavior になるため、互換性対策で無効にしていた環境では、セッション内だけ挙動が古いままになる可能性があります。クライアントの拡張子関連付けと、RemoteApp内の既定アプリは、同じ問題として扱わないのがコツです。(Microsoft Learn)
向く運用と、避けたほうがいい運用
向く運用
- GPOやMDMで既定接続URLを配り、RemoteApp and Desktop Connections の feed を正規ルートにしている運用。文書関連付けが feed 前提で動くため、いちばん整合性を取りやすいです。(Microsoft Learn)
- 文書を共有フォルダなど、サーバー側から見える保存先に置く運用。drive redirection に依存しにくく、ファイルが開かない系の事故を減らせます。(Microsoft Learn)
- コレクション内の全RD Session Hostで、同じアプリを同じパスにそろえている運用。RemoteApp公開や関連付けの揺れが出にくくなります。(Microsoft Learn)
避けたほうがいい運用
- 「ローカルPCの文書をダブルクリックすれば必ずRemoteAppで開く」ことを前提にしつつ、feed 配布や drive redirection をきちんと管理していない運用。便利ですが、依存点が多く壊れやすいです。(Microsoft Learn)
- ポータブルアプリや登録情報が不完全なアプリをRemoteApp化し、ファイル関連付けまで期待する運用。RDSはサーバー上の関連付け情報を参照するため、相性が悪くなりやすいです。(Microsoft Learn)
- 同じコレクション内でアプリのバージョン差やインストール先の差を放置する運用。表面上はつながっても、特定拡張子だけ壊れる温床になります。(Microsoft Learn)
どうしても安定しないときの代替策
RemoteAppのファイル関連付けは便利ですが、すべてのアプリで万能ではありません。安定性を優先するなら、次の代替策が現実的です。
- 関連付けは使わず、RemoteAppを起動してから共有フォルダ上の文書を開く
feed やクライアント既定アプリへの依存を減らせます。(Microsoft Learn) - 問題のアプリだけ別コレクションに分ける
すべてのRD Session Hostで同じ実行パスと登録状態を保ちやすくなります。(Microsoft Learn) - 文書ハンドリングが複雑なアプリは、RemoteAppよりフルデスクトップを検討する
これは仕様上の制約を避けるための運用判断です。RemoteAppで頑張りすぎるより、結果的に保守が楽になることがあります。(Microsoft Learn)
迷ったらこの順で直せば早い
- RD Connection Broker か管理端末で
Get-RDRemoteAppとGet-RDFileTypeAssociationを実行し、対象アプリと拡張子が本当に公開されているか確認する。(Microsoft Learn) - 拡張子候補が出ないなら、RD Session Host上のアプリ登録と、コレクション内すべてのホストでのインストール整合性を確認する。(Microsoft Learn)
- クライアントの既定接続URLが正しいか確認し、怪しければ feed を再登録する。古い資料の
/RDWebと、現行ドキュメントの.../Feed/webfeed.aspxを混同しない。(Microsoft Learn) - RemoteApp内のファイルを開く画面で、クライアントドライブが見えるか確認する。見えなければ drive redirection を疑う。(Microsoft Learn)
- まだ分からなければ、RD Session Host のイベントログを確認する。(Microsoft Learn)
RemoteAppのファイル関連付けが壊れたとき、いちばん大事なのは「Windowsの既定アプリが壊れた」と決めつけないことです。まず Get-RDFileTypeAssociation でサーバー側、次に既定接続URLでクライアント側、最後に drive redirection でファイル経路を見れば、多くのケースは原因をかなり絞れます。運用を安定させたいなら、ローカル保存前提を減らし、RD Session Host間のアプリ差分をなくすところまでセットで見直してください。(Microsoft Learn)
コメント