RDSで「ライセンスサーバーが見つからない」と出たら、最初に疑うべきはライセンスサーバー本体の故障ではありません。先に見るべきなのは、RD Session Host 側のライセンスモード設定、指定先ライセンスサーバー名、GPO の上書き、RDS CAL の種類・バージョン、そしてワークグループや信頼関係の条件です。Microsoft のトラブルシュートでも、未設定・通信不能・互換性不一致・権限や証明書の問題が主な確認項目として挙がっています。 (Microsoft Learn)
この記事では、RDSでライセンスサーバーが見つからないときに、どこから確認すれば最短で復旧できるかを、現場向けの順番で整理します。設定ミス、更新の影響、ワークグループ特有の落とし穴、最後の復旧手順まで、WordPressにそのまま載せられる形でまとめました。
RDSでライセンスサーバーが見つからないとき、最初に見るべき5項目
| 優先 | 確認項目 | 典型的なNG例 | 起きやすい症状 |
|---|---|---|---|
| 1 | RD Session Host のライセンス設定 | ライセンスモード未設定、指定先サーバー名が空 | 「ライセンスモードが構成されていません」 |
| 2 | GPOの上書き | GUIで直したのに、実際はGPOが別設定を配布 | 修正しても再発する |
| 3 | CALの種類・互換性 | WorkgroupでPer User、2025ホストに2022 CAL | サーバーは見えるのに発行できない |
| 4 | 通信・サービス・権限 | RD Licensing サービス停止、RPC/SMB遮断、権限不足 | 「利用できません」「セキュリティ エラー」 |
| 5 | ドメイン/ワークグループ条件 | 信頼関係なし、更新後の認証強化未対応 | 更改後・移設後・更新後に急に失敗 |
この並びは、Microsoft が案内している確認手順を、実際に復旧しやすい順に並べ替えたものです。設定確認の起点は Server Manager / GPO / レジストリ / RD Licensing Diagnoser / イベントログ の5つです。 (Microsoft Learn)
「ライセンスサーバーが見つからない」が意味していること
表示上は「見つからない」でも、内部的に起きていることは1つではありません。Microsoft の整理では、ライセンスサーバー未指定、ライセンスモード未設定、RD Session Host とライセンスサーバーの通信不能、CAL の不整合、証明書や権限の問題が代表的です。新規の RD Session Host には 120 日の猶予期間があり、その間は警告だけで接続できることがありますが、猶予期間を過ぎると接続拒否や警告の常時表示につながります。 (Microsoft Learn)
もう1つ重要なのは、警告が出た＝必ず設定ミスとは限らないことです。Microsoft は、Per User でローカルアカウントを使っている場合や、管理セッションで接続している場合には、設定が正しくても同様のポップアップが出ることがあると案内しています。まずは、一般ユーザーの通常接続で再現しているのか、管理用途の接続だけなのかを切り分けてください。 (Microsoft Learn)
「セッションは60分以内に切断されます」というメッセージも、RDS ライセンス問題の代表的な症状です。公式ドキュメントでは、これは RD Licensing サーバー自体の問題、または RD Session Host との通信を妨げる問題を示すとされ、Windows Server 2016/2019 では soft enforcement の挙動が関係します。なお、soft enforcement は Windows Server 2022 では削除されています。 (Microsoft Learn)
原因ごとの見方と対処
RD Session Host 側で、ライセンスサーバー名とライセンスモードが設定されていない
まず確認したいのは、RD Session Host が「どのライセンスサーバーを使うか」と「Per User / Per Device のどちらで動くか」を正しく持っているかです。RD Connection Broker を含む構成なら、Server Manager > Remote Desktop Services > Overview > Edit Deployment Properties > RD Licensing を見ます。RD Session Host と RD Licensing だけの構成なら、コンピューターの構成 > 管理用テンプレート > Windows コンポーネント > Remote Desktop Services > Remote Desktop Session Host > Licensing で、Use the specified Remote Desktop license servers と Set the Remote Desktop licensing mode を確認します。複数のライセンスサーバーを使う場合は、サーバー名をカンマ区切りで指定できます。 (Microsoft Learn)
設定の場所を見誤ると、直したつもりでも直っていません。Microsoft は、Server Manager で設定した値とGPOで設定した値が、別のレジストリに保存されることを示しています。Server Manager 側は HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\Licensing Core と ...\Services\TermService\Parameters\LicenseServers\SpecifiedLicenseServers、GPO 側は HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services を見ます。サーバー更改や移設の後は、これらの場所に旧ライセンスサーバー名が残っていないかを確認するのが早道です。 (Microsoft Learn)
GPOが Server Manager の設定を上書きしている
RDS のライセンス設定でいちばんハマりやすいのが、GUIで修正したのに、実際には GPO が別設定を押し戻しているケースです。Microsoft は、Group Policy で設定した内容は Server Manager の設定より優先されると明記しています。つまり、Broker 画面で直しても、対象 RD Session Host に GPO が適用されていれば、そちらが勝ちます。 (Microsoft Learn)
この場合は、ローカル画面の見た目よりも、何の GPO が実際に適用されているかを優先して確認します。Microsoft は gpresult /H を使った確認を案内しています。サーバー単体の設定だけを見て「合っているはず」と判断すると、直らない原因になります。 (Microsoft Learn)
gpresult /H C:\temp\rds-gpo.htmlこのレポートで、RD Session Host に対してどの GPO が有効になっているかを確認すると、Server Manager と食い違う原因を見つけやすくなります。 (Microsoft Learn)
CALの種類とバージョンが合っていない
ライセンスサーバーが見えていても、CAL の種類やバージョンが合っていなければ、結果として「使えない」「見つからない」に近い状態になります。特にワークグループ環境では、Per User は使えず、Per Device のみです。Per User の追跡やレポートもワークグループではサポートされません。 (Microsoft Learn)
| 環境 | 選べるCAL | 実務での判断基準 |
|---|---|---|
| ドメイン参加 | Per User / Per Device | 1人が複数端末から使うなら Per User、共有端末中心なら Per Device が選びやすい |
| ワークグループ | Per Device のみ | Per User は不可。まずここがズレていないか確認する |
この表は、Microsoft の CAL モデル説明と、ワークグループ制約を前提に整理したものです。Per User は「便利そうだから」で選ぶと、ワークグループではその時点で不整合になります。 (Microsoft Learn)
さらに、CAL のバージョン互換性も見落としやすいポイントです。Session Host に対して使える CAL は次の関係になります。 (Microsoft Learn)
| Session Host のバージョン | 利用できる RDS CAL |
|---|---|
| Windows Server 2016 | 2016 / 2019 / 2022 / 2025 |
| Windows Server 2019 | 2019 / 2022 / 2025 |
| Windows Server 2022 | 2022 / 2025 |
| Windows Server 2025 | 2025 |
また、CAL をインストールするライセンスサーバー側の Windows Server バージョンも重要です。たとえば 2025 CAL は 2025 のライセンスサーバーでのみ扱え、2022 のライセンスサーバーには入れられません。逆に、古い CAL を新しいライセンスサーバーで扱うことは可能です。 (Microsoft Learn)
加えて、Per User は接続そのものが厳密に強制されるモデルではなく、管理者側のライセンス管理責任が重い点にも注意が必要です。Per User で「発行済みが見えにくい」こと自体は、すぐ故障を意味しません。まずは種類・バージョン・環境の組み合わせが正しいかで判断してください。 (Microsoft Learn)
ライセンスサーバー自体はあるが、サービス・ポート・権限で失敗している
ライセンスサーバー名が正しくても、役割が未導入、サーバー未アクティブ化、CAL 未インストール、RD Licensing サービス停止のどれかなら、実運用では使えません。Microsoft は、RD Licensing Manager でライセンスサーバーに緑のチェックが付いていること、総数と残数が正しく見えていること、そしてサーバーがActivate Server済みであることを確認するよう案内しています。 (Microsoft Learn)
通信面では、RDS ライセンスには少なくとも TCP 135（RPC Endpoint Mapper）、TCP 445（SMB）、さらに 動的 RPC ポートが関わります。ライセンスサーバーのアクティブ化では、Microsoft Clearinghouse への TCP 443 も使います。ファイアウォールで 135 だけ開いていても、動的 RPC が塞がっていれば失敗します。 (Microsoft Learn)
切り分けでは、まず最低限の到達性を見ます。
Test-NetConnection <LicenseServerName> -Port 135
Test-NetConnection <LicenseServerName> -Port 445この2つで入口の疎通は見られますが、これで成功しても動的 RPC が閉じていれば通信は成立しません。135 と 445 が通ることは必要条件であって十分条件ではない、と覚えておくと判断を誤りにくくなります。 (Microsoft Learn)
権限面では、Access this computer from the network のユーザー権利割り当ても確認します。Microsoft は、Everyone が付いていない場合、Authenticated Users / Domain Computers / Session Host のコンピューターアカウントにこの権利を与えるよう案内しています。さらに、ライセンスサーバー側の動作確認には、Application and Services Logs\Windows\TerminalServices-Licensing\Operational のイベントログが有効です。 (Microsoft Learn)
ドメイン・ワークグループ・信頼関係の条件を満たしていない
RD Licensing は、どこに置いても自由に使えるわけではありません。Microsoft の推奨構成では、同じワークグループ、同じドメイン、双方向信頼のあるドメイン/フォレストのいずれかが前提です。信頼関係のない別フォレストや、条件を満たさない跨ぎ方では、ライセンス発行が想定どおり動かない原因になります。 (Microsoft Learn)
ワークグループ環境では、Per Device のみで、RD Session Host と RD Licensing を同一サーバーに置くことも可能です。別サーバーに分ける場合は、RD Session Host からそのライセンスサーバーへ到達できることが前提になります。逆に、ドメイン環境では Per User / Per Device の両方を使えますが、ライセンスサーバーのコンピューターアカウントを Terminal Server License Servers グループに入れる必要があります。ライセンスサーバーがドメインコントローラー上にある場合は、Network Service も同グループに必要です。 (Microsoft Learn)
クロスドメインやクロスフォレストで使うなら、双方向信頼が必要で、Per User CAL を他ドメインのユーザーに発行する場合は、ライセンスサーバーが相手側ドメインの Terminal Server License Servers にも入っている必要があります。さらに Microsoft は、各ドメイン/フォレストの RD Session Host 全台にライセンスサーバーを構成することを案内しています。 (Microsoft Learn)
更新後の認証強化や、証明書の問題が影響している
最近の運用で見落としやすいのが、ワークグループ環境でのセキュリティ更新後の挙動変化です。Microsoft は、CVE-2024-38099 向け更新後、RD Licensing サーバーが 非匿名の資格情報を要求するようになり、RD Session Host 上の NT AUTHORITY\NETWORK SERVICE が資格情報にアクセスできないと、ライセンス要求や照会に失敗すると案内しています。特に「更新後から急に見つからない」なら、ここを疑う価値があります。 (Microsoft Learn)
対処は、ライセンスサーバー側に専用ユーザーを作り、各 RD Session Host で NETWORK SERVICE としてその資格情報を登録する方法です。Microsoft の案内どおりなら、次の流れになります。必要なら一時的に mstsc.exe /admin で管理接続を取り、作業します。 (Microsoft Learn)
psexec.exe -I -u "NT AUTHORITY\NETWORK SERVICE" cmd.exe
cmdkey /add:<NAME-OF-THE-LICENSING-SERVER> /user:<NAME-OF-THE-LICENSING-SERVER>\<USERNAME> /passこの方法で、RD Session Host はワークグループ内の RD Licensing サーバーに接続できるようになります。 (Microsoft Learn)
どうしても暫定回避が必要な場合、Microsoft はライセンスサーバー側の HKLM\SYSTEM\CurrentControlSet\Services\TermServLicensing\Parameters に DisableWorkgroupAuthEnforcement=1 を設定する方法も示しています。ただし、推奨ではなく、セキュリティリスクが上がり、将来の Windows では無効化される可能性があると明記されています。恒久対策としては使わないほうが安全です。 (Microsoft Learn)
設定が正しいのに、Access was denied because of a security error や、RD Licensing Diagnoser 上で X.224 protocol stream 関連のメッセージが出る場合は、証明書レジストリの破損も候補です。Microsoft は、各 RD Session Host で HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM 配下の Certificate、X509 Certificate、X509 Certificate ID、X509 Certificate2 をバックアップ後に削除し、再起動してライセンスサーバーを再アクティブ化する手順を案内しています。これは最後の手段として扱うべきです。 (Microsoft Learn)
15分で進める復旧手順
まず RD Session Host 側の状態を数値で確認する
「見た目では合っている」をやめて、まずは RD Session Host が何を見ているかを取得します。Microsoft は、猶予期間、指定ライセンスサーバー、現在のライセンスモードを PowerShell で確認する方法を案内しています。 LicensingType は 2 が Per Device、4 が Per User です。 (Microsoft Learn)
$obj = gwmi -namespace "Root/CIMV2/TerminalServices" Win32_TerminalServiceSetting
$obj.GetGracePeriodDays()
$obj.GetSpecifiedLicenseServerList()
$obj.LicensingTypeここでサーバー名が空なら未設定、旧サーバー名が返るなら設定の残骸、LicensingType が意図と違えばモード不一致です。 (Microsoft Learn)
設定は「正しい場所」で直す
Broker ありなら Edit Deployment Properties > RD Licensing、Broker なしなら GPO の Remote Desktop Session Host > Licensing を直します。GUIで直すべき環境なのか、GPOで直すべき環境なのかを先に決めてください。GPO が優先される環境で Server Manager だけ直しても、戻されます。 (Microsoft Learn)
ライセンスサーバー側で、役割・アクティブ化・CALを確認する
ライセンスサーバーには Remote Desktop Licensing 役割が入り、Activate Server 済みで、必要な RDS CAL が入っている必要があります。RD Licensing Manager で緑のチェックがあるか、残数が正しいかを確認してください。ここが崩れていると、RD Session Host 側をいくら直しても復旧しません。 (Microsoft Learn)
GPOの適用状況を確認する
修正しても再発するなら、gpresult /H で適用済み GPO を確認します。特に、ドメイン GPO・ローカル GPO・Server Manager 設定の三重管理になっていると、意図しない上書きが起きやすくなります。設定値そのものより、どの設定ソースが勝っているかを見るのがポイントです。 (Microsoft Learn)
通信・権限・イベントログを確認する
TCP 135/445、動的 RPC、必要なら 443 の疎通を確認し、Access this computer from the network の権利割り当てを見ます。そのうえで、ライセンスサーバーの TerminalServices-Licensing\Operational ログを見れば、停止・拒否・到達不能の切り分けがしやすくなります。RD Licensing Diagnoser は Server Manager > Tools > Terminal Services > RD Licensing Diagnoser から開けます。 (Microsoft Learn)
ワークグループなら、更新の影響を必ず疑う
ワークグループ環境で、設定も通信も合っているのに急に失敗し始めたなら、CVE-2024-38099 対応後の認証強化を疑います。NETWORK SERVICE に資格情報を持たせる対策を優先し、DisableWorkgroupAuthEnforcement は暫定回避に限定してください。どうしても security error 系が消えない場合だけ、最後に X509 証明書レジストリの再生成を検討します。 (Microsoft Learn)
再発防止のポイント
ライセンス周りは、「設定ミス」よりも設定の置き場所が分散していることで再発します。再発防止を重視するなら、Broker 管理なら Broker、GPO 管理なら GPO と、管理経路を1本に決めるのが効果的です。更改時は、Server Manager・GPO・レジストリの3か所で旧サーバー名が残っていないかを必ず確認してください。 (Microsoft Learn)
ワークグループ環境では、Per User を使わないことが前提です。さらに、複数ライセンスサーバーを使うこと自体は可能ですが、Microsoft はワークグループでの複数ライセンスサーバー構成を推奨しておらず、将来の Windows でサポートが外れる可能性にも触れています。小規模ワークグループなら、構成はできるだけ単純にしたほうが安全です。 (Microsoft Learn)
ドメイン跨ぎで使うなら、双方向信頼、必要なポート、Terminal Server License Servers グループ参加をまとめて満たして初めて安定します。RDS は「見つかる/見つからない」の一段階ではなく、見える・認証できる・発行できるの3段階で成立すると考えると、設計で失敗しにくくなります。 (Microsoft Learn)
まとめ
RDSでライセンスサーバーが見つからないときは、ライセンスサーバー本体より、RD Session Host が何を参照しているかを先に確認するのが最短です。まずは GetSpecifiedLicenseServerList() と LicensingType を取得し、次に Broker/GPO のどちらが設定元かを確認し、その後で CAL の種類・互換性・通信・権限を見てください。ワークグループなら、更新後の認証強化まで含めて確認するのが重要です。 (Microsoft Learn)
今すぐ動くなら、手順はこの順で十分です。RD Session Host の実際の設定確認 → GPO/Broker の修正 → ライセンスサーバーの有効化と CAL 確認。ここまでで直らなければ、通信・権限・ワークグループ認証・X509 証明書の順で絞ると、無駄なく復旧できます。 (Microsoft Learn)
コメント