Windows Server 2019 の Server Core に RDS 接続ブローカー（RD Connection Broker）を入れようとしても、役割が一覧に出ない／インストールが失敗することがあります。これは手順不足ではなく、Server Core ではブローカーが提供されないことが原因です。現場で迷わないための確認方法と現実的な対処を整理します。
よくある症状：Server Core に「RDS 接続ブローカー」を追加できない
Windows Server 2019（Server Core）で Remote Desktop Services（RDS）を構成しようとしたとき、次のような“詰まり方”をするケースが多いです。
- Server Core で Install-WindowsFeature を実行しても、RD Connection Broker（接続ブローカー）の追加が失敗する
- GUI の Server Manager から Server Core を管理しても、RD Connection Broker が役割サービスの候補に出てこない
- 「Server Core で利用できる役割・機能の一覧」にブローカーが載っているように見えるため、手順漏れを疑って調査が長引く
ここで重要なのは、これは“環境の不備”や“操作ミス”で起きる例外ではなく、仕様として追加できないために発生するという点です。
結論：Windows Server 2019 の Server Core では RD Connection Broker は利用できない
Windows Server 2019 の Server Core では、「RD Connection Broker（RDS 接続ブローカー）」と「RD Virtualization Host（RD 仮想化ホスト）」は利用できません。つまり、Server Core へ役割を追加しようとして失敗する／選択肢に出てこない挙動は正常です。
Microsoft の “Removed / Deprecated” 系の資料では、Server Core での RDS 構成に関して次のような趣旨が明記されています。
- RD Connection Broker と RD Virtualization Host は、RDSH（RD Session Host）と同居することが多い
- RDSH は Desktop Experience が前提であるため、整合性の観点から ブローカー等も Desktop Experience を要する方向に整理された
- 結果として、Server Core ではこれらの役割は使えない
「一覧にはあるのに…」が起きる理由：Server Core 役割一覧の“脚注”がポイント
混乱の原因として多いのが、Microsoft Learn の「Server Core で利用できる役割・機能」一覧に、Remote Desktop Connection Broker が載っている点です。ただしこの一覧では、ブローカーの行に脚注が付いており、一定のバージョン以降は Server Core で提供されないことが示されています。
さらに別ページ（Server Core に含まれない役割の一覧）では「RDS の一部ロールサービスは含まれる」旨の注記があり、検索経由で断片的に読むと矛盾して見えることがあります。こうしたときは、“役割一覧”だけで判断せず、Removed/Deprecated（削除・非推奨）資料で最終確認するのが確実です。
まず確認：あなたの OS が Server Core であることを確定させる
「Core のつもりで入れた」「いつの間にか Core になっていた」など、インストール媒体や選択肢の取り違えでハマることがあります。まずは Server Core か Desktop Experience かを明確にしましょう。
| 確認方法 | コマンド例 | 見るポイント |
|---|---|---|
| PowerShell | (Get-ComputerInfo).WindowsInstallationType | Server Core / Server などの表示で判断 |
| PowerShell | (Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion").InstallationType | Server Core かどうか |
また、Windows Server 2016 以降では、インストール後に Server Core と Desktop Experience を相互に切り替えることはできません。後から GUI を追加して解決する、というルートは基本的に取れないため、設計段階での判断が重要です。
「追加できない」をコマンドで切り分ける
Server Core では GUI のウィザードが使えない前提の環境も多いため、PowerShell で “入る／入らない” を短時間で確認するのが実務的です。
RDS 系の役割サービスの有無を一覧で見る
Get-WindowsFeature | Where-Object {$_.Name -like "RDS*"} | Format-Table DisplayName, Name, InstallStateここで、RDS-Connection-Broker がそもそも一覧に出ない、あるいは インストール対象として成立しない場合、Server Core 側に「役割が存在しない／提供されていない」可能性が高いです。
ピンポイントで問い合わせる
Get-WindowsFeature -Name RDS-Connection-Broker, RDS-Virtualization, RDS-LicensingServer Core で “入るもの／入らないもの” の境界が見えてきます。特に、RD Licensing は Server Core で運用されるケースもあるため（後述）、ブローカーとライセンスが混同されて調査が長引くことがあります。
Server Core での RDS 関連ロールサービス対応状況
「結局どれが Core に入るのか」を整理すると、判断が一気に速くなります。Windows Server 2019 を前提に、RDS で名前が挙がりやすい要素をまとめます。
| ロールサービス | Server Core | Desktop Experience | 補足 |
|---|---|---|---|
| RD Connection Broker（接続ブローカー） | 不可 | 可 | Server Core では利用不可。ブローカーが必要なら Desktop Experience を用意する |
| RD Virtualization Host（RD 仮想化ホスト） | 不可 | 可 | Server Core では利用不可 |
| RD Session Host（セッション ホスト） | 不可 | 可 | Server Core ではロールサービスとして提供されない |
| RD Web Access（Web アクセス） | 不可 | 可 | Server Core ではロールサービスとして提供されない |
| RD Gateway（ゲートウェイ） | 不可 | 可 | Server Core ではロールサービスとして提供されない |
| RD Licensing（ライセンス） | 可 | 可 | RDS のライセンスサーバー用途として Core に集約したいニーズは多い |
この表から分かる通り、“RDS を本格的に構成したい” という目的自体が Server Core 単体では成立しにくい点が本質です。特にセッションホスト（RDSH）を含む構成を考えている場合、最終的には Desktop Experience が必須になります。
実務的な対応策：迷ったらこの2パターンで整理する
接続ブローカーを使いたい場合：ブローカー用に Desktop Experience を用意する
結論が「Core では入らない」以上、ブローカーが必要なら選択肢はシンプルです。RD Connection Broker を担うサーバーは Desktop Experience にする、これが最短です。
現場でよくある落としどころとしては、次のような分離です。
- RD Connection Broker：Desktop Experience
- RD Web Access / RD Gateway：Desktop Experience（必要な場合）
- RD Licensing：Server Core（可能なら）
- RD Session Host：Desktop Experience（前提）
「全部 GUI で固めるのは避けたい」という場合でも、ブローカーなど“GUI 前提になった役割”だけ Desktop Experience に寄せ、その他を Core に寄せることで、運用コストと攻撃面（パッチ頻度など）のバランスを取りやすくなります。
Server Core を軸にしたい場合：ブローカー必須の設計を避け、役割を割り切る
「どうしても Server Core を主役にしたい」という場合は、RDS の“役割”を Server Core に期待しすぎない設計が重要です。具体的には次の方向性になります。
- RDS の中核（ブローカー、セッションホスト、Web、ゲートウェイ）を Core に載せる発想を捨てる
- Server Core は、AD/DNS/DHCP/ファイル、Hyper-V など、Core と相性が良い役割に寄せる
- RDS は Desktop Experience または別のリモートデスクトップ基盤（クラウド含む）で設計する
「単体のサーバーにリモートで入れればよい」という要件であれば、RDS の大規模構成ではなく、通常の管理用 RDP（いわゆる管理目的の接続）で済むケースもあります。ただし、複数ユーザーが業務利用する目的でのリモートデスクトップ運用は、役割やライセンス要件が絡むため、設計段階で整理してください。
「GUI サーバーの Server Manager から Core を追加して入れれば良い」はなぜ効かないのか
よくあるアドバイスとして「別の GUI サーバーの Server Manager から Core を管理対象に追加して、そこから役割を入れる」という方法があります。確かに Server Core の管理手段としては一般的ですが、今回のケースでは問題の本質が違います。
そもそも Server Core 側に RD Connection Broker の役割サービスが存在しないため、遠隔の Server Manager から操作しても “インストール対象に出ない／入らない” という挙動になります。Microsoft Q&A でも、まさにこの状況（RD Licensing だけが選べる等）で迷っている例が見られます。
高可用性（HA）やコレクションを考えるほど、ブローカーが重要になる
RDS を複数台構成にしたり、負荷分散やセッション再接続（同じユーザーを同じセッションへ戻す）を安定させたりする場合、RD Connection Broker の存在は中核になります。
たとえば接続ブローカーを高可用性にする場合、複数のブローカーと、共有データベース（SQL など）やロードバランサー（あるいは DNS ラウンドロビン）を使う設計が前提になります。
つまり「将来的に台数を増やすかもしれない」「冗長化したい」という見通しがあるなら、最初から Desktop Experience を前提にブローカーを置くほうが、後戻りが少なくなります。
現場での判断を速くするチェックリスト
「設計と構築の途中で気づいて手戻り」が一番痛いので、着手前に次を確認すると安全です。
| チェック項目 | OK の目安 | NG の目安（今回の落とし穴） |
|---|---|---|
| インストール形態 | RDS を組むなら Desktop Experience を含めた計画になっている | Server Core だけでブローカーやセッションホストを組もうとしている |
| 要件（単体/複数台） | 単体で済むなら“何が不要か”が明確 | 負荷分散やコレクション、HA をやりたいのにブローカーを Core に入れようとしている |
| 情報源の確認 | 役割一覧＋Removed/Deprecated を両方見て判断 | 役割一覧の一部だけを読んで「あるはず」と思い込む |
| 手戻り対策 | Core/GUI は後から切替不可＝必要なら作り直す前提で計画 | 「あとで GUI を足す」前提で進める |
よくある質問
RD Licensing（RDS ライセンス）は Server Core に入れられる？
RD Licensing は Server Core の役割一覧にも含まれており、RDS のライセンスサーバーとして Core を使う設計は選択肢になります。ブローカーと混同しやすいので、役割名（RDS-Licensing）で切り分けて考えるのがポイントです。
App Compatibility FOD を入れれば、RD Connection Broker も入る？
アプリ互換性のための機能追加（FOD）は、あくまで Server Core 上で一部のアプリ実行や管理ツールの互換性を補う仕組みです。RD Connection Broker 自体が Server Core で提供されない以上、FOD で “ブローカーが復活する” という期待は持たないほうが安全です。
どうしても Server Core のまま進めたい。最小の妥協案は？
「RDS を本格的に組む」のではなく、「Core を中心にサーバー運用する」方針へ寄せるのが現実的です。RDS が必須なら、ブローカーやセッションホストなど要所だけ Desktop Experience を採用し、その他の基盤サーバーを Server Core へ寄せる構成が落としどころになりやすいです。
コメント