紹介
Windows Serverが新しいRemote Desktop接続を拒否する場合、サービスやサーバー全体を再起動する前に、失敗の原因を特定することが重要です。問題は1人のユーザーに影響していますか、それとも複数のセッションに影響していますか?この記事では、IT管理者が初期チェックからより高度な診断および予防措置まで、考えられる原因、実用的なトラブルシューティングコマンド、回復手順を説明します。
「リモートデスクトップサービスが現在ビジーです」というメッセージが表示されるとはどういう意味ですか?
エラーは、Windowsが要求されたリモートデスクトッププロトコル(RDP)機能またはアクションを実行できないときに発生します。一般的に、表示されるエラーメッセージは次のようになります:
実行しようとしているタスクは、現在リモートデスクトップサービスが忙しいため、完了できません。数分後に再試行してください。他のユーザーは引き続きログオンできるはずです。
エラーメッセージは、システムが別のセッションを追加できず、リモートデスクトップが最大容量に達していることを示唆していますが、必ずしもそうではないかもしれません。
エラーは単一のユーザーアカウントまたは複数のユーザーアカウントで発生する可能性があります。前者の場合は、セッションを再起動することが可能であるべきです。しかし、後者の場合は、システムがどのユーザーにも接続を確立することを許可しない可能性があります。
さらに、この問題は単一のユーザーセッションまたはすべてのユーザーセッションに影響を与える可能性があります。これらの2つのシナリオを区別することが重要です。なぜなら、それに対処するために必要な解決策が異なるからです。
Microsoft Learnの RDSセッション接続トラブルシューティングガイダンス Windows Server ホストに影響を与える接続障害を特定するための追加チェックを提供します。
このエラーの原因は何ですか?
RDPセッションを確立するために関与するいくつかのWindows Serverコンポーネントがあります。セッションの管理、システムリソース、Windowsサービス、またはログオンプロセスに関する問題は、接続の確立を妨げる可能性があります。
応答しないまたはフリーズしたRDPセッション
セッションは接続、切断、再接続、またはログオフする際にフリーズすることがあります。その後、Windowsはセッションを完了するか、リソースを解放することに失敗します。
管理者は再接続を拒否するかログオフするセッションを見つけることができます。この問題は、他のセッションが正常に動作していても、1つのセッションでのみ発生する可能性があります。
まだ一つの 切断されたセッション 正常であり、ロックがかかった場合のみリセットする必要があります。
リソース枯渇とログオンストーム
リソースが不足していると、セッションの初期化が遅れたり、妨げられたりする可能性があります。最も一般的な問題は、CPUの飽和、メモリ不足、過剰なディスク活動、遅いプロファイルの読み込みです。
そのような問題は、数百人のユーザーが同時にリモートデスクトップ接続を確立するログオンストームの際に特に顕著です。認証、グループポリシー、プロファイルの読み込み、およびアプリケーションの起動活動は、共有リモートデスクトップセッションホストに対して大きな負荷を生成します。
ただし、高いリソース利用はこのエラーに遭遇するための要件ではありません。CPUおよびメモリの利用率が低くても、セッション処理の失敗が発生することがあります。
メモリリークとサードパーティソフトウェア
メモリリークや適切に解放されないセッションオブジェクトは、Windows Serverのリモート接続を受け入れる能力に影響を与える可能性があります。
この問題は、マシンを再起動すると正常な機能が復元される場合に特に顕著ですが、数時間または数日後にエラーが再発する場合です。
サードパーティ製ソフトウェアの適用が、何らかの形でWindowsセッションと連携することも理由となる場合があります。これには、エンドポイント保護エージェント、セキュリティフィルター、またはWindowsセッションに干渉する可能性のある類似のソフトウェアが含まれます。
これらのドライバーは通常、対応するシステムサービスが停止されるときにアンロードされないため、そのような仮説の調査にはサービスを停止するだけでは不十分な、より徹底的なアプローチが必要です。
グループポリシーとユーザープロファイルの問題
グループポリシーは指示します リモートアクセス 接続、セッション制限、およびRemote Desktop Session Hostの動作に関するその他の機能に関連する権限。誤った権限やポリシー間の競合は、接続の問題を引き起こす可能性があります。
グループポリシークライアントサービスの失敗は、Windowsのログオンプロセスにも干渉する可能性があります。
同時に、Windowsはユーザープロファイルに何か問題が発生した場合、セッションを完了できません。この場合、管理者はユーザープロファイルサービスに注目し、ユーザープロファイルストレージが利用可能かどうかを確認し、長いログインセッションが接続の問題と重なる場合は、FSLogixや他のツールを使用してユーザープロファイルを管理することを検討する必要があります。
このエラーを修正するには何をすればよいですか?
トラブルシューティングのアクションは、一般的なものから特定的なものへと進め、非破壊的なテストからターゲットセッションの回復およびサービスやサーバーの再起動を必要に応じて行うべきです。
次の手順を使用して、ユーザーの作業を中断することなく問題を絞り込むことができます。
ステップ 1: 問題が1人のユーザーに影響するのか、サーバーに影響するのかを判断する
しばらくお待ちいただき、再度お試しください。問題は、一時的なリソースの競合や遅延したログオンプロセスにより、自動的に解決される可能性があります。
接続がまだ失敗する場合は、より広範な RDP接続のトラブルシューティング ネットワーク、クライアント設定、または接続の問題を調査する前に、排除するのに役立つかもしれません。
問題が続く場合は、範囲を特定してください。
- 他のユーザーは接続を正常に確立できますか?
- 既存のRDPセッションは稼働していますか?
- 失敗は成功した認証の前ですか、それとも後ですか?
- 問題はWindowsの更新または設定変更の前に発生しましたか、それとも後に発生しましたか?
- 管理者はサーバーコンソールを使用してローカルにログオンできますか?
仮想マシンの場合、ハイパーバイザーコンソール接続はRDPを使用しないことを考慮してください。Hyper-Vを使用している場合、拡張セッションがRDPを使用するため、基本セッションタイプを使用する必要があります。
コンソールログオンが失敗している場合は、RDS特有の問題だけでなく、Windowsレベルのログオンやオペレーティングシステムの問題を調査してください。
ステップ2: Windows Serverリソースを確認する
管理者アクセスが利用可能になったら、タスクマネージャーまたはパフォーマンスモニターを使用して、CPU使用率、利用可能なメモリ、ディスクアクティビティ、およびストレージ容量を確認してください。
システムドライブの空き容量を迅速に確認するには、PowerShellを実行します。
Get-Volume -DriveLetter C
最も物理メモリを消費しているプロセスを特定するには:
プロセスを取得 | オブジェクトをソート WorkingSet64 -降順 | オブジェクトを選択 -最初の 10 名前、ID、WorkingSet64
認証やプロファイルの読み込み中に、特に異常なリソース消費を探してください。
単一のパフォーマンススナップショットでは、メモリリークが明らかにならない場合があります。リソース消費が正常に見える場合は、セッション診断を続け、エラーが再発する場合は時間をかけてパフォーマンスデータを収集してください。
ステップ3:スタックしたRDPセッションを特定してリセットする
特定のユーザーが再接続できない場合、影響を受けたサーバーのセッションを確認してください。
管理者権限のコマンドプロンプトを開き、実行します:
コマンドはセッションID、ユーザー名、および接続状態を表示します。典型的な結果は次のようになります:
SESSIONNAME USERNAME ID STATE
console Admin 1 アクティブ
rdp-tcp#5 User01 3 アクティブ
User02 4 切断
rdp-tcp 65536 リッスン
セッションが故障していることが確認された場合は、そのIDを使用してリセットしてください。
4を実際のセッションIDに置き換えてください。
適切な権限を持つ管理者は、セッションをリモートで照会することもできます。
次に、特定されたセッションをリセットします:
注意
セッションをリセットすると、そのアプリケーションが終了し、未保存の作業が失われる可能性があります。セッションの識別を確認し、可能な限りユーザーに通知してください。
すべての切断されたセッションを無差別にリセットしないでください。また、次のような重要なWindowsプロセスを強制的に終了させることも避けてください。
csrss.exe
オペレーティングシステムを不安定にする可能性があります。
ステップ 4: リモートデスクトップサービスとイベントログを確認する
セッションの回復でエラーが解決しない場合は、リモートデスクトップサービスを確認してください。
実行:
Get-Service -Name TermService
サービスは通常、報告する必要があります
実行中
ステータス。ただし、これはサービスが実行中であることを確認するだけであり、Windowsが新しいセッションを正常に初期化できることを確認するものではありません。
次に、イベント ビューアを開き、関連するログを確認します。
| イベント ビューア ログ | 調査すべきこと |
|---|---|
| Windowsログ > システム | サービスの失敗とシステムエラー |
| Windowsログ > アプリケーション | アプリケーションのクラッシュとプロファイルエラー |
| ターミナルサービス-ローカルセッションマネージャー > 操作中 | セッションの作成、ログオンおよび再接続 |
| ターミナルサービス-リモート接続マネージャー > 操作中 | 接続処理と認証 |
| グループポリシー > 操作 | ポリシー処理の失敗 |
最後の3つのログは以下にあります
アプリケーションとサービスのログ > マイクロソフト > ウィンドウズ
.
接続失敗の正確な時間とイベントを関連付けます。失敗の近くで発生したイベントは証拠を提供するかもしれませんが、それが自動的に因果関係を確立するわけではありません。
複数のユーザーが影響を受け、ターゲットリカバリーが失敗した場合、リモートデスクトップサービスの制御された再起動を検討することができます。
サービスを再起動 - 名前 TermService
この操作はアクティブな接続に影響を与える可能性があり、サービスの依存関係によって制限される場合があります。試みる前にサービスの設定と運用上の影響を確認してください。
本番RDSホストでは、ユーザーが作業中にサービスを再起動するよりも、計画されたメンテナンスウィンドウを優先してください。
ステップ5:グループポリシーと接続制限の確認
構成変更後にエラーが発生した場合は、影響を受けたサーバーに適用されているグループポリシー設定を確認してください。
レポートを生成する:
レポートを開き、以下のポリシーを確認してください:
コンピューターの構成 > 管理用テンプレート > Windowsコンポーネント > リモートデスクトップサービス > リモートデスクトップセッションホスト > 接続
接続の最大数を制御するポリシー、単一セッションの制限、およびリモート接続の許可に特に注意してください。
また、リモートデスクトップサービスを通じたログオンを管理するユーザー権限の割り当てを確認してください。
最近のポリシー変更がエラーと一致する場合は、制御されたテストを通じてその影響を調査してください。失敗に寄与していることを確認せずにセキュリティポリシーを無効にすることは避けてください。
ステップ6:RDSライセンスとドレインモードの確認
一部の接続失敗は、故障しているセッションではなく、RDSの展開設定に起因しています。
マルチユーザーのリモートデスクトップセッションホスト展開の場合、ライセンスモードと構成されたライセンスサーバーを確認してください。
セッションホストが新しい接続を意図的に拒否しているかどうかも確認してください。
新しいユーザーログオンが無効になっている場合、サーバーがメンテナンスのためにドレインモードに設定されているかどうかを確認してください。
適切な場合、新しいログオンは次のように再有効化できます:
逆排水モードがなぜ起動されたのか確認せずに解除しないでください。
ライセンスの問題、接続制限、ドレインモードは必ずしも正確な「リモートデスクトップサービスは現在ビジーです」というメッセージを生成するわけではありません。これらのチェックは、新しい接続が失敗するが既存のセッションが稼働しているときに最も有用です。
ステップ7:ユーザープロファイルとサードパーティソフトウェアを調査する
エラーが続く場合は、セッションの初期化に関与するコンポーネントを調査してください。
ユーザー固有の障害については、まず影響を受けたアカウントがそのプロファイルを正常に読み込めるかどうかを確認してください。ユーザープロファイルサービスのイベント、プロファイルストレージのアクセス可能性、および認証の遅延を確認します。
FSLogixやユーザープロファイルディスクの文脈では、プロファイルコンテナの可用性、マウントの失敗、およびストレージパフォーマンスの問題を考慮してください。
システム全体の繰り返しの失敗については、Windowsセッションと相互作用する最近インストールまたは更新されたソフトウェアに焦点を当ててください。
セキュリティエージェント、エンドポイント保護製品、およびシステムレベルのフィルターは、セッション処理の失敗を引き起こす可能性があります。すべての隔離テストは、ベンダーの推奨事項および変更管理手順に従って実施する必要があります。
ステップ8: 必要に応じてWindows Serverを再起動します
対象のトラブルシューティングで問題が解決しない場合、サーバーを再起動することでRDP接続を再確立できる可能性があります。
再起動する前に、現在確立されているセッションとホストされているアプリケーションへの影響を理解していることを確認してください。可能であれば、マルチホストRDS展開では、ホストを排出し、新しい接続を別のホストにリダイレクトしてください。
再起動後、リモートデスクトップサービスが正常に動作していることを確認し、ユーザーが接続でき、新しいエラーがイベントビューアに生成されていないことを確認してください。
再起動は、即時の問題を引き起こしている状況が修正されたことを確認しますが、根本的な原因が対処されたことを確認するものではありません。
再起動後にエラーが再発する場合は、さらなる調査のために証拠を保存し、リソース消費の過剰、個々のセッションの処理の失敗、サードパーティソフトウェアによる干渉のパターンを探してください。
RDSのビジーエラーが繰り返される場合、どのように対処すべきですか?
エラーが繰り返されると、強調点はネットワークへのアクセスを回復することから、この中断の原因を特定することに変わります。
以下の表は、トラブルシューティングのための便利なガイドとして機能します。
| 観察された症状 | 調査優先度 |
|---|---|
| 1人のユーザーは再接続できません。 | セッションまたはユーザープロファイルが停止しました |
| 複数のユーザーは接続できません | サービスの健康、リソース、セッション処理 |
| 朝のログオン中の失敗 | 同時ログオン、プロファイルの読み込み、ストレージ |
| 一時的にエラーを解決するために再起動します | メモリまたはセッション関連のリーク |
| セキュリティソフトウェアの更新に続くエラー | サードパーティソフトウェアの相互作用 |
| グループポリシーの変更に従ってエラーが発生しました | ポリシー処理とログオン権限 |
| コンソールログオンも失敗します | より広範なWindowsログオンまたはシステムの問題 |
| 既存のセッションは動作しますが、新しいユーザーは接続できません。 | 接続制限、ドレインモード、ライセンス |
これらのパターンは、明確な診断ではなく、調査の優先順位を示唆しています。
再起動前に診断証拠をキャプチャする
運用上可能な限り、サーバーを再起動する前に、間欠的な障害に対して関連するログとパフォーマンスデータを収集してください。
Microsoftは診断トレースを収集するためのTroubleShootingScript (TSS)ユーティリティを提供しています。
シナリオに応じて、管理者はRDPクライアントトレースをキャプチャできます。
.\TSS.ps1 -Scenario UEX_RDSCli
サーバー側のトレース:
.TSS.ps1 -シナリオ UEX_RDSSrv
現在のMicrosoft TSSドキュメントを使用して、サポートされているシナリオ、前提条件、および実行手順を確認してください。
より複雑な障害の場合、追加のメモリまたはパフォーマンスキャプチャが必要になることがあります。そのような診断は、運用システムに影響を与える可能性があり、機密情報を含む可能性があるため、慎重に計画する必要があります。
マルチサーバー展開では、接続パスにそれらのサービスが含まれる場合、RD接続ブローカーおよびRDゲートウェイコンポーネントを調査に含めてください。
これらのエラーをどのように防ぐことができますか?
すべてのRDSの障害が防げるわけではありません。しかし、継続的な監視、適切なセッションポリシー、制限されたソフトウェアメンテナンスを含む、取るべき手段があります。
サーバーリソースとセッションアクティビティを監視する
RDS環境を監視することで CPU、メモリ、ディスクのトラッキング 、同時にログインされたセッション。
トレンドを閾値ではなく見ること。ベースライン分析は、ピーク時に発生する問題やサーバーを再起動した後に徐々に現れる問題のトラブルシューティングに特に重要です。
システムを監視して、十分なリソースがあるにもかかわらず発生する容量の問題と障害を区別します。
セッションタイムアウトを慎重に設定してください
切断されたおよび非アクティブなセッションを管理するポリシーを確認してください。 Microsoft Learnでは、区別する方法について説明しています。 予期しないセッションロックと切断 これらの動作に関与するセッションタイムアウトポリシーを調査します。
適切に選択されたタイムアウト値は、セッションが無駄に残ることを防ぎ、リソースを占有することを防ぎます。しかし、過度に攻撃的なタイムアウトポリシーは、重要な操作が完了する前にセッションを終了させることで、生産的な作業セッションを破壊する可能性があります。
セッションタイムアウトポリシーはビジネス要件に基づくべきであり、根本的なセッションリークの治療法として使用されるべきではありません。
Windowsおよびセッション関連ソフトウェアを維持する
サポートされているWindows Serverの更新プログラムと特定の問題に対する修正を実装します。
エンドポイント保護エージェント、プロファイル管理コンポーネント、仮想化コンポーネント、およびセッション統合アプリケーションがオペレーティングシステムと互換性があることを確認してください。
更新を事前生産環境でテストしてください。特に、Windowsのログオンまたはセッションプロセスに複数のサードパーティコンポーネントが関与している場合は特に重要です。
容量とRDS構成の確認
現実的な同時作業負荷に応じてリモートデスクトップセッションホストのサイズを調整し、ログインおよびプログラム起動のピーク時間を考慮します。
複数のホスト間でセッションを分散させて、混雑を避けるために大規模な環境に対応することを検討してください。
グループポリシーの監査、接続制限、ライセンス設定およびメンテナンスの実践を定期的に行い、接続障害の潜在的な原因を発見し排除します。
シンプルなリモートデスクトップとアプリケーション配信をお探しですか?
リモートデスクトップサービスのトラブルシューティングは、Windowsアプリケーション配信環境を維持するために必要な管理作業を浮き彫りにすることがあります。主にユーザーにWindowsアプリケーションや完全なリモートデスクトップを提供する必要がある組織にとって、既存のインフラストラクチャの複雑さを見直すことは価値があるかもしれません。
TSplus リモートアクセス マルチユーザーWindowsアプリケーションの公開とリモートデスクトップ配信に対する効率的なアプローチを提供し、ブラウザベースのアクセスと中央管理を実現します。これにより、ITチームは従来のMicrosoft RDSインフラストラクチャの完全な複雑さを展開することなく、リモートユーザーにアプリケーションを利用可能にすることができますが、適切なWindows Serverのメンテナンスとセキュリティは依然として必要です。
結論
「リモートデスクトップサービスが現在ビジーです」というエラーは、単なるサーバーの再起動以上の対処が必要です。障害がセッションのスタック、リソースの制限、またはWindowsログオンの問題から発生しているかを特定することで、管理者は最も影響の少ない解決策を選択できます。
エラーが持続する場合や再発する場合、体系的な診断、パフォーマンス監視、構成レビューが根本的な原因を解決し、信頼性のあるRDP接続を維持するために不可欠です。
TSplus リモートアクセス 無料トライアル
デスクトップ/アプリアクセスのための究極のCitrix/RDS代替。安全で、コスト効果が高く、オンプレミス/クラウド