【Windows Server上級 第5回】リモートアクセスの要塞。RDS (Remote Desktop Services) とVDI入門

「VPNが遅い！」というクレームに、まだ帯域増強で対抗しますか？

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
前回は、AD CSによるPKI（証明書基盤）の構築を学びました。
これで、社内の通信をセキュアに暗号化する準備が整いました。

さて、現代のインフラエンジニアにとって避けて通れないのが「テレワーク環境」の整備です。
多くの現場では、とりあえずVPN装置を置いて「社員の自宅から会社のネットワークに繋ぐ」形を取っています。
しかし、Excelファイル一つ開くのに数分かかったり、社員のPCに機密データが残ってしまったりと、VPN運用には限界があります。

本記事では、RDSのアーキテクチャ、VPN不要で安全に接続する「RD Gateway」、アプリ単位で公開する「RemoteApp」、そして仮想デスクトップ「VDI」との違いまで、現場で即戦力となる知識を徹底解説します。

---

第1章：なぜVPNではダメなのか？ 画面転送の優位性

VPNは「ネットワークを延長する」技術です。
自宅のPCが社内LANに直結されるイメージですが、これには致命的な弱点があります。

VPNの弱点：データが移動する

ファイルサーバー上の 100MB のExcelを開くとき、VPN経由だと 100MB のデータが自宅PCまで流れてきます。
保存するときも 100MB 戻っていきます。
これでは回線がいくらあっても足りませんし、自宅PCがウイルス感染していれば社内への入り口になります。

RDSの強み：データは移動しない

RDSでは、ファイルを開く処理はすべて「社内のサーバー上」で行われます。
自宅PCに送られるのは「画面の差分（画像）」だけです。
100MBのファイルを開こうが、1GBのCADデータを操作しようが、通信量は「画面の書き換え分」だけ。
データが社外に出ないため、情報漏洩リスクも極小化されます。

---

第2章：RDSの登場人物（ロール）を理解する

RDSは単一の機能ではなく、複数の役割（ロール）が連携して動くシステムです。
Linuxエンジニア向けに、Webシステムの構成に例えて解説します。

RDSの役割	機能概要	Webシステムでの例え
RD Web Access	ユーザーがブラウザでアプリ一覧を見るポータル画面。	Webサーバー (Nginx/Apache)
RD Gateway	インターネットからのHTTPS(443)通信を受け、内部RDP(3389)に変換する。VPN不要の立役者。	リバースプロキシ / SSH踏み台
RD Connection Broker	ユーザーを適切なサーバーに振り分ける。負荷分散や再接続を管理。	ロードバランサー (HAProxy)
RD Session Host	実際にユーザーがログインし、アプリが動く場所。	APサーバー (Tomcat/PHP-FPM)
RD Licensing	ライセンス(CAL)を管理する。	ライセンスサーバー

---

第3章：RemoteApp。「デスクトップ」を見せない技術

普通のリモートデスクトップ接続だと、サーバーのデスクトップ画面が「ドン！」と全画面表示されますよね。
しかし、ユーザーに使わせたいのは「Excel」や「社内アプリ」だけかもしれません。

RemoteApp (リモートアップ)

特定のアプリケーションのウィンドウだけを切り抜いて、クライアントPCに転送する技術です。
ユーザーから見ると、まるで自分のPC上で動いているかのように見えます（タスクバーにもアイコンが出ます）。
しかし、実体はサーバー上で動いています。

• メリット： ユーザーにサーバーのOS画面（スタートメニュー等）を触らせなくて済む。違和感なく導入できる。
• Linuxでの類似技術： X Window Systemの「X転送 (ssh -X)」に近いです。

---

第4章：実践！RDS環境の構築（標準展開）

それでは実際に構築しましょう。
小規模なら1台に全役割を入れる「クイックスタート」もありますが、本番環境では役割を分ける「標準展開」が基本です。

事前準備

• ドメイン参加済みのサーバーを用意（今回は1台ですべて兼任する構成とします）。
• 固定IPを設定。

構築手順（サーバーマネージャー）

1. 「役割と機能の追加」ウィザードで、「リモートデスクトップサービスのインストール」を選択。
2. 「標準展開」→「セッションベースのデスクトップ展開」を選択。
3. 「RD接続ブローカー」「RD Webアクセス」「RDセッションホスト」に、すべて同じサーバーを指定して次へ。
4. 「再起動が必要」にチェックを入れて展開開始。

コレクションの作成

RDSでは「誰に」「どのアプリを」見せるかを「コレクション」という単位で管理します。

1. サーバーマネージャーの「リモートデスクトップサービス」→「コレクション」→「タスク」→「セッションコレクションの作成」。
2. 名前（例: OfficeApps）を付け、セッションホストサーバーを指定。
3. アクセスを許可するユーザーグループ（例: Domain Users）を指定。
4. ユーザープロファイルディスク（UPD）の設定（後述のFSLogixを使う場合は無効化）。

RemoteAppの公開

作成したコレクションの中で「RemoteApp プログラムの公開」をクリックし、電卓やOfficeなどを選択します。

これで、クライアントPCからブラウザで https:///RDWeb にアクセスすると、公開されたアプリアイコンが並びます。
クリックすれば、ブラウザからではなく専用クライアントが立ち上がり、アプリが起動します。

---

第5章：VDI (Virtual Desktop Infrastructure) との違い

よく「RDS」と「VDI」が混同されますが、決定的な違いは「OSを共有するか、専有するか」です。

RDS (SBC: Server Based Computing)

• 仕組み： 1つのWindows Server OSに、複数のユーザーが同時にログインする。
• メリット： 集約率が高い（1台のサーバーで50人〜100人を収容可能）。コストが安い。
• デメリット： 誰かが重い処理をすると全員が重くなる。アプリによってはマルチユーザー動作に対応していない。

VDI (Virtual Desktop Infrastructure)

• 仕組み： Hyper-V上に、ユーザー1人につき1台の仮想マシン（Windows 10/11）を用意する。
• メリット： 環境が完全に隔離されている。管理者権限を持たせることも可能。互換性が高い。
• デメリット： リソース消費が激しい（OSが人数分動く）。コストが高い。

---

第6章：プロのノウハウ。FSLogixとライセンスの罠

RDS/VDIを実戦投入する際、必ず直面する2つの課題とその解決策です。

1. ユーザープロファイル問題と「FSLogix」

RDSでは、ユーザーがどのサーバーにログインするか分かりません。
「昨日デスクトップに保存したファイルがない！」とならないよう、移動ユーザープロファイルを使うのが昔の定石でした。
しかし、移動プロファイルは「ログイン時にプロファイルを全コピー」するため、ログインが激遅になります。

解決策：FSLogix
Microsoftが買収した技術です。ユーザープロファイルをVHDX（仮想ディスク）ファイルとしてファイルサーバーに保存します。
ログイン時、そのVHDXを「ネットワークマウント」して自分のプロファイルに見せかけます。
コピーが発生しないため、プロファイルが数十GBあってもログインは一瞬です。
現代のRDS/VDI構築では、FSLogixの導入は必須要件です。

2. RDS CAL（ライセンス）の罠

RDSを利用するには、Windows Serverのライセンスとは別に「RDS CAL (Client Access License)」が必要です。
これがないと、猶予期間（120日）を過ぎた瞬間に接続できなくなります。

• 接続デバイス数CAL： 端末単位。不特定多数が使う共有PC向け。
• 接続ユーザー数CAL： ユーザー単位。1人がスマホ、PC、タブレットなど複数端末から使う現代のスタイル向け。Active Directoryが必須。

注意： ライセンスサーバーを構築し、購入したCALをインストールしてアクティベーションすることを忘れないでください。

---

まとめ：データはサーバーに、画面は手元に

お疲れ様でした！
上級編第5回は、RDSとVDIによるリモートアクセス環境の構築について解説しました。

今回の重要ポイント：

• VPNは「データの移動」、RDSは「画面の移動」。セキュリティならRDS。
• RD Gatewayを使えば、HTTPS(443)だけで安全に接続できる。
• RemoteAppを使えば、アプリだけをクライアントに配信できる。
• ユーザープロファイル管理には、移動プロファイルではなくFSLogixを使う。

さて、ここまでサーバー構築の手順を解説してきましたが、GUIでポチポチ設定するのは再現性が低く、ミスの元です。
Linuxエンジニアなら「Ansibleでコード化したい！」と思いますよね。
Windowsには、PowerShellを使った強力な構成管理機能があります。

次回、第6回は「Infrastructure as Code (IaC)。PowerShell DSCによる構成管理の自動化」です。
「あるべき状態（Desired State）」をコードで定義し、Windowsサーバーの設定を自動収束させる、DevOps時代のWindows管理術を解説します。お楽しみに！