Quantcast
Channel: リモートデスクトップ | MacRuby
Viewing all 11 articles
Browse latest View live

ネットワークのMTUサイズを変更する方法

$
0
0

リモートデスクトップの表示で真っ黒な画面しか出てこなくなり、タイムアウトしてしまう場合など、

ネットワークのMTUサイズを変更する必要が生じる場合があります。

MTUサイズとは、ネットワークで送信可能なパケットの最大サイズのことです。

MTUサイズを超えたIPパケットは、ファイアーウォールでブロックされてしまう場合があります。

そのような時には、MTUサイズを調整する必要があります。


まず、レジストリエディターを開き、下記の項目を選択します。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces

\{interfaceGUID}


{interfaceGUID}は、ネットワークインターフェース毎に設定されている文字列です。

{interfaceGUID}を選択した状態で、【編集】→【新規】→【DWORD(32ビット)値】を新規追加します。

名前をMTUとし、値を10進数で指定します。(MTUサイズを1500byteにしたいなら、1500と入力します。)

MTUサイズの値として何byteを指定すればよいかは、ネットワークのMTUサイズを決定する方法を参考にしてください。

再起動すると、MTUサイズが変更されます。

こうして、ネットワークのMTUサイズを変更することができました。


ネットワークのMTUサイズを決定する方法

$
0
0

リモートデスクトップ接続で黒画面しか出てこず、タイムアウトしてしまう場合など、

MTUサイズを変更しなければならない場合があります。

そのような際に、MTUサイズの値をいくつに設定すればよいか、決定する方法です。


まず、接続するマシンのIPアドレスに、下記のようにpingを送信してみます。


ping -f -l 1472 -n 1 ***.***.***.***

-f:分割処理禁止指定
-l:送信するデータサイズ
-n:送信する回数


すると、ある値では成功し、ある値では失敗します。

1472byteでは成功

MTUサイズを決定する方法1

1473byteでは失敗

MTUサイズを決定する方法2

ですので、上記の場合の適正なMTUサイズは、成功した最大値である1472byteと、28byte(pingコマンドを打つ場合のIPヘッダとICMPヘッダの合計はいつも28byte)を足して、1500byteが適正なMTUサイズになります。

ちなみに、イーサネットのデフォルトのMTUサイズは、1500byteですので、今回は調整する必要がありませんでした。


イーサネットではなく、PPPoE接続の場合などは、さらにPPPoEヘッダのサイズを考慮しなければならないので、MTUサイズを、1454に調整してやると、ちょうどよいサイズになります。

もちろん、他にも様々な要因がありますので、上述した、pingでMTUサイズの上限を調べる方が確実だと思います。

こうして、ネットワークのMTUサイズを決定することができました。

MTUサイズを変更する方法はこちらの記事を参考にしてみて下さい。

リモートデスクトップで黒画面しか表示されない場合の対処方法

$
0
0

遠隔地のPCをリモートデスクトップ接続でつないでいる場合、

真っ黒な画面しか表示されなくなってしまう場合があります。


その場合は接続する際のオプションで、

【エクスペリエンス】のタブ内にある、

ビットマップのキャッシュを保持】のチェックを外します。

リモートデスクトップで黒画面しか表示されない場合の対処方法

これで接続すると、リモートデスクトップで真っ黒な画面しか表示されない不具合が解消される場合があります。


ちなみに、回線速度が遅い場合は帯域を非常に圧迫しますので、通常は【ビットマップのキャッシュを保持】にチェックを入れておくことをお勧めいたします。

ビットマップのキャッシュを保持すると、頻繁に利用されるイメージが、キャッシュとしてローカルに保存されるため、画面の描画速度が格段に速くなります。

サーバーのセキュリティ データベースにこのワークステーションの信頼関係に対するコンピュータ アカウントがありません

$
0
0

ドメイン環境において、

サーバーのセキュリティ データベースにこのワークステーションの信頼関係に対するコンピュータ アカウントがありません

というエラーが表示され、コンピューターにログインできない場合があります。


それは、ActiveDirectoryからコンピューターアカウントが消えていることが原因かもしれません。

同一名のコンピューターがActiveDirectoryに登録されたりすると、この問題が生じる可能性があります。


ですので、まずはドメインから一度抜けて、再度ドメイン参加することによって、正しくActiveDirectoryに登録され、ログインできるようになります。

こうして、【サーバーのセキュリティ データベースにこのワークステーションの信頼関係に対するコンピュータ アカウントがありません】というエラーを解消することができました。

サーバーにログオンしている全ユーザーを確認する方法

$
0
0

リモートデスクトップ機能を持たせたサーバーを管理している際などに、

現在、そのサーバーにログオンしているユーザーがいるのか、確認したい場合があります。


そのような場合には、コマンドプロンプトで下記のコマンドを入力することで、サーバーにログオンしている全ユーザーを確認できます。


query user /server:サーバー名


コマンドプロンプトからサーバーにログオンしている全ユーザーを確認する

こうして、サーバーに現在ログオンしている全ユーザーを確認することができました。

[XP]このコンピューターはリモートコンピューターに接続できません。

$
0
0

VMware上に作成したWindowsXPマシンに対して、リモートデスクトップ接続ができない場合があります。


下記のようなエラーを表示し、リモートデスクトップ接続が拒否されてしまいます。


このコンピューターはリモートコンピューターに接続できません。

ネットワークエラーが発生したため接続が失われました。接続を再試行してください。問題が解決しない場合は、ねっとわーく管理者またはテクニカルサポートに問い合わせてください。


Pingは通るのに、リモートデスクトップは接続できません。

また、Firewallの設定も、Remoto Desktop Userの権限にも問題がないように思える場合は、レジストリの破損を疑ってみる必要があります。


下記のレジストリの値を、一旦削除し、XPマシンを再起動することによって解決する場合があります。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\TermService\Parameters\Certificate

レジストリの値を一旦削除し、XPマシンを再起動する



ちなみに、このケースの症状としては、イベントビューアでシステムのログを見ると、TermDD(イベントID:50)という項目でエラーを吐いています。

下記のMicrosoftナレッジベースに近しい症状が乗せられています。
http://support.microsoft.com/kb/323497/



こうして、VMware上のWindowsXPマシンにおいて、リモートデスクトップ接続ができない状況を改善することができました。

リモートデスクトップ接続をコマンドで呼び出す方法とその略称の意味

$
0
0

Widnows XP Professionalから搭載されている機能の「リモートデスクトップ接続」。

Windows7では、【すべてのプログラム】>【アクセサリ】>【リモートデスクトップ接続】として呼び出せますが、

コマンドで呼び出す方法を覚えておくと便利です。


リモートデスクトップ接続をコマンドで呼び出すには、

【Windowsキー】を押して【プログラムとファイルの検索】から

mstsc

と入力することで、リモートデスクトップ接続を立ち上げることができます。




非常に覚えにくいコマンドなのですが、mstscとは何の略なのでしょうか。

これは、Microsoft Terminal Services Client の略称と考えられます。


リモートデスクトップ接続」は、以前は「ターミナルサービスクライアント」と呼ばれていましたので、その名残と考えられます。

これでコマンドが少し覚えやすくなるかもしれません。


こうして、リモートデスクトップ接続を、コマンドから呼び出すことができました。

マイクロソフト Surface Pro 256GB [Windowsタブレット・Office付き] H5W-00001
マイクロソフト Surface Pro 256GB [Windowsタブレット・Office付き] H5W-00001

RDS(リモートデスクトップ)でファイルのコピー&ペーストが効かない場合の対処法

$
0
0

Windows 2012 R2において,リモートデスクトップサーバーを構築した際,クライアントからファイルのコピー&ペーストができない場合があります。

テキストのコピー&ペーストは問題なくできるのに,ファイルのコピー&ペーストはできないという場合もあるでしょう。

そのような場合に確認すべき設定は以下の通りです。


リダイレクトを許可する設定がされているか


レジストリエディタを開き(スタートボタンを押してregedit.exe),以下のパスに遷移します。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

そして,次の2つの値を設定します。

fDisableCdmを0に設定
fDisableClipを0に設定

テキストしかコピーできなかった場合は,恐らくfDisableClipしか0になっていかなった場合でしょう。

fDisableCdmも0に設定することで,ドライブのリダイレクトも有効化する必要があります。



ちなみに,2008 R2までは,リモートデスクトップセッションホストの構成という画面で簡単に変更することができていました。

リモートデスクトップセッションホストの構成

リモートデスクトップセッションホストの構成




しかし,2012 R2になってからは,リモートデスクトップサーバーを構成する方法が多様化し,上図のような設定コンポーネントがインストールされず,手間取ってしまうかもしれません。

2012 R2にRDS機能を初期インストールする際にも上記のリダイレクトの設定を行うことができますが,後から変更するためには,レジストリを調整するのが手っ取り早いです。



クライアント側の設定で,クリップボードやドライブのリダイレクトを許可するように設定して接続しているか


クライアント側でリモートデスクトップ接続を行う画面において,クリップボードのリダイレクトを許可する設定にしているかどうかを確認してください。

クリップボードのリダイレクトを許可する設定

クリップボードのリダイレクトを許可する設定



詳細設定の「ドライブ」にはチェックを入れる必要はないようです。


他にも要素がありますが,今後アップデートしたいと思います。

RDS(リモートデスクトップ)でファイルのコピー&ペーストが効かない場合の対処法

$
0
0

Windows 2012 R2において,リモートデスクトップサーバーを構築した際,クライアントからファイルのコピー&ペーストができない場合があります。

テキストのコピー&ペーストは問題なくできるのに,ファイルのコピー&ペーストはできないという場合もあるでしょう。

そのような場合に確認すべき設定は以下の通りです。


リダイレクトを許可する設定がされているか


レジストリエディタを開き(スタートボタンを押してregedit.exe),以下のパスに遷移します。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

そして,次の2つの値を設定します。

fDisableCdmを0に設定
fDisableClipを0に設定

テキストしかコピーできなかった場合は,恐らくfDisableClipしか0になっていかなった場合でしょう。

fDisableCdmも0に設定することで,ドライブのリダイレクトも有効化する必要があります。



ちなみに,2008 R2までは,リモートデスクトップセッションホストの構成という画面で簡単に変更することができていました。

リモートデスクトップセッションホストの構成

リモートデスクトップセッションホストの構成




しかし,2012 R2になってからは,リモートデスクトップサーバーを構成する方法が多様化し,上図のような設定コンポーネントがインストールされず,手間取ってしまうかもしれません。

2012 R2にRDS機能を初期インストールする際にも上記のリダイレクトの設定を行うことができますが,後から変更するためには,レジストリを調整するのが手っ取り早いです。



クライアント側の設定で,クリップボードやドライブのリダイレクトを許可するように設定して接続しているか


クライアント側でリモートデスクトップ接続を行う画面において,クリップボードのリダイレクトを許可する設定にしているかどうかを確認してください。

クリップボードのリダイレクトを許可する設定

クリップボードのリダイレクトを許可する設定



詳細設定の「ドライブ」にはチェックを入れる必要はないようです。


他にも要素がありますが,今後アップデートしたいと思います。

RDS上のPDF-XChangeを使うとマウスカーソルが消えてしまう場合の対処法

$
0
0

フリーで多機能なPDF-XChange Viewerですが,使っておられる方も多くおられるでしょうか。

もちろんこのソフトに限らずなのですが,リモートデスクトップサーバー(RDS)上で使用している際,マウスカーソルが消えてしまうというバグに気づくことがあります。


どんな場合にマウスカーソルが消えてしまうか


どんな時にマウスカーソルが消えてしまうかというと,通常のマウスのカーソル形状ではない場合です。

つまり,ソフトウェア固有のカーソル形状になった場合に,カーソルが消えてしまいます。

例えば,下図のようなカーソルです。

Windows のデフォルトのカーソルではないカーソル形状の時に消えてしまう

Windows のデフォルトのカーソルではないカーソル形状の時に消えてしまう


実は,このRDSでカーソル情報を転送する仕組みというのは少し複雑なことを行っています。

もし,リモート上にあるマウスの描画をそのままRDS越しに転送してしまうとすると,マウスを動かすたびに,多くのトラフィックが流れてしまうことになるため,マウスの座標情報と,カーソルの形状の情報をRDSからクライアントに対して渡しています。

しかし,アプリケーションが固有のカーソル形状を利用しようと思った時に,そのカーソルの情報をうまくクライアントに渡すことができずカーソルが消えてしまうという症状につながります。


ではRDSで特定のアプリのカーソルが消える場合にはどうすればよいか


まずは,同様の環境で他のサーバーでも起こるのかどうかを確認してみましょう。

正常に動いているRDSがあるなら,インストールされているアプリケーションのバージョンも比較して確認してみます。

インストール日にも注目しましょう。なぜなら,複数のサーバーを管理している場合,一斉にソフトウェアのアップデートがかかり,同時に不具合が発生することもあるからです。

それで,他のサーバーで起こっていたとしても,仕様としてあきらめる必要はありません。

その後,ソフトウェアの修復を試みてみましょう。

プログラムと機能から,修復を選択します。OSとソフトウェアの関連付けの部分で不具合が起きている場合もありますので,この方法は有効です。

再起動不要で問題が解消する場合もありますが,解消しない場合には,サーバーを再起動してみましょう。


以上,RDS上のPDF-XChangeでマウスカーソルが消えてしまった場合の一つの対処法でした。

CredSSPのエラーでリモートデスクトップ接続ができない場合の対処法

$
0
0

新規構築したサーバーなどにリモートデスクトップ接続を試みると,以下のようなCredSSPのエラーが出て,RDP接続が拒否される場合があります。

CredSSPのエラーが出てリモートデスクトップ接続できない。

CredSSPのエラーが出てリモートデスクトップ接続できない。

An authentication error has occurred.
The function requested is not supported
Remote computer: SERVER NAME
This could be due to CredSSP encryption oracle remediation.
For more information, see https://go.microsoft.com/fwlink/?linkid=866660

このような場合には,どうしたら良いのでしょうか。

CredSSPの脆弱性対策パッチを適用する

以下のURLで,CredSSPの脆弱性に対するパッチが公開されていますので,必要なファイルをダウンロードしましょう。

表の中から該当のOSを選択し,Security Updateのリンクをクリックします。

表の中から該当のOSを選択し,Security Updateのリンクをクリックする。

表の中から該当のOSを選択し,Security Updateのリンクをクリックする。

そして,再び該当のOSを探し,ダウンロードボタンをクリックします。
サイズは,1GBを超える場合もありますので,辛抱強く待ちましょう。

再び該当のOSを探し,ダウンロードボタンを押す

再び該当のOSを探し,ダウンロードボタンを押す

ダウンロードが完了したら,そのパッチをリモートデスクトップ接続できないサーバーにコピーし,インストールします。

Windows 2016の場合には,パッチの名前はKB4103723です。

Windows 2016の場合,CredSSPのパッチはKB4103723。

Windows 2016の場合,CredSSPのパッチはKB4103723。

インストール後は再起動が求められます。

CredSSPのパッチを当てた後には再起動が求められる。

CredSSPのパッチを当てた後には再起動が求められる。

パッチをあてて再起動した後,サーバーがハングしているように見える場合がありますが,強制終了しないようにしましょう。かなり大きなアップデートなので,5分ぐらい放置する必要がある場合もあります。

もし強制終了させてしまったなら,再度パッチをあてなおす必要があります。

これで,再びリモートデスクトップ接続ができるかどうか試してみてください。恐らく,CredSSPの脆弱性によるエラーは現れなくなるはずです。

CredSSPの脆弱性とは何なのか

では,CredSSPの脆弱性とは実際にはどのようなものなのでしょうか。

CredSSPとは,Credential Security Support Provider (CredSSP) プロトコルのことで,他のアプリケーションの認証要求を処理してくれるプロバイダーです。

この認証要求プロトコルに脆弱性があるため,ユーザーの資格情報を悪用させる危険性があり,その資格情報を使ってリモートから悪意のあるコードを実行される場合があるということです。

この脆弱性がリモートデスクトップ接続に影響を及ぼす理由というのも,そこから説明できます。

つまり,RDP接続でもCredSSPを利用して認証要求を行っているため,そこで使用される資格情報を中間者攻撃によって悪用される危険性があるということです。

それで,上述したパッチを適用することで,CredSSPプロトコルがリクエストを検証する方法がさらにセキュアなものになり,中間者攻撃ができないように修正されます。

以上,CredSSPにおける脆弱性の話と,CredSSPのエラーが出てリモートデスクトップ接続ができない場合の対処法でした。

Viewing all 11 articles
Browse latest View live