)ではパケットが失われることはほとんど発生しないため、UDPを使った方がパフォーマンス(レスポンス)が良いことがあるのでしょう。デフォルト値を変更したということは忘れずに、状況に応じて切り換えて運用してみてください。 VPN越しにリモートデスクトップを使用する場合できるだけネットワークを安定させるため、無線よりも有線LANを使うことをオススメしておきます。ノートPCに有線LANがない場合はUSBイーサネットアダプタで追加できます。 古いLANケーブルを使っていると速度が出ないことがあります。ギガビット(1GbEや10GbE)に対応した品質の良いケーブルを使いましょう。カテゴリー5e(CAT5e)以上のケーブルが目印です。 他にもリモートデスクトップ関連の記事をいくつか書いているので参考にしてみてください。 ぼくです。働き方改革でテレワーク(リモートワーク、WFH)でリモートデスクトップ接続(RDP)する機会が増えてきました。windowsの更... こんにちは、ぼくです。以前のエントリで Chrome リモートデスクトップ を使って、いつでもどこでもマイニングPCの様子が見られるように...
前回のあらすじ。 リモートデスクトップ接続10台数珠接続をなんなくクリアしたわたしは、意気揚々と上司モナイさんに報告するも、「少なくない?」のひと声で、もっと多くの台数でやってみることに。 前回の記事はこちら。 リモートデスクトップ接続に限界はあるの?を実際にやってみた こんにちは、お久しぶりです。 かんたんです。 さて今回は、前回の続きということで、もっと多くの台数に接続できるのか調査してみることとなりました。 そのためにご用意したPCの台数は…。なんと…! 30台です。 どどーんと! これはすごい、これはすごいです。壮観という言葉がまさにピッタリです。 ご家庭ではなかなか見ることのできない景色が広がっています。 15台の地点に、セロハンテープを置いています。 そして、 前回 の反省を生かし、酔い止めも用意しています。 酔ってからでも効くのがうれしいですね。 さらに、酔った原因は壁紙の模様にもあると考え、壁紙をなし(真っ黒)にして準備万端です。 それでは限界に挑みます 10台までは前回やりましたので、なんなく(本当は、8台目くらいから重いなーと思っていたことは内緒にしておきます)接続できました。 全然酔いませんし、酔い止めのおかげです。 さて…、ここからは未知の領域です。 11台…、12台…。おお、いけるいける。 13台目に行こうとしたその時でした…! コンピューターを検出できないとのエラーが!まさか早くも限界が訪れたのか…!? と思ったら、リモートされる側のコンピューター名の設定を間違っていました(てへぺろ 気を取り直していこうと思ったんですが、どうにもこうにも重い。ものすごくラグがある。 まるで紙芝居のような状態になってきました。 紙芝居の様子を、ノーカットでお送りします。右側のスクロールバーにご注目ください。 画面スクロールをしただけなのにもかかわらず、このラグ…。 左下のCPU使用率が跳ね上がっています。 そろそろ限界が近いのかもしれません。 でもまったく酔ってはいません。酔い止めを買っておいてよかった。 14台…、15台…、16台…。 限界が近いと思いましたが、重いもののまだいけそうな雰囲気もあります。20台はいけそうな予感です。 それでは17台目に。 あれ? 「接続が失われました。セッションに再接続中…」の文字がっ!
Internet VPN経由なら、接続品質自体が怪しいような気もしますが…。 ping応答を返す適当なinternet siteに-tオプションつけてpingを継続的に打ってみて、remote desktopが切れた時に同時に応答性が低下していないか見てみるとか? ネットワーク管理者に、拠点のインターネットゲートウェイやデータセンタのVPNサーバのログを確認してもらうのも有用かと。 あと、意外と、VPNサーバや本社側インターネットゲートウェイで、セッションタイムアウトが設定されていた、というオチもありがちかと存じます。 ご参考になれば幸いです。 早く解決するといいですね。 2 ユーザーがこの回答を役に立ったと思いました。 · この回答が役に立ちましたか? 役に立ちませんでした。 素晴らしい! フィードバックをありがとうございました。 この回答にどの程度満足ですか? フィードバックをありがとうございました。おかげで、サイトの改善に役立ちます。 フィードバックをありがとうございました。 早速のお返事ありがとうございます! その頻繁接続切断のクライアントがある拠点では全部で12台、VPNで同じサーバーにリモートデスクトップで接続して同じシステムを使っているのですが、この1台だけが切断再接続を繰り返すのです。ライセンスはきちんと用意しています。 そうなるとこの個体の問題なんではないか、と思うのですが、何が悪いのか… そしてサーバーもに、このクライアントにも、イベント確認しても何の痕跡もないのです。エラーの記録があればまだよかったのですが。 切断しているときに、サーバーにping飛ばしてみようと思うのですが、操作ができないので、それも出来ず。 ちなみにこのサーバーはシステムが入っているだけのVPN拠点用の第2サーバーで、システムを運用するためのデータは別のサーバーに入っております。 セッションタイムアウト、それを確認してみます。 どうもありがとうございました。 VPN/remote desktopのuser accountは端末ごとですか? であれば、VPNのsession timeout/Remote Desktop serverのsession timeoutは確認する価値ありですね。 (ただ、Remote Desktop Serviceでの切断であれば、明示的にserverから切断された、といわれる気がしますので、個人的には、やはりnetwork levelの問題だと思います。) あとは、LANの回線品質も疑う必要がありますかね。 有線LANであれば、OKな端末のLAN cableに差し替えて、問題が移動するかどうか。 pingについては、以下のような を > という形でファイルにリダイレクトするよう仕込んでおいて、問題発生後、回収して確認すれば良いと思います。 @echo off:start ping nodename -n 2 echo%time% goto:start 対象は、VPNの先のserverよりは、LANのgatewayを最初は指定しておくべきかも。 1 人がこの回答を役に立ったと思いました。 →はい、そうです。 →やはり、セッションタイムアウトですか。確認してみます。 →なるほど、LANケーブルは変えてみましたが、OKな端末のものと変えてみる、それは早速明日、試してみます。 →このような方法を知りませんでした。これも早速明日、やってみます。 フィードバックをありがとうございました。