RemoteApp/Remote Desktop Connection フィードが表示されない・「RemoteApp and desktop resources aren’t available…」の原因と解決策【Windows Server 運用トラブル対応】

RemoteApp とデスクトップ接続（RADC/フィード）を登録したのにアプリ一覧が空、あるいは「RemoteApp and desktop resources aren’t available for the email address that you entered」と表示される――現場で頻出のこの事象を、RD ゲートウェイ/接続ブローカー/コレクション/証明書/クライアントの5視点で徹底分解。最短で復旧するための切り分けと実運用に耐えるチェックリスト、PowerShell 例まで一気にまとめます。

RemoteApp および Desktop Connection が表示されない問題の全体像

本記事は、オンプレミスの Remote Desktop Services（RDS）環境で、RemoteApp とデスクトップ接続（以下「フィード」）を登録してもクライアントにアプリ一覧が表示されない、または英語のエラーが出るケースを対象にしています。具体的には次のような症状を想定します。

コントロールパネル → RemoteApp and Desktop Connections にフィードを追加しても一覧が空のまま。
メールアドレスによる自動検出を使うと「RemoteApp and desktop resources aren’t available for the email address that you entered」と表示される。
社内 LAN では表示されるが、社外（インターネット越し）では表示されない。
一部ユーザーだけ表示されない／特定のアプリだけ消える。

主な原因（要約）

原因は大きく4系統に分かれます。まずは全体像を把握しましょう。

系統	典型的な誤り	確認ポイント	復旧優先度
RD ゲートウェイのポリシー	CAP/RAP に対象ユーザー/グループが含まれていない、許可するリソースの定義が不正	RD Gateway Manager の Policies、ユーザー/グループ、許可ホスト	高
接続ブローカー / コレクション	RemoteApp が未公開／誤ったコレクション、コレクションが Offline	Server Manager → RDS → Collections の状態、RemoteApp の一覧	高
RD Web / フィード URL / 証明書	URL の打ち間違い、FQDN と証明書 CN/SAN の不一致、自己署名の期限切れ	HTTPS で `.../RDWeb/Feed/webfeed.aspx` に到達できるか、証明書の有効性	中
イベントログに示唆がある未対応エラー	TerminalServices-/RemoteDesktopServices- 系ログに警告/エラーが残存	イベントビューアーの該当チャネル（Operational）	中

まずはここから：5分でできるクイックチェック

クライアントから 正しいフィード URL をブラウザで直接開き、XML（webfeed）を取得できるか確認：
https://rdweb.contoso.com/RDWeb/Feed/webfeed.aspx（FQDN・HTTPS 必須）。
証明書の警告 が出ないか・CN/SAN が URL と一致しているかを確認。
RD Web サーバー上で IIS の バインド(443) と割り当て証明書が有効か確認。
RD Gateway 経由でのみ失敗するなら、TCP 443 / UDP 3391 の開放と CAP/RAP の対象ユーザー/リソースを再点検。
Server Manager の Collections で対象コレクションが Available、RemoteApp が公開済みかチェック。

解決策（詳細）

ゲートウェイの CAP/RAP を確認・是正する

社外からの利用で一覧が空になったり、特定ユーザーだけ失敗する場合は CAP（接続承認ポリシー）/RAP（リソース承認ポリシー）の不備が最短の犯人です。

CAP：どのユーザー/グループが RD ゲートウェイを通過できるか。
RAP：どの宛先ホスト（Session Host/コレクション仮想名）へ到達できるか。

操作手順（RD Gateway Manager）：

Policies → Connection Authorization Policies を開き、該当ユーザー/グループ（例：Domain Users ではなく RDS_Users など）が含まれるか確認。
Resource Authorization Policies で、許可対象が RD Session Host の FQDN あるいは セキュアに定義したコンピューターグループになっているかを確認。曖昧な NetBIOS 名や誤ったワイルドカードは避けます。
RD Gateway が NPS と連携している場合は、NPS のポリシー順序（最上位一致）・条件（NAS ポートタイプ/グループ）を再点検します。

検証コマンド例（クライアント）：

whoami /groups
klist

グループ所属と Kerberos チケットの状態を確認し、CAP の条件に合致するかを見ます。社外のみ失敗する場合は、ファイアウォール/プロキシで 443 と 3391（UDP）に制限がないかを同時に確認します。UDP 3391 が閉じていても基本は TCP 443 にフォールバックしますが、環境によっては初期化遅延やタイムアウトの要因になります。

接続ブローカーとコレクション構成を検証する

フィードが取得できてもアプリが空の場合、多くはコレクションまたは RemoteApp 公開の問題です。

GUI での確認（Server Manager）：

Remote Desktop Services → Overview で各役割（Broker/Web/Gateway/Session Host）が Green であること。
Collections を開き、対象コレクションの Status が Available。セッションホストが Online、ユーザーグループが正しいか。
Publish RemoteApp programs からアプリが公開済みか、誤ったコレクションに公開していないかを確認。

PowerShell での確認（RemoteDesktop モジュール）：

Import-Module RemoteDesktop
# ブローカーを明示（必要に応じて FQDN を指定）
$cb = "rdcb01.contoso.local"
Get-RDSessionCollection -ConnectionBroker $cb
Get-RDSessionHost -CollectionName "Apps" -ConnectionBroker $cb
Get-RDRemoteApp -CollectionName "Apps" -ConnectionBroker $cb | 
  Format-Table Alias, DisplayName, FilePath

ここでコレクションが表示されなかったり RemoteApp が出てこない場合は、公開設定のやり直しや Session Host の参加状態を見直します。HA 構成のブローカーでは、仮想名（DNS レコード）が正しい IP を向いているか（ラウンドロビンの割り当て含む）も確認します。

RD Web / フィード設定を再取得する（URL 再登録）

クライアント側で登録し直すだけで直るケースも少なくありません。URL 手入力での登録が最も確実です。

クライアントで control /name Microsoft.RemoteAppAndDesktopConnections を実行。
既存の接続を削除（Remove）。
Access RemoteApp and desktops から URL を 完全一致の FQDN + HTTPS で入力：
https://rdweb.contoso.com/RDWeb/Feed/webfeed.aspx
資格情報を求められたら、RDS で利用する UPN（user@contoso.com）を使用。

メールアドレスによる自動検出 で失敗する場合は、メールドメインと RDWeb の公開名が一致していない、またはドメイン側のリダイレクト/名前解決が未整備の可能性があります。運用としては「URL 直指定の手順をユーザー配布」が最小の修正で確実です。自動検出を維持したい場合は、メールドメインから最終的に /RDWeb/Feed/webfeed.aspx へ導く名前解決やリダイレクトの設計を整備してください。

証明書チェーンの点検（Web/ゲートウェイ/ブローカーの整合性）

フィードは HTTPS で配布されるため、証明書警告が出るだけでもクライアントが取り込みを拒否することがあります。鍵は「全役割で FQDN と証明書の対応を一致」です。

役割	FQDN の例	証明書の割当先	注意点
RD Web Access (IIS)	`rdweb.contoso.com`	IIS サイトの HTTPS バインド	CN/SAN に FQDN を含める。中間証明書を必ずチェーンにインポート。
RD Gateway	`rdgw.contoso.com`（または RDWeb と同一）	RD Gateway Manager → SSL 証明書	外部公開名と一致させる。NAT 環境での名前解決も要確認。
RD Connection Broker	`rds.contoso.com`（仮想名/HA）	RDS デプロイの「証明書」タブ	SSO/発行/ブローカーの各用途に適切な証明書を割当。

確認コマンド：

# クライアントから 443 の到達性
Test-NetConnection rdweb.contoso.com -Port 443 -InformationLevel Detailed

# フィードの疎通（証明書エラーの有無を確認）

invoke-webrequest [https://rdweb.contoso.com/RDWeb/Feed/webfeed.aspx](https://rdweb.contoso.com/RDWeb/Feed/webfeed.aspx) -UseBasicParsing

「内部は表示されるが外部は不可」のときは、外部公開に使う FQDN と証明書のペアが合っているか（例：内部 FQDN を外部へ見せていないか）を重点確認します。

イベントビューアーで詳細調査（ログのあたり方）

次のチャネルを Applications and Services Logs から確認します。目的は「拒否/到達不能/公開不備」のどれかに切り分けることです。

Microsoft-Windows-TerminalServices-Gateway/Operational：CAP/RAP の判定結果、認証方式、到達ホスト。
Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational：セッションの確立/切断、認証周り。
Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational：プロトコル初期化、暗号/TLS 握手。
Microsoft-Windows-TerminalServices-SessionBroker/Operational：ブローカーの配布とコレクション情報。
IIS-Logging（RD Web サーバー）：/RDWeb/Feed/webfeed.aspx へのアクセスコード（200/401/403/500）。

採取コマンド例（サーバー側）：

# 必要な Operational ログを evtx でエクスポート（例）
wevtutil epl "Microsoft-Windows-TerminalServices-Gateway/Operational" C:\Logs\TSGW.evtx
wevtutil epl "Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational" C:\Logs\RDPCore.evtx

RD Web の IIS ログ（既定では %SystemDrive%\inetpub\logs\LogFiles）で、クライアントのアクセス元 IP とステータスコードを突き合わせると、URL/認証/権限/ゲートウェイ のどこで止まっているかが明確になります。

グループポリシーの更新と関係サービスの再起動

構成を直したのに反映されないときは、GPO とクライアントサービスを明示的に更新します。

クライアント：gpupdate /force の後、RemoteApp and Desktop Connections サービス（サービス名の例：RADCService）を再起動。
powershell -Command "Restart-Service -Name RADCService -Force"
RD Web サーバー：IIS の該当アプリプール（RDWebAccess）をリサイクル、あるいは iisreset /restart。
Broker：RDS 管理サービス（RDMS）周りは、メンテナンス時間帯に慎重に実施。

ネットワーク設計と名前解決の落とし穴

ゲートウェイ配下でのみ発生する表示不具合は、ポートや名前解決の齟齬で説明できることが多いです。以下の表で要件を再確認します。

用途	方向	プロトコル/ポート	備考
RD Web フィード取得	Client → RD Web	TCP 443	証明書検証に失敗するとクライアントが拒否。
ゲートウェイトンネル	Client → RD Gateway	TCP 443 / UDP 3391	UDP は品質向上。閉じていても原則 TCP にフォールバック。
ブローカー/セッション割当	Server 間	TCP 3389 ほか	サーバー間の名前解決とファイアウォールルールを厳格に。

名前解決の原則：「クライアントが参照する FQDN」と「証明書の CN/SAN」と「DNS 解決結果」は三位一体で一致している必要があります。内部/外部で FQDN を分ける場合は、スプリットブレイン DNS の整備と URL 案内の粒度（社内向け/社外向け）を揃えてください。

よくある失敗シナリオと処方箋

社内は表示されるが社外で空になる

原因：CAP/RAP の対象から該当ユーザーが漏れている／外部公開名と証明書が不一致／WAF/SSL 中間装置で TLS ハンドシェイクが失敗。
対処：CAP/RAP にユーザー/グループを追加、ゲートウェイ証明書を外部 FQDN で再割当、SSL 終端装置の TLS バージョン/暗号スイートを RDP/HTTP と整合。

一部ユーザーのみフィードが空

原因：RemoteApp の「ユーザーの割当」が誤り、あるいはコレクションのユーザーグループに未所属。
対処：Publish RemoteApp programs で User Assignment を点検。whoami /groups でグループ所属を確認。

メールアドレス自動検出だけが失敗

原因：メールドメインから RDWeb への解決/リダイレクトルール不足。
対処：運用を URL 直指定へ切替えるか、メールドメインに対して適切な HTTPS ベースのリダイレクト/名前解決を整備。

RemoteApp は出るがフルデスクトップだけ出ない

原因：フルデスクトップを公開していない／コレクションの種類が Session でない。
対処：目的のコレクションに「セッションベースのデスクトップ」を追加し公開。

確実に直すための点検チェックリスト

項目	確認方法	求める状態
フィード URL	ブラウザで `/RDWeb/Feed/webfeed.aspx` にアクセス	HTTP 200、証明書警告なし
証明書	IIS バインド/RD Gateway 設定/ブローカーの「証明書」	CN/SAN=FQDN、一連のチェーンが有効
CAP/RAP	RD Gateway Manager と NPS	対象ユーザー/リソースが正しく登録
コレクション	Server Manager → Collections	Status=Available、RemoteApp 公開済み
ネットワーク	443/3391 の開放、名前解決	外部からも FQDN が正しく解決し疎通可

トラブルシューティングフロー（現場向け）

外形監視：Test-NetConnection rdweb.contoso.com -Port 443、Invoke-WebRequest で webfeed の 200 応答を確認。
ログ照合：IIS ログのステータスと Gateway/RemoteConnectionManager の Operational ログを同時に見る。
コレクション確認：PowerShell で Get-RDSessionCollection と Get-RDRemoteApp を列挙。
ポリシー修正：CAP/RAP を適用、NPS の順序見直し。
GPO/サービス反映：gpupdate /force、RADC サービス/IIS を再起動。

運用のコツ（再発防止）

命名規則の統一：外部公開名・内部名・証明書名をあらかじめ命名規則で固定。
証明書更新の自動化：有効期限アラートと自動割り当てスクリプトを用意（IIS バインド/ゲートウェイ/ブローカーの 3 箇所）。
構成のコード化：RemoteDesktop モジュールで 現在の公開一覧 と 対象グループ を定期出力し、差分を検知。
多拠点の DNS 管理：サイト別に RDS 仮想名の解決先を管理、ラウンドロビン採用時は健全性監視とセットで。
ユーザー通知テンプレート：URL 直指定の登録手順（スクリーンショット付き）を配布し、メール自動検出に依存しない運用へ。

PowerShell スニペット集（現場でそのまま使える）

1) フィード URL 疎通と証明書情報（クライアント）

$url = "https://rdweb.contoso.com/RDWeb/Feed/webfeed.aspx"
try {
  $r = Invoke-WebRequest $url -UseBasicParsing -TimeoutSec 10
  "Status: {0}" -f $r.StatusCode
} catch { 
  "Error: {0}" -f $_.Exception.Message 
}

2) コレクションと RemoteApp の棚卸し（ブローカー）

Import-Module RemoteDesktop
$cb = "rdcb01.contoso.local"
(Get-RDSessionCollection -ConnectionBroker $cb) |
  ForEach-Object {
    $_; Get-RDRemoteApp -CollectionName $_.CollectionName -ConnectionBroker $cb |
      Select-Object CollectionName, DisplayName, Alias, FilePath
  } | Format-Table -AutoSize

3) クライアントのフィード再登録（ユーザー操作の代替手段）
（管理者が案内用に使う想定。実運用では UI 手順の周知が安全です。）

Start-Process control.exe "/name Microsoft.RemoteAppAndDesktopConnections"
# 以降は UI で削除→URL 再登録を実施

ケーススタディ：復旧までの思考過程

ケース A：外部だけ表示されない
IIS で RDWeb の 200 応答を確認、証明書は内部 CA。外部は中間証明書が未配布でチェーン切れ。外向けは公開 CA 証明書に切り替え、ゲートウェイも同一証明書に統一。以後、外部からも即復旧。

ケース B：一部ユーザーだけ空
Collections は Available、RemoteApp も公開済み。IIS ログは 200。Gateway の Operational ログを見ると、当該ユーザーが CAP に未所属。業務グループを CAP/RAP に追加し 5 分で解決。

ケース C：メールアドレス検出でのみ失敗
メールドメインが @subsidiary.co.jp、RDWeb は rdweb.parent.co.jp。自動検出の設計がないため 404。URL 直指定に切替える手順を配布し、併せて将来のために DNS/HTTPS リダイレクトの設計案を提示。

トラブルを未然に防ぐ設定例

グループポリシー（ユーザー構成） → 管理用テンプレート → Windows コンポーネント → RemoteApp and Desktop Connections

既定の接続 URL を指定：フィード URL を固定し、手入力ミスを排除。
ユーザーのサインイン時に自動更新：ログオン直後に同期されるため、公開/撤回の反映遅延を抑制。

証明書運用：Web/Gateway/Broker の各役割ごとに「失効監視・自動割当スクリプト・更新手順書」をセットで管理。IIS バインドと RD Gateway の証明書は別 UI で割り当てることを教育しておくと事故が減ります。

最後に：正しい順番で見るのが最短の復旧策

フィードが空になる問題は、手当たり次第に設定を疑うと迷走します。URL と証明書 → Collections と公開 → CAP/RAP → ログ → GPO とサービス反映の順に当てることで、現場の平均復旧時間は目に見えて短縮します。この記事のチェックリストとコマンドをそのまま運用手順に組み込めば、「再現性のある切り分け」が可能になり、原因の取り違えや設定の二度手間を防げます。

付録：設定・確認手順のサマリ（表）

手順	内容	補足
ゲートウェイの CAP/RAP を確認	RD ゲートウェイマネージャー → ポリシーでユーザー/グループとリソースを許可	対象グループを明示、宛先は FQDN のみ
接続ブローカーのコレクションを検証	Server Manager → RDS → Collections で Availability/公開済みを確認	必要に応じて RemoteApp を再公開
RD Web / フィード設定を再取得	クライアントでフィードを削除し、`https://<FQDN>/RDWeb/Feed/webfeed.aspx` を再登録	メール自動検出に依存しない運用を推奨
証明書チェーンを点検	Web/Gateway/Broker の各証明書が有効で FQDN と一致	中間証明書の取り込みを忘れずに
イベントビューアーで詳細調査	TerminalServices-/RemoteDesktopServices- 系 Operational ログを確認	エラーに応じて KB/設定を補正
GPO 更新とサービス再起動	`gpupdate /force`、RADC/IIS を再起動	反映遅延の解消

付録：切り分けのヒント

外部からのみ失敗：ゲートウェイ/ファイアウォール（TCP 443, UDP 3391）と公開証明書を再点検。
複数サイト構成：DNS ラウンドロビンや Connection Broker の仮想名の解決先がサイトによりズレていないか。
一時的に 3389 を開放：直 RDP が成功するなら、アプリ層ではなくゲートウェイ層の問題と切り分け可能。
ブラウザでの事前確認：まず webfeed を直接開いて 200 が返るか・証明書エラーがないかを素で確認するのが最短。

これらの手順で CAP/RAP とコレクション設定を正しく修正し、クライアントにフィードを再登録すれば、RemoteApp とデスクトップの一覧は通常どおり表示されるようになります。現場では「URL と証明書」「公開とポリシー」「ログで裏付け」の3点セットをルーチン化してください。

RemoteApp/Remote Desktop Connection フィードが表示されない・「RemoteApp and desktop resources aren’t available…」の原因と解決策【Windows Server 運用トラブル対応】

RemoteApp および Desktop Connection が表示されない問題の全体像

主な原因（要約）

まずはここから：5分でできるクイックチェック

解決策（詳細）

ゲートウェイの CAP/RAP を確認・是正する

接続ブローカーとコレクション構成を検証する

RD Web / フィード設定を再取得する（URL 再登録）

証明書チェーンの点検（Web/ゲートウェイ/ブローカーの整合性）

イベントビューアーで詳細調査（ログのあたり方）

グループポリシーの更新と関係サービスの再起動

ネットワーク設計と名前解決の落とし穴

よくある失敗シナリオと処方箋

社内は表示されるが社外で空になる

一部ユーザーのみフィードが空

メールアドレス自動検出だけが失敗

RemoteApp は出るがフルデスクトップだけ出ない

確実に直すための点検チェックリスト

トラブルシューティングフロー（現場向け）

運用のコツ（再発防止）

PowerShell スニペット集（現場でそのまま使える）

ケーススタディ：復旧までの思考過程

トラブルを未然に防ぐ設定例

最後に：正しい順番で見るのが最短の復旧策

付録：設定・確認手順のサマリ（表）

付録：切り分けのヒント

コメント

コメントするコメントをキャンセル

RemoteApp/Remote Desktop Connection フィードが表示されない・「RemoteApp and desktop resources aren’t available…」の原因と解決策【Windows Server 運用トラブル対応】

RemoteApp および Desktop Connection が表示されない問題の全体像

主な原因（要約）

まずはここから：5分でできるクイックチェック

解決策（詳細）

ゲートウェイの CAP/RAP を確認・是正する

接続ブローカーとコレクション構成を検証する

RD Web / フィード設定を再取得する（URL 再登録）

証明書チェーンの点検（Web/ゲートウェイ/ブローカーの整合性）

イベント ビューアーで詳細調査（ログのあたり方）

グループ ポリシーの更新と関係サービスの再起動

ネットワーク設計と名前解決の落とし穴

よくある失敗シナリオと処方箋

社内は表示されるが社外で空になる

一部ユーザーのみフィードが空

メールアドレス自動検出だけが失敗

RemoteApp は出るがフル デスクトップだけ出ない

確実に直すための点検チェックリスト

トラブルシューティング フロー（現場向け）

運用のコツ（再発防止）

PowerShell スニペット集（現場でそのまま使える）

ケーススタディ：復旧までの思考過程

トラブルを未然に防ぐ設定例

最後に：正しい順番で見るのが最短の復旧策

付録：設定・確認手順のサマリ（表）

付録：切り分けのヒント

コメント

コメントする コメントをキャンセル

RemoteApp および Desktop Connection が表示されない問題の全体像

イベントビューアーで詳細調査（ログのあたり方）

グループポリシーの更新と関係サービスの再起動

RemoteApp は出るがフルデスクトップだけ出ない

トラブルシューティングフロー（現場向け）

コメントするコメントをキャンセル