Windows Server 2019でリモートデスクトップを利用していると、まれに「Please wait for the Remote Desktop configuration」というメッセージが長時間表示されたまま、ログインが進まなくなるケースがあります。一度こうした状況に陥ると、なかなか原因が特定できず、再起動などの対処を試みても改善しないことがあり、システム管理者にとって頭の痛い問題と言えるでしょう。この記事では、User Profile Disks（UPD）の存在やネットワーク、イベントログの確認方法といった多角的な視点から、その原因と解決策を徹底的に掘り下げて解説します。ぜひ本記事を参考に、トラブルの根本原因を突き止めてスムーズにログインを実現してください。
「Please wait for the Remote Desktop configuration」とは
「Please wait for the Remote Desktop configuration」のメッセージが表示されるのは、主にリモートデスクトップ接続時にユーザープロファイルの読み込みやサービスの初期化が正常に完了しない状況を示しています。Windows Server 2019ではリモート接続を管理するために複数のサービスや設定が連動しており、なかでもUser Profile Disks（UPD）やネットワークの状態、Remote Desktop Services（RDS）構成の問題が複合的に絡むことが原因となりやすいです。この段階でログインプロセスが先に進まない場合、まずはUPDの設定やストレージ・ネットワークのトラブルを疑ってみるとよいでしょう。
よくあるケース
- UPDの保存先共有フォルダにアクセスできない
ネットワークの不具合や共有フォルダの権限設定の問題、あるいはサーバー側がオフラインになっているなど、ディスクにアクセスできないケース。 - リモート接続数の上限やセッション管理の不備
同時接続数の制限やセッションが正常に切断されずに残っていると、新たなログイン時にセッションが確立できず滞留することがあります。 - サービスやOS自体の不調
Windows Updateの影響や、RDS関連のサービスが一部異常停止・フリーズしている可能性があるケース。
ポイントとなる設定やサービス
- Remote Desktop Services（TermService）
リモート接続のベースとなるサービスで、これが異常停止または起動不良だと、ログオンプロセスの初期段階で問題が発生しやすくなります。 - User Profile Service
ユーザープロファイルの読み込みを管理するサービスで、ユーザーごとのレジストリやデスクトップ、ドキュメントなどを確立する役割を担います。 - User Profile Disks（UPD）関連の機能
RDSのセッションコレクションにおいてユーザープロファイルを共有ドライブ上に格納する仕組み。ネットワークドライブが見つからない場合やディスクにアクセスできないと、ログインがいつまでも完了しません。
UPD（User Profile Disks）の確認手順
User Profile Disksを使っている環境では、まずその保存先（通常は共有フォルダやファイルサーバー上の特定ディレクトリ）に対してアクセスが可能かどうかを確認しましょう。UPDが正しくマウントされない場合、ユーザープロファイルの読み込みプロセスが進まず、長い待機状態に陥ります。
UPD保存先の基本的な確認項目
- ネットワークの到達性
- クライアントPCまたは別のサーバーから、UPD保存先となる共有フォルダにアクセスできるかをテスト。
- 「\サーバー名\共有フォルダ」の形式でエクスプローラーやコマンドプロンプトからアクセスし、エラーが出ないかを確認。
- 権限設定
- 共有フォルダのNTFS権限と共有権限が正しく構成されているかをチェック。
- Administratorやドメインユーザーが必要な読み書き権限を持っているかどうかを確認することで、UPDの読み込み失敗を防ぐ。
- ディスク容量
- 共有フォルダがあるストレージの空き容量が十分にあるかどうか。
- ディスクが逼迫している場合、UPDファイルのマウントが行えずタイムアウトを引き起こす可能性があります。
簡単なテスト方法の例
下記はPowerShellで共有フォルダにファイルを作成し、読み書きできるかをテストする例です。
# テスト用フォルダとファイルを作成
$testFilePath = "\\ファイルサーバー名\UPDShare\testfile.txt"
# ファイル作成
"TestWrite" | Out-File $testFilePath
# ファイル内容を読み込み
Get-Content $testFilePathこのスクリプトを実行してエラーが出ず、かつGet-Contentで”TestWrite”の内容が取得できれば、読み書き権限は概ね正常と考えられます。
サーバー再起動とサービス状況のチェック
ネットワークやストレージが問題なさそうな場合でも、Windows Server自体がリソース不足やサービスエラーによって正常に機能していないケースもあります。一時的な不具合の場合はサーバーを再起動してみるだけでも改善することがありますが、再起動のタイミングによってはサービスの起動順序や依存関係でさらに問題が起きる可能性もあるため、注意深く手順を踏むことが重要です。
再起動前に確認したいこと
- イベントビューアーのエラー有無
特にApplicationやSystem、Microsoft-Windows-RemoteDesktopServices-RdpCoreTS関連のログを参照し、深刻度の高いエラーが出ていないかチェックしましょう。 - リソース使用率
タスクマネージャーやパフォーマンスモニターでCPU、メモリ、ディスクI/O、ネットワーク帯域などが異常な使用率を示していないか。
もし高負荷が原因でサービスがハングしている場合、根本的な対策として負荷分散やスケーリングを検討する必要があります。 - 依存サービスの起動状態
Remote Desktop Servicesは、複数のサービスに依存する場合があります（Remote Desktop Services UserMode Port Redirectorなど）。これらがスタートアップ時に正しく起動しているかを念入りに確認してください。
サービスの起動確認コマンド
Get-Service -Name TermService, UmRdpServiceTermService（Remote Desktop Services）UmRdpService（Remote Desktop Services UserMode Port Redirector）
これらのサービス状態がRunningであれば、基本的にリモートデスクトップ接続に必要なサービスは動作している可能性が高いです。ただし、依存サービスが他にもある場合はそちらもあわせて確認しましょう。
Event Viewer（イベントビューアー）での詳細調査
Windows Server上のトラブルシュートを行う際、最も頼りになるのがイベントビューアーのログです。「Please wait for the Remote Desktop configuration」の問題が発生した時間帯を絞り込み、何かしらのエラーや警告が記録されていないかを集中的にチェックしてください。
注目すべきログの種類
- Applicationログ
- User Profile Serviceやその他のアプリケーションレイヤーのエラーがここに出力されることがあります。
- Systemログ
- ネットワークドライバやディスク関連ドライバ、OS関連の重要なエラーはここに記録されやすいです。
- Remote Desktop Servicesログ
Applications and Services Logs→Microsoft→Windows→RemoteDesktopServices-...
ここにRDSに特化したエラーや警告が細かく出る場合があるため、問題発生時刻に合わせて要チェックです。
ログ内容が示す具体例
| イベントID | ソース | 可能性のある原因 |
|---|---|---|
| 1000～1111 | Application Error / User Profile Service | ユーザープロファイルの読み込み失敗、UPDのマウントに失敗している場合など |
| 20499 | Remote Desktop Services | RDS構成関連の警告・エラー |
| 7001, 7009 | Service Control Manager | 依存サービスの起動失敗やタイムアウト |
| 55 | Ntfs | ディスク上のファイルシステムエラーが原因で読み込みに失敗 |
このようなイベントが問題発生前後に集中的に出現していた場合は、該当するサービスや設定を重点的に見直す必要があります。
ネットワークとストレージ状態の確認
UPDやファイル共有が絡んでいるケースでは、ネットワークやストレージの状態は最優先で確認すべき項目です。特に、以下のようなポイントを洗い出すことで、問題切り分けを効率化できます。
ネットワーク状態の診断
- Pingテストおよび名前解決
ping ファイルサーバー名を実行し、応答があるかどうかで基本的な疎通を確認。同時にnslookup ファイルサーバー名でDNS参照が正しく動作しているかをチェックします。 - 経路制御（ルーティング）の問題
ルータやファイアウォールの設定変更で一部のポートやプロトコルがブロックされていないか確認が必要です。RDP（TCP/3389）だけでなく、SMB（TCP/445）やRPCなどのポートが通るかどうかもチェックしてみましょう。 - 同時接続数上限やセキュリティソフトの影響
Windows Defenderやサードパーティ製ウイルス対策ソフトがファイルサーバーへのアクセスをブロック・遅延させている可能性もあります。ログを確認し、特定のプロセスがSMB通信をブロックしていないか調べましょう。
ストレージ側の確認
- 共有フォルダ（SMB/NFS）の応答状況
Windows Serverがホストしている共有であればSMBが主体ですが、他システムでNFSを利用していることも考えられます。プロトコルごとにログの保存先やトラブルシュートの方法が異なるため、利用しているプロトコルに応じたチェックを行います。 - ファイルサーバーの負荷状況
同時に多数のクライアントから接続があると、ディスクI/OやネットワークI/Oがボトルネックになる場合があります。ファイルサーバーのパフォーマンスモニターを確認し、I/O待ちが発生していないかを監視してください。 - クラスタリング環境（仮想化環境を含む）の問題
仮想マシンが稼働しているホストのクラスタリングが不安定な場合や、ストレージ仮想化（vSAN等）を利用している環境でのレプリケーション遅延が原因となっていないかも検討する必要があります。
さらに踏み込んだ原因究明：構成の見直しと代替策
上記の手順を行っても解決しない場合、あるいはUPDを使わない設定で問題が発生しないようであれば、RDS構成そのものやUPD以外のプロファイル管理方式（例：FSLogix）を検討することも視野に入れるとよいでしょう。
Remote Desktop Services全体の構成確認
RDSには、セッションホスト、接続ブローカー、ライセンスサーバー、ゲートウェイなど、複数の役割が存在します。特定のコンポーネント（例：接続ブローカー）が動作不良を起こしていると、ログインフェーズで不整合が起こることがあります。
- 接続ブローカー（Connection Broker）の役割
複数のセッションホストを束ねる形で、ユーザーのセッションを管理・振り分ける機能を担います。接続ブローカーのデータベースに問題があると、ログインプロセスで異常な遅延が生じる場合があります。 - ライセンスサーバーの状態
RDS CAL（Client Access License）が有効期限切れになっていたり、ライセンスサーバーが認識されていないと、セッションの確立に問題が発生することがあります。
UPD以外のプロファイル管理手法の検証
近年のMicrosoft 365やAzure環境下ではFSLogixによるプロファイル管理が注目を集めています。FSLogix Profile Containerを導入することで、UPD特有のマウント問題や競合を軽減できる可能性があります。
- FSLogix Profile Containerのメリット
- 高速なログイン・ログオフ性能
- OneDriveキャッシュやOutlookキャッシュも含めて一元管理
- プロファイル破損時のリカバリが容易
もしUPDの設定が複雑である場合や、ライフサイクル的にFSLogixを導入可能な環境であれば、UPDの代替として検証する価値は十分にあります。
グループポリシーとの兼ね合い
ユーザープロファイルに関するグループポリシー設定（例：リダイレクトフォルダやログオンスクリプト）とのコンフリクトが発生すると、UPDやFSLogixの初期化プロセスが妨げられるケースがあります。特に「Delete cached copies of roaming profiles（ roamingプロファイルのキャッシュを削除する ）」設定などが有効になっていると、意図せずプロファイル情報の削除が行われログインに失敗することがあるため、注意が必要です。
根本対策とベストプラクティス
最終的には、下記のような運用上のベストプラクティスを取り入れることで、リモートデスクトップ環境の安定性を高められます。
1. 監視体制の強化
- イベントログの自動収集・分析
サードパーティの監視ツールやAzure Monitorなどを利用し、重大なエラーを即時キャッチしてアラートを飛ばす仕組みを整える。 - 定期メンテナンス
Windows Update後の動作検証やサービスの再起動手順を定期的に実施し、クリアな状態を保つ。
2. RDSライセンス・バージョン管理
- ライセンスサーバーのアクティベーション確認
定期的にRDS CALの期限や状態をチェックし、トラブルの原因とならないようにする。 - Windows Server 2019の累積アップデート
可能な限り最新の累積アップデート（Cumulative Update）を適用し、不具合修正パッチを取り込み続けることで、類似の問題が再発しにくくなる。
3. ネットワーク・ストレージの冗長化
- 複数NICやチーミングの導入
ネットワーク障害があった場合でも別経路で通信を継続できるように設定しておく。 - ストレージのHA構成
共有フォルダを提供するファイルサーバーをクラスタリングしたり、リージョン間レプリカを用いて冗長化を図ることで、UPDのマウント失敗を回避する。
4. UPDをどうしても使わないといけない場合の対策
- ユーザー別ディスク容量の適切な割り当て
ユーザープロファイルが肥大化すると、UPDの読み込みに時間がかかり、タイムアウトを招きやすくなります。定期的に不要ファイルを整理し、ディスク容量に余裕を持たせる運用が望ましいです。 - ログオフ時のクリーンアップ強化
既定のログオフスクリプトやタスクスケジューラで、一時ファイルやキャッシュを削除するように設定しておくことで、ディスク容量の圧迫やプロファイル破損を防ぎます。
まとめ：最優先はUPD保存先とネットワークの安定性
「Please wait for the Remote Desktop configuration」が長時間表示される場合、多くはUser Profile Disksの保存先共有がオフラインもしくはアクセス不可になっているか、ネットワークトラブルが原因となるケースが多いです。
最初にUPDの存在を確認し、共有フォルダやストレージへのアクセス可否をテストすることから始めましょう。併せてイベントビューアーをチェックし、UPDやネットワーク、RDS構成に関連するエラーが記録されていないかを探ることが有効です。
問題が根深い場合にはRDS全体の構成やライセンス状況も含めた大きな視点での見直し、さらにはFSLogixなどの代替ソリューションの導入検討も必要です。適切な運用と定期的なメンテナンスを行うことで、Windows Server 2019のリモートデスクトップ環境を安定的に保ち、ユーザーが快適に利用できる環境を維持していきましょう。
コメント