Windows 11のリモートデスクトップが切断される場合、通信だけでなく、接続先PCのスリープ、セッションポリシー、RDPサービス、VPNやRD Gatewayも候補です。最初に「何分後に」「画面を操作中か放置中か」「再接続すると同じセッションへ戻るか」を記録し、クライアント・ホスト・経路・セッションの4領域に分けます。ファイアウォールやUDPを一律に無効化せず、読み取り確認から進めるのが安全です。
まず切断の種類を記録する
「切断」には、RDPウィンドウだけ閉じて接続先の処理は続く状態、接続先でサインアウトされる状態、接続先PC自体が再起動・スリープする状態があります。再接続後に開いていたアプリがそのままなら、セッションは残り通信経路だけが切れた可能性があります。アプリも消えて新規サインインになるなら、サインアウト、セッション制限、OS再起動を調べます。接続先PCへ現地で触れられる担当者がいる場合は、同時刻の電源状態も確認してもらいます。
障害時刻は秒単位でなくてもよいので記録し、表示メッセージを全文保存します。「毎回ほぼ60分」「数分操作しないと切れる」「Wi-Fiを移動した瞬間」「VPN再接続時」のような規則性は重要です。接続元だけを有線へ変えた結果、別の利用者から同じホストへ接続した結果、同じ利用者が別ホストへ接続した結果を比較すると、どの境界に原因があるか絞れます。
接続先がRDPホストの条件を満たすか
Microsoftの案内では、接続先としてリモートデスクトップを受けるWindowsはProエディションなど対応版が必要です。接続元のアプリはHomeでも利用できますが、Windows 11 Homeを接続先にする標準RDPホスト機能は対象外です。接続先で「設定」→「システム」→「バージョン情報」に進み、エディションを確認します。続いて「設定」→「システム」→「リモート デスクトップ」が有効かを確認します。組織管理端末では設定がポリシーで固定されるため、勝手に解除しません。
PC名やIPアドレスを取り違えていると、一時的に別端末へ接続できたり名前解決が変わったりします。接続先の正式なコンピューター名、社内DNS名、利用するVPNまたはRD Gatewayを管理者の台帳と照合します。3389番ポートをルーターで直接インターネットへ公開する方法は避け、組織が提供するVPNやRD Gateway、多要素認証を利用してください。
通信経路を読み取り確認する
直接RDPする構成で、接続元から接続先の3389番へ到達できるかはPowerShellのTest-NetConnectionで確認できます。これは設定を変更しない確認コマンドです。HOST01は実際の承認済みホスト名に置き換えます。
Test-NetConnection -ComputerName HOST01 -Port 3389TcpTestSucceededがTrueなら、その時点でTCP接続できたことを示すだけで、RDPセッション全体の安定性を保証しません。Falseなら名前解決、VPN、経路、ホスト停止、ファイアウォール、サービスなどを管理者と調べます。RD Gateway経由では利用者端末が接続先の3389番へ直接到達しない設計があります。VPN製品も独自の経路を使うため、その場合は上記の結果だけで障害と断定せず、管理者が指定するゲートウェイと診断手順を使います。
Wi-Fi利用時だけ切れるなら、同じ場所で有線または安定した別ネットワークを使い、同じ時間だけ再試験します。公衆Wi-Fiへの切り替えは機密通信や認証情報のリスクがあるため避けます。VPNが切れた結果としてRDPが切れる場合、RDPクライアントの設定よりVPNログと再接続時刻が重要です。ネットワークアダプターのドライバー更新は、メーカーまたはWindows Updateの承認済み版と復旧方法を確認してから行います。
セッションが残っているかを確認する
接続先へ管理権限のある別経路から入れる場合、quserで現在のセッション名、ユーザー名、状態、アイドル時間、ログオン時刻を表示できます。閲覧権限がない環境では管理者へ依頼します。
quser /server:HOST01切断直後も対象ユーザーがDisc状態で残るなら、サインアウトではなく切断である可能性が高まります。セッションが消えた場合は、グループポリシーのアイドル制限・切断セッションの終了、管理者操作、OS再起動などを確認します。quserの表示だけで誰が切断したかは分かりません。利用者が他人のセッションをログオフさせる操作は行わず、表示結果と時刻を管理者へ渡します。
イベントログでホスト側の事実を探す
Microsoftのトラブルシューティングでは、接続先のイベントビューアーにあるRemoteDesktopServices関連ログを確認します。「アプリケーションとサービス ログ」→「Microsoft」→「Windows」配下のTerminalServices-LocalSessionManagerやTerminalServices-RemoteSessionManagerを、記録した障害時刻で絞ります。イベントIDだけを検索して即断せず、レベル、ソース、時刻、説明、前後の関連イベントをまとめて確認します。
同じ時刻にWindows Update後の再起動、ネットワーク切断、サービスエラーがあれば関連を検討します。イベントログの消去や保持設定の変更は証跡を失うため行いません。エクスポートには端末名やユーザー名が含まれることがあるので、組織内の承認された保存先に限定します。プロトコルエラーが反復する場合も、レジストリでUDPを無効化する対策を先に試すのではなく、Windows版、RDPクライアント版、ネットワーク機器、Gatewayのログをそろえて管理者へ引き継ぎます。
接続先のスリープと電源を確認する
接続先PCがスリープに入ればRDP通信は維持できません。接続先で「設定」→「システム」→「電源とバッテリー」→「画面、スリープ、休止状態のタイムアウト」を確認します。ノートPCでは電源接続時とバッテリー時で値が異なることがあります。蓋を閉じた動作や組織の省電力ポリシーも別に管理される場合があります。
確認のためにスリープを一時的に延長する場合も、消費電力、発熱、物理セキュリティへ影響します。組織端末では利用者判断で「なし」に固定せず、管理者の承認を得ます。試験後は元の値へ戻し、変更前後と結果を記録します。接続先が再起動していた場合は、信頼性モニターやWindows Update履歴、システムイベントを管理者が確認します。
一定時間で切れる場合はポリシーを疑う
毎回同じアイドル時間または最大接続時間で切れる場合、サーバーや組織のグループポリシーで制限されている可能性があります。これは障害ではなく運用要件かもしれません。利用者側のRDPファイルだけで解除できるとは限らず、セキュリティ目的の設定を回避してはいけません。切断時刻、quserの状態、業務上必要な接続時間を管理者へ提示し、ポリシーの設計者に確認します。
WindowsやRDPクライアントの既知問題が疑われる場合は、現在のOSビルドと更新履歴を確認します。古い記事にある特定ビルド向けの回避策を、別ビルドへそのまま適用しないでください。更新はパイロット端末と復旧手順を用意し、管理された保守時間に行います。直近更新直後から始まった場合も、更新を無計画に削除せず、既知問題と後続修正を管理者が照合します。
安全な確認順と引き継ぎ
推奨順は、症状と時刻の記録、別クライアント・別ホストとの比較、ホストのエディションとRDP有効状態、VPNまたはGatewayの状態、直接接続構成ならTest-NetConnection、quserによるセッション状態、イベントログ、電源とポリシーです。各段階で一つだけ条件を変え、同じ時間再現試験をします。
管理者へは、接続元・接続先の名称とWindows版、RDPクライアント版、接続方式、発生時刻、操作中かアイドル中か、再接続時のセッション状態、ネットワーク比較、コマンド結果、関連イベントを渡します。認証情報、秘密鍵、VPN設定ファイルは添付しません。この情報があれば、セキュリティ制御を弱めずに原因領域を判断できます。
コメント