Windows Server 2019 Standardで3ユーザー以上が同時に業務アプリを使うには、管理用のリモートデスクトップ接続とは別に、リモートデスクトップサービス（RDS）の構成とアクセスライセンスを確認します。「同時2接続までは業務利用も無料」「Windows Server CALを買えばRDSも使える」という理解では、必要なライセンスを見落としてしまいます。
この記事では、社内利用のオンプレミス環境を想定し、必要なCALの数え方、Active Directoryドメインとワークグループの違い、導入後の確認を順に説明します。ホスティング事業者のサービスやAzure Virtual Desktopなどは契約・ライセンス条件が異なるため、ここで示す構成をそのまま当てはめないでください。
まず確認：管理用の2接続と業務用RDSは別の用途
Windows Serverの管理用リモートデスクトップは、通常、同時2セッションまでのサーバー管理に使う機能です。この管理目的の例外を、一般ユーザーが会計ソフトやOfficeなどを使うための「無料の2人枠」と考えてはいけません。業務用のデスクトップやアプリを提供する場合は、1人・2人であっても必要なRDSライセンスを確認します。
管理者アカウントで接続したかどうかだけで、利用目的が管理業務に変わるわけではありません。また「管理用2人＋RDS CAL 1人で計3人分の業務利用」という数え方もしません。MicrosoftのWindows Server 2019 Retail/OEM使用許諾条件（第4条、PDF）では、管理だけを目的とする最大2ユーザーまたはデバイスの例外と、RDS利用に必要な追加CALを区別しています。取得方法に応じた実際の契約条件を確認してください。
Windows Server CALとRDS CALの違い・必要数
Windows Server本体のライセンス、基本アクセス用のWindows Server CAL、RDS機能用のRDS CALは別のものです。社内ユーザーがWindows Server上のRDSを使う一般的な構成では、Windows Server CALに加えてRDS CALが必要です。RDS CALだけを購入しても、基本CALの代わりにはなりません。根拠はMicrosoftのRDSライセンスガイダンスを参照してください。
| 区分 | 確認すること |
|---|---|
| Windows Server本体 | サーバーのコア数、仮想化構成、エディションなどに合ったOSの使用権があるか。 |
| Windows Server CAL | サーバーへアクセスするユーザーまたはデバイスを基本CALでカバーできているか。 |
| RDS CAL | RDSを利用するユーザーまたはデバイスに、対応バージョンの追加CALを割り当てられるか。 |
| 業務アプリのライセンス | Officeや業務ソフトがRDS上の複数ユーザー利用を認め、必要な製品・契約・対応OSの条件を満たすか。 |
CALは同時接続数のプールではない
RDS CALには、特定のユーザーを対象にするPer Userと、特定の端末を対象にするPer Deviceがあります。例えば普段は10人が利用し、同時に接続するのは3人だけでも、Per Userの必要数を3人分に減らすことはできません。同時接続数は性能設計、利用者数・端末数はCALの割り当てとして分けて管理します。
| 利用例 | RDS CALの考え方 |
|---|---|
| ドメイン環境で3人がそれぞれ会社PCとノートPCを使う | Per Userを選ぶなら、対象の3人分。Per Deviceを選ぶなら、実際に接続する全端末を数える。 |
| 8人が交代で4台の共用端末だけを使う | Per Deviceなら4台分を検討できる。自宅PCなど接続端末が増えた場合は、その端末も確認する。 |
| ワークグループで3人が3台から接続する | RDSはPer Deviceで構成し、3台分を確認する。Per Userは選べない。 |
上の表はRDS CALを数える例です。Windows Server CALの保有状況も別途照合してください。Per Userでは技術的に保有数を超える利用が可能な場合がありますが、接続できたことは使用権が足りている証明にはなりません。種類と動作の違いはMicrosoftのRDS CALモデルで確認できます。
HPE ROK版に「5 CALが付属する」とは限らない
HPE ROKという製品名だけでCALの同梱有無・種類・数量は判断できません。見積書、購入した型番、ライセンス証書を確認してください。HPEのWindows Server 2019 QuickSpecsでも、OS製品とUser／Device CALの各製品が区別されています。仮に「5 CAL付き」の販売セットであっても、それがWindows Server CALなのかRDS CALなのかを確認し、両方が含まれるとは推測しないことが重要です。
CALの世代とライセンスサーバーのOSをそろえる
「接続先セッションホストで使えるCAL」と「ライセンスサーバーに登録できるCAL」は別の互換性です。Windows Server 2019のセッションホストは2019以降のRDS CALに対応しますが、2019のライセンスサーバーに2022・2025のRDS CALをそのまま登録できるわけではありません。
| RDS CALのバージョン | 2019セッションホストへのアクセス | そのCALを登録するライセンスサーバー |
|---|---|---|
| 2016 | 不可 | 2019ホスト用のCALとしては使用できない。 |
| 2019 | 可 | Windows Server 2019以降。 |
| 2022 | 可 | Windows Server 2022以降。 |
| 2025 | 可 | Windows Server 2025。 |
購入前にMicrosoftのCAL／ホスト／ライセンスサーバー互換性表を照合してください。新しいCALを旧サーバーで使う場合の製品の提供方法などは、購入先にも確認します。RDS環境の更新では、RDSのサポートされる構成も確認し、役割ごとの互換性を別々に判断してください。
構成を選ぶ：ドメイン標準展開とワークグループを混同しない
ここからのGUI操作はWindows Server 2019のデスクトップエクスペリエンス環境を想定しています。既存サーバーへ役割を追加すると、再起動や接続中の利用者への影響が生じることがあります。バックアップ、保守時間、コンソールなどの復旧手段を用意し、先に検証環境で手順を確認してください。
| 構成 | 導入・管理の考え方 | RDS CAL |
|---|---|---|
| AD DSドメインの標準展開 | ドメイン参加済みのサーバーで、RD Connection Brokerを含む展開を設計する。セッションコレクションなどを管理する。 | Per UserまたはPer Device。 |
| ワークグループの単体構成 | RD Session HostとRD Licensingを用いる、Connection Brokerなしの構成。標準展開と同じ管理機能は使えない。 | Per Deviceのみ。 |
各役割の担当を確認する
- RD Session Host：利用者のデスクトップやアプリを実行します。
- RD Licensing：RDS CALの登録・発行・追跡を行います。
- RD Connection Broker：標準展開で接続先や既存セッションへの再接続を管理します。
- RD Web Access：公開したリソースへのアクセス窓口を提供します。
- RD Gateway：外部から内部のRDSリソースへ接続する経路を提供します。必要な認証・証明書・アクセス制御を設計します。
役割の詳細はMicrosoftのRDS役割一覧を参照してください。人数が3人だからといって全役割が必須になるわけでも、すべてを1台にまとめればよいわけでもありません。
AD DSドメインで標準展開する場合
- AD DS、DNS、参加先ドメイン、管理権限を確認します。RD Session HostやRD Connection Brokerなどのサーバーをドメインに参加させ、名前解決を確認します。
- サーバーマネージャーへ対象サーバーを追加し、「役割と機能の追加」から「リモートデスクトップサービスのインストール」→「標準展開」→「セッションベースのデスクトップ展開」を選びます。
- Connection Broker、Web Access、Session Hostの配置を指定し、再起動が必要な場合は保守時間内に実施します。必要に応じてLicensingやGatewayを追加します。
- ライセンス設定、証明書、セッションコレクション、利用可能なユーザー／グループを構成し、実際の接続経路で確認します。
これはAD DSドメインを前提とする標準展開の流れです。Microsoftのサーバー準備手順とRDS展開手順を併せて確認してください。Connection Brokerをワークグループに追加して、同じ展開を作ろうとしないでください。
ワークグループで小規模に構成する場合
MicrosoftはConnection Brokerを使わない構成を案内しています。ここではRD Session HostとRD Licensingを同じワークグループサーバーに置く例とし、RDSはPer Deviceを選びます。サーバーマネージャーの役割追加ウィザードは使えますが、RDSの展開管理画面を標準展開と同じようには利用できません。
- サーバーマネージャーの「役割と機能の追加」で「役割ベースまたは機能ベースのインストール」を選択します。
- 対象サーバーの「リモートデスクトップサービス」から、RD Session HostとRD Licensing、および必要な管理ツールを追加します。Connection Brokerを一括追加しません。
- 必要な再起動を計画して行い、次節のライセンスサーバーのアクティブ化、RDS CAL登録、ライセンスモード設定へ進みます。
- 接続させるローカルユーザーをRemote Desktop Usersグループに登録し、RDS経由のログオン許可と拒否ポリシーを確認します。接続のためだけに全員をAdministratorsへ追加しないでください。
制約と設定項目はMicrosoftのConnection Brokerなしの構成手順を参照してください。1台構成は障害や再起動の影響も1台に集中します。可用性やユーザー管理の要件が大きい場合は、ドメイン構成を含めて設計し直します。
ライセンスサーバーのアクティブ化とCAL登録
1. ライセンスサーバーをアクティブ化する
RD Licensingの役割・管理ツールを入れたサーバーで「リモートデスクトップライセンスマネージャー」を開き、対象サーバーの「サーバーのアクティブ化」を実行します。自動接続、Webブラウザー、電話のうち環境に合う方法を選び、ウィザードを完了します。これはWindows本体のライセンス認証とは別の操作です。詳細はMicrosoftのライセンスサーバーのアクティブ化手順を参照してください。
2. 購入済みのRDS CALを登録する
続けてライセンスマネージャーの「ライセンスのインストール」を開きます。購入したライセンスプログラムを選び、コードや契約番号、製品バージョン、種類、数量を購入情報と照合して登録します。アクティブ化だけで購入済みCALの登録まで完了するわけではありません。手順はMicrosoftのRDS CALインストール手順に従ってください。
3. セッションホストへライセンス設定を行う
Connection Brokerを含む標準展開では、サーバーマネージャーの「リモートデスクトップサービス」→「概要」→「展開のプロパティの編集」→「RDライセンス」で、ライセンスモードとライセンスサーバーを指定します。Brokerなしの構成では、セッションホストを対象にしたグループポリシー、またはローカルグループポリシーを使います。
ポリシーの場所は「コンピューターの構成」→「管理用テンプレート」→「Windowsコンポーネント」→「リモートデスクトップサービス」→「リモートデスクトップセッションホスト」→「ライセンス」です。表示名は言語により異なるため、以下の英語名も手掛かりにしてください。
- Use the specified Remote Desktop license servers：使用するライセンスサーバー名を指定します。
- Set the Remote Desktop licensing mode：購入したCALに合うモードを指定します。ワークグループではPer Deviceです。
設定元が複数ある場合は適用結果を確認し、意図したサーバー名とモードになっていることを検証します。Microsoftのセッションホストのライセンス設定には両構成の手順が掲載されています。
別々のワークグループサーバーでは認証の追加確認が必要
セッションホストとライセンスサーバーを別々のワークグループサーバーに置く場合、DNSや通信許可だけでは足りないことがあります。CVE-2024-38099へのセキュリティ更新後は、ライセンス要求・照会に匿名ではない資格情報が必要です。Microsoftは、ライセンスサーバー側の専用ユーザーと、セッションホスト側のNETWORK SERVICEが利用できる資格情報の設定を案内しています。
対象となる場合は、Microsoftのワークグループ間認証手順を管理者が確認し、資格情報の保管・更新方法まで設計してください。同一マシンに両役割を置く場合と、両サーバーがADドメイン参加済みの場合は、この追加手順の対象外です。接続できないからといって認証の強制を無効化する方法を、通常の解決策にしないでください。
120日間の猶予は「ライセンス不要の業務利用期間」ではない
RDSには、ライセンスサーバーを必要としない120日間の技術的な猶予期間があります。期限後も接続を継続するには、有効なRDS CALを発行できるライセンス構成が必要です。この動作はMicrosoftのRDS CAL解説に記載されています。
技術的に接続できる期間と、契約上利用を許可された範囲は別です。猶予期間を、製品版の業務利用でCALを購入・割り当てなくてよい根拠にはしないでください。評価版を使う検証も、その評価条件を確認します。期限切れへの対応は必要なライセンスと構成の整備であり、猶予期間のリセットや保護設定の変更ではありません。
接続できないときは、症状を分けて調べる
3人目が接続できない、セッションが切れる、ライセンス警告が出るといった現象は、すべて同じ原因とは限りません。エラー全文、発生時刻、対象ユーザー、接続先、直前の更新・設定変更を記録してから確認します。
| 症状 | 先に確認すること |
|---|---|
| 管理用の2セッションに制限されているように見える | RD Session Hostの導入状態と、本来のセッションホストへ接続しているか。設定を変えて管理用の制限だけを解除しようとしない。 |
| ライセンスサーバーが利用できないと表示される | RD Licensing Diagnoser、ライセンスサービス、指定したサーバー名、名前解決、必要なサーバー間通信。別ワークグループなら認証要件も確認。 |
| CALが使えない・種類が一致しない | アクティブ化とCAL登録、Per User／Per Device、CAL・ホスト・ライセンスサーバーの各バージョン。 |
| 特定ユーザーだけログオンを拒否される | ユーザーの所属グループ、RDS経由のログオン許可／拒否、コレクションの割り当て、アカウント状態。 |
| 同じアカウントで接続すると既存セッションへ戻る | ユーザーごとのセッション制限や再接続設定。別々の利用者はそれぞれのアカウントで確認する。 |
| 時間経過で切断・ログオフされる | セッション時間制限、Gatewayの制限、ネットワーク状態、アプリの終了状況。CAL不足と即断しない。 |
RD Licensing Diagnoserは、サーバーマネージャーの「ツール」から開きます。問題の内容と推奨される対応を読み、Microsoftのライセンスサーバー接続トラブルの確認手順と照合してください。ポート3389へ接続できるだけでは、ホストとライセンスサーバー間の通信が正常とは判断できません。
構成・セッションを読み取りで確認する例
対象サーバー上のWindows PowerShellで、次のコマンドは役割の状態とセッション一覧を表示します。役割を追加したり、再起動やログオフを行ったりするコマンドではありません。管理権限など、実行に必要な権限を持つアカウントで確認してください。
# RDS関連の役割とインストール状態を表示
Get-WindowsFeature -Name RDS* | Select-Object Name, InstallState
# このサーバーのユーザーセッションを表示
query user仕様はGet-WindowsFeatureとquery userを参照してください。セッション一覧だけからCALの過不足は判定できません。購入記録・割り当て管理・ライセンスマネージャーの状態を別に確認します。
ログオフはCALの使い回しではなく、セッション管理
切断は通信を切る操作で、サーバー上にアプリやセッションが残ることがあります。ログオフはセッションを終了する操作です。放置セッションの整理はリソース管理やセキュリティに役立ちますが、ログオフするたびにRDS CALが別人向けの空き枠へ戻る仕組みではありません。CALの割り当て先変更は契約の再割り当て条件に従って判断します。
時間制限を設ける場合は、グループポリシーの「リモートデスクトップセッションホスト」→「セッションの時間制限」で、アイドル時の切断と切断後の終了を区別します。強制ログオフは未保存の作業を失わせる可能性があるため、利用者へ周知してから検証します。関連する制限の関係はMicrosoftのRemoteAppセッションと時間制限の解説も参考になります。
業務利用を始める前のセキュリティ・動作確認
- 接続経路：RD Session HostのRDPポートをインターネットへ直接公開する構成を避け、組織のVPNやRD Gatewayなど管理された経路を検討します。ポート番号の変更だけを安全対策と考えないでください。
- 認証と権限：NLA、利用者ごとの強固なパスワード、最小権限を基本にします。RD GatewayでMFAを使う場合も、対応する認証基盤とポリシーの設定が必要です。
- 証明書と更新：接続先名に合った信頼できる証明書を用意し、OS・Gateway・アプリの更新を保守計画へ組み込みます。
- 業務アプリ：RDS上の複数ユーザー利用への対応、利用許諾、保存先・プロファイル・印刷・周辺機器の動作を確認します。
- 負荷と復旧：想定した複数の一般ユーザーで同時接続し、CPU、メモリ、ディスク、応答時間を確認します。切断後の再接続、計画再起動後の復旧、バックアップからの復元方法も確認します。
認証の基本はMicrosoftのNLAとリモートアクセスの説明、Gatewayの証明書・アクセス制御・MFA連携はRD Gatewayの設計資料を参照してください。ここで挙げた動作確認は導入環境で実施するチェック項目であり、この記事で特定環境の検証結果を保証するものではありません。
Windows Server 2019を今後も使う場合の注意
2026年10月時点でWindows Server 2019はメインストリームサポートを終了しており、延長サポートは2029年1月に終了予定です。既存環境の改修と同時に、移行先OS、CALの世代、アプリの対応状況を計画してください。正確な終了日はMicrosoftのWindows Server 2019ライフサイクルで確認できます。OSの延長サポートが続いていても、サーバー上の業務アプリまで同じ期間サポートされるとは限りません。
まとめ：3ユーザー以上のRDP利用で押さえる順序
- 管理用アクセスと業務用RDSを区別し、OS本体・Windows Server CAL・RDS CAL・アプリのライセンスを確認する。
- 同時接続数だけでCAL数を決めず、利用する人または端末を数える。ワークグループのRDSはPer Deviceで設計する。
- ドメインの標準展開とBrokerなし構成を分け、必要な役割、ライセンスサーバー、モードを設定する。
- 猶予期間や接続成功をライセンス充足の証明にせず、診断・セキュリティ・実利用の確認まで行う。
実際に必要な権利は購入形態と利用方法で変わります。見積書・証書・適用される契約条件を照合し、不明点をMicrosoftまたは販売パートナーへ確認してから運用を始めてください。
コメント