Server 2019の「Remote Desktop Configuration」で待機が続く場合は、更新時期と影響するユーザー・ホストの範囲を先に確認します。
「Please wait for the Remote Desktop Configuration」または「Remote Desktop Configuration の処理が完了するのをお待ちください」で止まっても、表示だけでUPDやUmRdpServiceの故障とは特定できません。更新直後の既知の問題、特定ユーザーのプロファイル、ホストや共有への接続を順に分けます。管理者向けの調査手順です。
2026年9月の更新後なら、RDSの既知の問題を確認
MicrosoftはWindows Server 2019で、2026年9月8日のKB5122876（OSビルド17763.9245）導入後にRDSが不安定になり、接続・サインイン失敗やRemote Desktop Configurationの待機、サーバーの応答停止が生じる既知の問題を案内しています。MMC、RDS Licensing Diagnoser、エクスプローラー、Windows Update画面まで応答しなくなる場合もあります。
公式の解決状況では9月14日の定例外更新KB5129238、またはそれ以降の累積更新で解決とされています。KB5129238のビルドは17763.9247です。この記事を確認した2026年10月時点の情報であり、同じ表示が出る全環境の原因をこの更新と判断するものではありません。
- 対象がWindows Server 2019で、問題の開始が9月更新の導入後かを記録する。
- 更新履歴とOSビルドを確認し、KB5122876のみの状態か、修正を含む累積更新まで導入済みかを確認する。
- 該当する場合は公式リリース正常性ページと適用するKBの対象・前提を確認し、バックアップ、再起動、接続ユーザーへの影響を調整して更新する。
- 既に修正済みの環境や時期が違う環境は、次の影響範囲とログ調査へ進む。
KB5129238の単体OOBはMicrosoft Update Catalogからの提供とされ、導入前提にKB5005112のSSUが記載されています。通常の累積更新を選ぶ場合も、そのKBの前提を確認してください。Windows 365やAzure Virtual Desktopは、この特定のRDS既知の問題の対象外とされています。プロファイル削除や修正更新のアンインストールを最初の対処にはしません。
誰が、どのホストで止まるかを分ける
| 比較した結果 | 優先して確認するもの |
|---|---|
| 一人だけ、複数ホストで止まる | そのユーザーのプロファイル、UPDを使っている場合は対象VHDとログ |
| 一台のホストだけ、複数ユーザーで止まる | ホストの更新状態、リソース、サービス、共有への接続 |
| 複数ホスト・複数ユーザーで同時に止まる | 共通の更新、ストレージ/共有、認証、ネットワーク経路 |
| 既存ユーザーは使え、新しい接続だけ止まる | 新規ログオン時の処理、接続先ホスト、プロファイル初期化のログ |
比較は組織で承認したテストユーザーや接続経路で行い、同じ時刻・同じコレクションを記録します。別ユーザーで入れたことだけで元ユーザーのデータ破損を確定せず、接続先ホストが同じかも確認します。切断とサインアウトは違い、切断されたセッションにはアプリやプロファイルが残っている場合があります。
再起動の前に、セッションとサービスを読む
次はセッション情報を読むコマンドです。RDHOST01は実際のRDセッションホスト名へ置き換えます。他ユーザーのセッションを見るには適切な権限が必要です。表示されるユーザー、ID、状態を記録し、別の管理経路も確保します。
query session /server:RDHOST01対象ホスト上のPowerShellでは、元記事で扱っていたサービスを次のように確認できます。Get-Serviceは状態の取得であり、起動・停止は行いません。
Get-Service -Name TermService, UmRdpService, ProfSvc |
Select-Object Status, Name, DisplayNameRunningと表示されても、ログオンやプロファイルの処理が正常に終わった証明にはなりません。停止が見つかった場合も、サービス名と停止時刻、Systemログの本文、依存関係を確認します。TermServiceの再起動やサーバー再起動は接続中の利用者に影響するため、作業中データ、保守時間、コンソール/仮想マシン管理など復旧用経路を調整してから行います。
UPDを使っている場合の共有・VHD確認
User Profile Disks（UPD）はコレクション単位の機能で、ユーザーごとのVHDをログオン時にマウントして使います。まずServer ManagerのRemote Desktop Services → Collections → 対象コレクションのProperties → User Profile Disksで有効か、保存先がどこかを確認します。有効でない環境をUPDの故障として調べ続けないようにします。
- 対象コレクションとUPDの保存先UNCパスを確認する。
- そのコレクションのRDセッションホストからSMB共有に到達できるか調べる。
- 共有側の空き容量と、対象ユーザーのVHDが使われている状態・エラーを確認する。
- Microsoftの構成要件に従い、コレクションのサーバーが中央共有に必要なフルコントロールを持つか、共有とNTFSの実効権限を管理者が確認する。
- 同じ時刻のプロファイル/ストレージのログと照合する。
クライアントPCや管理者アカウントで共有を開けることは、RDホストが必要な認証と権限でUPDをマウントできる証明ではありません。元記事の固定名testfile.txtへの書き込みは既存ファイルを上書きするおそれがあるため、一般的な診断例から外します。書き込み検証が必要なら管理者がテスト範囲・一意な名前・権限・後処理を設計します。
次はRDホストから共有サーバーのSMBポートへTCP接続できるかを調べる例です。fileserver.example.localは実際の共有サーバー名へ置き換えます。共有の内容を変更しませんが、診断の通信は発生します。
Test-NetConnection -ComputerName "fileserver.example.local" -Port 445 -InformationLevel DetailedTcpTestSucceededがTrueでも、共有/NTFS権限、Kerberos認証、VHDマウント成功までは確認していません。Falseなら名前解決、経路、ファイアウォール、共有サーバー側を確認します。セキュリティ機能を一括無効化して試す方法は使いません。UPDの稼働中VHDを手作業で取り外したり、ユーザープロファイルを削除したりする前に、セッション状態とデータの保管・復旧計画を確認してください。
イベントIDだけで原因を決めず、時刻と本文を読む
イベントビューアーのApplicationログでUser Profiles Serviceの警告/エラーを探し、発生時刻と対象ユーザーを記録します。さらにApplications and Services Logs → Microsoft → Windows → User Profile Service → Operationalで、同じログオンの処理を追います。Microsoftの調査案内ではApplicationとOperationalのログは既定で有効です。
イベントIDはソースによって意味が異なります。「1000〜1111は全部プロファイル障害」のように広い番号範囲を対応表にしません。例外コード、ファイル/共有パス、アクセス拒否、ユーザー、ホスト名まで読みます。またUser Profiles Serviceの1530は、それだけで今回の待機を示すエラーとは限らず、Microsoftの案内では無視できるイベントとして扱われています。
Windowsのログオンプロセスの予期せぬ終了が記録されている場合も、同時刻のApplication/Systemの実際のエラーと障害プロセスを確認します。ログが足りない場合のDiagnosticやトレース採取は、公式手順と運用担当者の範囲で一時的に行い、採取後に戻します。待機時間だけでUPD破損やネットワーク障害を断定しません。
ライセンスやFSLogixを使う環境の追加確認
ライセンス関連の明確なエラーがある場合は、設定したRDSライセンスサーバー、Per User/Per Deviceのモード、CALとホストのバージョン互換性を確認します。CALの発行表示の有効期限と、製品の購入ライセンスを一律に同じ「期限切れ」と扱いません。RDS Licensing Diagnoser自身が応答しない場合は、上記の更新後の既知の問題との一致も確認します。
FSLogixを既に導入している環境は、UPDの設定と混同せずC:\ProgramData\FSLogix\Logs\Profileの対象日ログで、ユーザーのログオン時刻、LoadProfile、プロセスID、警告/エラーを追います。FSLogixの公式資料は2026年4月のKerberos暗号化変更によるSMBストレージへの影響も案内しているため、該当する保存先は担当者が暗号化対応状況を確認します。認証保護を弱める対処には置き換えません。
FSLogixへの移行、ストレージ冗長化、NICチーミングは別の設計変更です。現障害の原因や適用条件を特定する前に、どれかで必ず待機が解消すると案内しません。まず更新、影響範囲、実際のログから今回の障害に合う対処を選びます。
復旧後に確認しておくこと
- 影響を受けていたユーザーが同じコレクションでログオン・サインアウトできる。
- 別ユーザーや別ホストでも結果を比較し、待機や切断が再発していない。
- プロファイルのデータと必要なアプリ設定が残っている。
- 適用した更新/変更と時刻、前後のログ、影響したセッションを記録する。
- 未解決ならOSビルド、導入KB、影響範囲、ログ本文を添えて管理者・Microsoftサポートへ調査を引き継ぐ。
この記事では実際のRDSサーバーの更新、セッション終了、共有への書き込み、サービス変更は行っていません。読み取り例も対象ホストと組織の権限を確認して使用してください。
コメント