Windowsの「リモートセッションを構成しています」が終わらない問題:原因と対処法

リモートデスクトップ接続で「リモートセッションを構成しています」の表示から進まない場合、ネットワーク接続そのものは始まっていても、認証、ユーザープロファイル読込、グループポリシー、ログオンスクリプト、シェル起動など、その後の段階で待機している可能性があります。接続を繰り返すと同じユーザーのセッションが複数残る場合もあるため、まず発生範囲と接続段階を整理し、クライアント、経路、接続先、ユーザー固有の要因を順番に切り分けます。

目次

表示メッセージだけで原因を決めつけない

「構成しています」という画面は、接続処理の一場面を示すだけで、必ずしもRDPサービス設定だけが原因とは限りません。DNSで名前を引けない場合、TCP接続が成立しない場合、証明書確認、ネットワークレベル認証、資格情報、プロファイルのマウント、ログオンスクリプトなど、止まる位置によって調査対象は変わります。エラー番号や追加メッセージが表示されたら、画面を閉じる前に正確に記録します。

発生時刻、接続元端末、接続先の完全修飾ドメイン名、VPNの有無、ユーザー名、初回か再接続か、他ユーザーの状況を残します。同じ端末から別サーバーへ接続できるか、別端末から同じサーバーへ接続できるか、同じサーバーへ別ユーザーが入れるかを比較すると、クライアント、ネットワーク、ホスト、ユーザーのどこへ範囲を絞るべきか判断できます。

名前解決とRDPポート到達性を確認する

最初に接続先名が正しいIPアドレスへ解決されるかを確認します。古いDNSキャッシュ、VPN接続前後で異なるDNS、同名ホスト、接続先の変更があると、別の端末へ向かうことがあります。IPアドレスを直接指定してつながるかは切り分けに使えますが、証明書名や管理方針との不一致が起きるため恒久設定にはせず、DNS修正を優先します。

PowerShellのTest-NetConnection -ComputerName server.example -Port 3389は、指定ホストのRDPポートへTCP接続できるかを確認する読み取りテストです。RDPポートが変更されている環境では実際の値を使います。TcpTestSucceededがFalseなら、クライアントのファイアウォール、VPN、経路、接続先ファイアウォール、RDPリスナーの順に確認します。Trueでも認証以降の成功は保証しません。

RDPリスナーと接続先の稼働状態を調べる

管理者は物理コンソールや仮想基盤コンソールなど別経路から接続先へ入り、OS全体が応答しているかを確認します。MicrosoftのRDS接続ガイダンスでは、RDPプロトコル、グループポリシー、サービス、リスナーなどの基礎要素を順に確認するチェックリストが示されています。他の管理経路でもログオンが遅い場合、RDP固有ではなくCPU、メモリ、ディスク、プロファイル、更新などOS全体の問題を疑います。

タスクマネージャーやパフォーマンスモニターで、CPU、利用可能メモリ、ディスク応答時間、空き容量を確認します。RDPポートがListen状態か、Remote Desktop Servicesが意図した状態かも確認します。ただしサービス再起動は既存セッションへ影響するため、利用者数、管理用の代替経路、変更時間を確認してから行います。リスナー設定やポートを推測で変更しないでください。

ユーザーセッションの重複と状態を確認する

特定ユーザーだけ止まる場合、切断状態の古いセッション、ログオフ途中のセッション、同じユーザーの複数セッションが残っていないかを確認します。quserなどでセッションID、状態、アイドル時間、ログオン時刻を照合します。他ユーザーが正常なら、ホスト全体よりユーザープロファイル、ログオンスクリプト、ユーザー別アプリ、資格情報を優先して調べます。

古いセッションを強制ログオフすると未保存データが失われるため、利用者へ連絡し、実行中処理を確認します。新しいセッションを作るためだけに古いセッションを終了するのではなく、なぜ再接続されなかったかを記録します。接続ブローカーを使うRDS構成では、セッションホスト単体だけでなく、ブローカーの割り当て、コレクション、ユーザープロファイルディスクやFSLogixの状態も確認します。

認証・資格情報・証明書の段階を切り分ける

パスワード変更直後、保存済み資格情報が古い場合、アカウントロック、時刻ずれ、ドメインコントローラー到達性の問題では、接続処理が認証周辺で止まることがあります。Windows資格情報マネージャーに保存された対象サーバーの資格情報を確認し、組織の手順に従って更新します。資格情報を平文でメモしたり、複数利用者で共有したりしないでください。

証明書失効確認や信頼チェーンの取得に時間がかかると、「リモート接続をセキュリティで保護しています」など接続前段階で長く待つことがあります。証明書警告を無視して進めるのではなく、接続先名、発行先、有効期限、信頼された証明機関、失効確認先への到達性を管理者が確認します。NLAや暗号化を無効化して回避する方法は、セキュリティを下げるため初手にしません。

プロファイル・GPO・ログオンスクリプトを調べる

認証後にユーザープロファイルの読込が進まない場合、プロファイル保存先のネットワーク、空き容量、ファイルロック、ウイルス対策スキャン、破損、同時マウントを確認します。特定ユーザーだけ遅いときは、別ユーザーでの比較が有効です。原因確認なしにユーザープロファイルを削除すると、設定やローカルデータを失う可能性があるため、バックアップと影響確認なしで実施しません。

グループポリシーやログオンスクリプトがネットワーク共有、プリンター、ドライブ、外部サービスの応答を待つ場合もあります。GroupPolicyのイベントログ、スクリプトの実行時刻、対象共有の到達性を確認します。ポリシーをすべて無効にするのではなく、直近変更と対象範囲を確認し、検証用OUやテストユーザーで一項目ずつ比較します。セキュリティ製品も無断で停止しないでください。

イベントログで処理の止まった段階を探す

接続元と接続先の両方で、発生時刻周辺のイベントを確認します。接続先ではTerminalServices関連、User Profile Service、GroupPolicy、Application、System、認証関連ログを見ます。接続元ではRDPクライアント関連ログとネットワーク変化を確認します。同じエラーが大量に出ていても、発生時刻と一致しない古い記録は今回の原因とは限りません。

イベントID、ソース、メッセージ、ユーザー、セッションID、相関IDを保存し、問題が起きた接続一回分の時系列を作ります。「接続開始」「認証」「セッション割当」「プロファイル読込」「シェル起動」のどこまで進んだかを並べると、調査対象を絞れます。ログを消去したり、再起動で証拠を失ったりする前に、必要なログをエクスポートします。

安全な復旧順序と再発防止

利用者側ではネットワークとVPNの再接続、保存済み資格情報の確認、クライアント再起動を行い、管理者側ではセッション状態、ホスト負荷、RDPリスナー、プロファイル、GPO、ログを確認します。影響が特定セッションに限られ、未保存データへの承認が取れた場合だけログオフを検討します。サービスやサーバー再起動は複数ユーザーへの影響を確認し、保守手順で実施します。

再発防止では、発生ユーザー、接続元、時間帯、VPN、特定アプリ、ポリシー更新、Windows更新の共通条件を集めます。接続タイムアウトを単に長くするだけでは根本原因を隠すことがあります。監視にはRDPポート到達性だけでなく、ログオン所要時間、プロファイルマウント、ホスト資源、ブローカーやライセンスの状態を含め、利用者が感じる接続完了までを測ります。

確認チェックリスト

  • 同じ接続元・別接続元、同じユーザー・別ユーザーで発生範囲を比較する
  • 名前解決と実際のRDPポートへの到達性を確認する
  • 別管理経路からホスト負荷、リスナー、セッション状態を確認する
  • 資格情報、証明書、プロファイル、GPO、ログオンスクリプトを段階別に調べる
  • 強制ログオフやサービス再起動前に未保存データと他ユーザーへの影響を確認する
  • 接続元と接続先のイベントログを同じ時刻で照合する

復旧後は、対象ユーザーがデスクトップまで到達できること、業務アプリ、共有フォルダー、プリンターが利用できること、通常のサインアウトと再接続が成功することを確認します。一度つながっただけで完了とせず、同じ条件で再現しないか、ログオン時間が通常へ戻ったか、別ユーザーへ副作用がないかも記録します。

公式情報・参考資料

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次