none
リモートデスクトップ接続について RRS feed

 > 

  • 質問

  • Question
    サインインして投票
    0
    サインインして投票

    以下の環境で、リモートデスクトップ接続が、「たまに」接続できます。
    接続できた場合でも、数分で切断されます。
    切断された場合、「たまに」再接続できます。ほとんど２０回試行後キャンセルされます。
    安定的に接続できるようにしたいので、ご教示いただきたい次第です。


    クライアント：Windows7 Professional SP1
    ホスト：WindowsServer2016(AD/DNSサーバ)
    ネットワーク：同一LANセグメント


    クライアント側エラーダイアログ：
    ----------
    このコンピュータはリモート コンピューターに接続できません。
    接続を再試行してください。問題が解決しない場合は、リモート コンピューターの
    所有者またはネットワーク管理者に問い合わせてください。
    ----------

    もしくは

    ----------
    リモート デスクトップはリモート コンピューターに接続できません。次のいずれかが原
    因です。
    1) サーバーへのリモート アクセスが有効にされていない
    2) リモート コンピューターの電源が入っていない
    3) リモート コンピューターがネットワークで使用できない
    リモート コンピューターの電源が入っていること、ネットワークに接続されていること、
    リモート アクセスが有効になっていることを確認してください。
    ----------

    ホスト側イベント（イベント ビューアー (ローカル) ＞ アプリケーションとサービスログ ＞ Microsoft ＞ Windows ＞ RemoteDesktopServices-RdpCoreTS） ＞ Operational：
    ※エラー及び警告のみ抽出
    ----------
    ログの名前:         Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational
    ソース:           Microsoft-Windows-RemoteDesktopServices-RdpCoreTS
    日付:            2017/02/01 11:48:51
    イベント ID:       142
    タスクのカテゴリ:      RemoteFX モジュール
    レベル:           警告
    キーワード:        
    ユーザー:          NETWORK SERVICE
    コンピューター:       Localdc1.n-parts.local
    説明:
    TCP ソケットの読み取り操作が失敗しました (エラー 121)
    イベント XML:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-RemoteDesktopServices-RdpCoreTS" Guid="{1139C61B-B549-4251-8ED3-27250A1EDEC8}" />
        <EventID>142</EventID>
        <Version>0</Version>
        <Level>3</Level>
        <Task>4</Task>
        <Opcode>15</Opcode>
        <Keywords>0x4000000000000000</Keywords>
        <TimeCreated SystemTime="2017-02-01T02:48:51.689893800Z" />
        <EventRecordID>3840</EventRecordID>
        <Correlation ActivityID="{F4202D54-EC3C-4DC0-8F92-5852A0470000}" />
        <Execution ProcessID="268" ThreadID="4372" />
        <Channel>Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational</Channel>
        <Computer>Localdc1.n-parts.local</Computer>
        <Security UserID="S-1-5-20" />
      </System>
      <EventData>
        <Data Name="error">121</Data>
      </EventData>
    </Event>
    ----------
    ログの名前:         Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational
    ソース:           Microsoft-Windows-RemoteDesktopServices-RdpCoreTS
    日付:            2017/02/01 11:48:51
    イベント ID:       143
    タスクのカテゴリ:      RemoteFX モジュール
    レベル:           警告
    キーワード:        
    ユーザー:          NETWORK SERVICE
    コンピューター:       Localdc1.n-parts.local
    説明:
    TCP ソケットの書き込み操作が失敗しました (エラー 121)
    イベント XML:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-RemoteDesktopServices-RdpCoreTS" Guid="{1139C61B-B549-4251-8ED3-27250A1EDEC8}" />
        <EventID>143</EventID>
        <Version>0</Version>
        <Level>3</Level>
        <Task>4</Task>
        <Opcode>15</Opcode>
        <Keywords>0x4000000000000000</Keywords>
        <TimeCreated SystemTime="2017-02-01T02:48:51.689899600Z" />
        <EventRecordID>3841</EventRecordID>
        <Correlation ActivityID="{F4202D54-EC3C-4DC0-8F92-5852A0470000}" />
        <Execution ProcessID="268" ThreadID="4172" />
        <Channel>Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational</Channel>
        <Computer>Localdc1.n-parts.local</Computer>
        <Security UserID="S-1-5-20" />
      </System>
      <EventData>
        <Data Name="error">121</Data>
      </EventData>
    </Event>
    ----------
    ログの名前:         Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational
    ソース:           Microsoft-Windows-RemoteDesktopServices-RdpCoreTS
    日付:            2017/02/01 11:48:51
    イベント ID:       226
    タスクのカテゴリ:      RemoteFX モジュール
    レベル:           警告
    キーワード:        
    ユーザー:          NETWORK SERVICE
    コンピューター:       Localdc1.n-parts.local
    説明:
    RDP_TCP: Event_Disconnect に応答して StateUnknown から移行するときにエラーが発生しました (エラー コード 0x80070079)。
    イベント XML:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-RemoteDesktopServices-RdpCoreTS" Guid="{1139C61B-B549-4251-8ED3-27250A1EDEC8}" />
        <EventID>226</EventID>
        <Version>0</Version>
        <Level>3</Level>
        <Task>4</Task>
        <Opcode>19</Opcode>
        <Keywords>0x4000000000000000</Keywords>
        <TimeCreated SystemTime="2017-02-01T02:48:51.689911200Z" />
        <EventRecordID>3842</EventRecordID>
        <Correlation ActivityID="{F4202D54-EC3C-4DC0-8F92-5852A0470000}" />
        <Execution ProcessID="268" ThreadID="4372" />
        <Channel>Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational</Channel>
        <Computer>Localdc1.n-parts.local</Computer>
        <Security UserID="S-1-5-20" />
      </System>
      <EventData>
        <Data Name="StateTransition">RDP_TCP</Data>
        <Data Name="PreviousState">23</Data>
        <Data Name="PreviousStateName">StateUnknown</Data>
        <Data Name="NewState">21</Data>
        <Data Name="NewStateName">StateDisconnected</Data>
        <Data Name="Event">43</Data>
        <Data Name="EventName">Event_Disconnect</Data>
        <Data Name="ErrorCode">0x80070079</Data>
      </EventData>
    </Event>
    ----------
    ログの名前:         Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational
    ソース:           Microsoft-Windows-RemoteDesktopServices-RdpCoreTS
    日付:            2017/02/01 11:48:51
    イベント ID:       228
    タスクのカテゴリ:      RemoteFX モジュール
    レベル:           警告
    キーワード:        
    ユーザー:          NETWORK SERVICE
    コンピューター:       Localdc1.n-parts.local
    説明:
    トレースの切断: CUMRDPConnection Disconnect trace:'calling spGfxPlugin->PreDisconnect()' in CUMRDPConnection::PreDisconnect at 4477 err=[0x0]、エラー コード: 0x0
    イベント XML:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-RemoteDesktopServices-RdpCoreTS" Guid="{1139C61B-B549-4251-8ED3-27250A1EDEC8}" />
        <EventID>228</EventID>
        <Version>0</Version>
        <Level>3</Level>
        <Task>4</Task>
        <Opcode>19</Opcode>
        <Keywords>0x4000000000000000</Keywords>
        <TimeCreated SystemTime="2017-02-01T02:48:51.791486300Z" />
        <EventRecordID>3854</EventRecordID>
        <Correlation ActivityID="{F4202D54-EC3C-4DC0-8F92-5852A0470000}" />
        <Execution ProcessID="268" ThreadID="4172" />
        <Channel>Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational</Channel>
        <Computer>Localdc1.n-parts.local</Computer>
        <Security UserID="S-1-5-20" />
      </System>
      <EventData>
        <Data Name="ComponentName">CUMRDPConnection</Data>
        <Data Name="Message">Disconnect trace:'calling spGfxPlugin-&gt;PreDisconnect()' in CUMRDPConnection::PreDisconnect at 4477 err=[0x0]</Data>
        <Data Name="ErrorCode">0</Data>
      </EventData>
    </Event>
    ----------
    ログの名前:         Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational
    ソース:           Microsoft-Windows-RemoteDesktopServices-RdpCoreTS
    日付:            2017/02/01 11:49:25
    イベント ID:       101
    タスクのカテゴリ:      RemoteFX モジュール
    レベル:           警告
    キーワード:        
    ユーザー:          NETWORK SERVICE
    コンピューター:       Localdc1.n-parts.local
    説明:
    Reason Code: 2(Server Configuration). のため、ネットワーク特性の検出機能が無効になりました。
    イベント XML:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-RemoteDesktopServices-RdpCoreTS" Guid="{1139C61B-B549-4251-8ED3-27250A1EDEC8}" />
        <EventID>101</EventID>
        <Version>0</Version>
        <Level>3</Level>
        <Task>4</Task>
        <Opcode>16</Opcode>
        <Keywords>0x4000000000000000</Keywords>
        <TimeCreated SystemTime="2017-02-01T02:49:25.713755700Z" />
        <EventRecordID>3869</EventRecordID>
        <Correlation ActivityID="{F420AB8B-7BC4-43BC-8B94-5FC0F8CC0000}" />
        <Execution ProcessID="268" ThreadID="4564" />
        <Channel>Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational</Channel>
        <Computer>Localdc1.n-parts.local</Computer>
        <Security UserID="S-1-5-20" />
      </System>
      <EventData>
        <Data Name="ReasonString">Reason Code: 2(Server Configuration).</Data>
      </EventData>
    </Event>
    ----------
    ログの名前:         Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational
    ソース:           Microsoft-Windows-RemoteDesktopServices-RdpCoreTS
    日付:            2017/02/01 11:49:25
    イベント ID:       101
    タスクのカテゴリ:      RemoteFX モジュール
    レベル:           警告
    キーワード:        
    ユーザー:          NETWORK SERVICE
    コンピューター:       Localdc1.n-parts.local
    説明:
    Reason Code: 1(Client not supported). のため、ネットワーク特性の検出機能が無効になりました。
    イベント XML:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-RemoteDesktopServices-RdpCoreTS" Guid="{1139C61B-B549-4251-8ED3-27250A1EDEC8}" />
        <EventID>101</EventID>
        <Version>0</Version>
        <Level>3</Level>
        <Task>4</Task>
        <Opcode>16</Opcode>
        <Keywords>0x4000000000000000</Keywords>
        <TimeCreated SystemTime="2017-02-01T02:49:25.713957800Z" />
        <EventRecordID>3880</EventRecordID>
        <Correlation ActivityID="{F420AB8B-7BC4-43BC-8B94-5FC0F8CC0000}" />
        <Execution ProcessID="268" ThreadID="1316" />
        <Channel>Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational</Channel>
        <Computer>Localdc1.n-parts.local</Computer>
        <Security UserID="S-1-5-20" />
      </System>
      <EventData>
        <Data Name="ReasonString">Reason Code: 1(Client not supported).</Data>
      </EventData>
    </Event>
    ----------
    ログの名前:         Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational
    ソース:           Microsoft-Windows-RemoteDesktopServices-RdpCoreTS
    日付:            2017/02/01 11:49:26
    イベント ID:       227
    タスクのカテゴリ:      RemoteFX モジュール
    レベル:           エラー
    キーワード:        
    ユーザー:          NETWORK SERVICE
    コンピューター:       ***.local
    説明:
    'Failed CreateVirtualChannel call on this Connections Stack' in CUMRDPConnection::CreateVirtualChannel at 2349 err=[0xd0000034]
    イベント XML:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-RemoteDesktopServices-RdpCoreTS" Guid="{1139C61B-B549-4251-8ED3-27250A1EDEC8}" />
        <EventID>227</EventID>
        <Version>0</Version>
        <Level>2</Level>
        <Task>4</Task>
        <Opcode>19</Opcode>
        <Keywords>0x4000000000000000</Keywords>
        <TimeCreated SystemTime="2017-02-01T02:49:26.729798200Z" />
        <EventRecordID>3933</EventRecordID>
        <Correlation ActivityID="{F420AB8B-7BC4-43BC-8B94-5FC0F8CC0000}" />
        <Execution ProcessID="268" ThreadID="4172" />
        <Channel>Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational</Channel>
        <Computer>***.local</Computer>
        <Security UserID="S-1-5-20" />
      </System>
      <EventData>
        <Data Name="Name">CUMRDPConnection</Data>
        <Data Name="Value">3489660980</Data>
        <Data Name="CustomLevel">'Failed CreateVirtualChannel call on this Connections Stack' in CUMRDPConnection::CreateVirtualChannel at 2349 err=[0xd0000034]</Data>
      </EventData>
    </Event>
    ----------

    以上、よろしくお願いいたします。

    2017年2月1日 3:58
    |

回答

  • Question
    サインインして投票
    1
    サインインして投票

    すごく基本的なこと、かつ再確認になってしまうと思いますが、192.168.1.1の端末が他にありませんか？
    例えばルーターとか。。。

    クライアントPCでARPコマンドなどで意図したMACアドレスが取得できるかなど改めて確認されたほうが良いと思います。

    • 回答としてマーク npcSystem 2017年2月13日 3:00
    2017年2月9日 8:33
    |
  • Question
    サインインして投票
    1
    サインインして投票

    私もIPアドレスじゃなくてMACアドレスをチェックした方が良いと思いますね。

    WiresharkやMicrosoft Message Analyzerその他のパケットキャプチャ出来るツールで解析されているのですよね?

    RSTが出ている前後の応答やその時のMACアドレスをちゃんと見た方が良いのでは?

    あと、キャプチャしている端末と問題の通信をしている端末が同じだと正確なモニタが出来ないので、モニタポート付きのスイッチに別の端末を繋いで見た方が良いですね
    • 編集済み tmori3y2 2017年2月9日 10:54
    • 回答としてマーク npcSystem 2017年2月13日 3:00
    2017年2月9日 10:50
    |
  • Question
    サインインして投票
    1
    サインインして投票


    ところで、MACアドレスはベンダーIDで始まり、残りはベンダーで固有のIDを割り当てます。

    NICベンダーの場合もあるのですが、仮想環境の場合は仮想環境固有のベンダーIDになります。

    仮想的なものでない場合に、今回のように連番になるのは同じロットのハードウェアを調達した時ぐらいなもんで、普通は仮想デバイスか、同じサーバに刺さっている複数のNICじゃないか？と思ってしまいます。

    ベンダーIDは、WiresharkやMicrosoft Message Analyzerなどで表示させることができるほか、IEEEのサイトでも検索できます。

    https://regauth.standards.ieee.org/standards-ra-web/pub/view.html#registries

    このベンダーIDで絞りこむ方法で特定できる場合もあります

    例えば、All MACで00DBDFで検索するとIntel Corporateという風にわかります。

    Hyper-VでMicrosoft Hyper-V Network Adapterの00155Dとかだと、Microsoft Corporationです。

    ちなみに、大きな会社だと複数のIDを割り当ててもらっているので、この値以外でもIntelやMicrosoftに該当する場合もあります。

    どちらにしても、同じ物理サーバのNICの3つのMACアドレス、同じ仮想サーバの3つの仮想スイッチのどちらかのパターンが濃厚かと思います。
    2017年2月10日 9:36
    |
  • Question
    サインインして投票
    0
    サインインして投票

    tmori3y2様、ご返信ありがとうございます。

    いただいた情報を元に対応した結果、事象は解決いたしました。

    環境：Dell T130サーバ
    iDrac8のネットワーク設定：NIC1：192.168.1.1（xx-xx-xx-xx-xx-F5）
    WindowsServerでのNIC1の設定　 ：192.168.1.1（xx-xx-xx-xx-xx-F3）

    原因：IPアドレスの重複

    真因：iDrac8についての理解不足

    対応：iDrac8に設定するIPアドレスを変更


    iDrac8について良く理解せずに、Windowsで設定したIPアドレスと
    同一のIPアドレスを設定したことでIPアドレスの重複が発生したことが
    今回の事象の原因でした。原因が分かったので対応ができました。


    皆様にご協力いただいたおかげで、原因特定と、問題解決することができました。
    どうもありがとうございました。

    • 回答としてマーク npcSystem 2017年2月13日 3:00
    2017年2月13日 2:59
    |

すべての返信

  • Question
    サインインして投票
    0
    サインインして投票

    こんにちは。

    経験則からいうとネットワークの問題ではありませんか？

    FW の設定等をご確認されたほうがいいのではないかと思いました。

    Azure IaaS ならば FW と併せて NSG の設定をご確認されてみてはいかがでしょうか。

    コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。

    2017年2月1日 5:12
    |
  • Question
    サインインして投票
    0
    サインインして投票

    miyamam様
    ご回答ありがとうございます。

    サーバはオンプレミスで設置してあります。物理サーバ（仮想サーバではない）です。
    また、クライアントからサーバ間のネットワーク経路上に存在するネットワーク機器はスイッチングハブのみです。
    ルータもFWも経由しません。NSGも関係ないかと思っております。
    FWとはウィンドウズファイアウォールのことでしょうか？

    以上、よろしくお願いいたします。

    2017年2月1日 5:26
    |
  • Question
    サインインして投票
    0
    サインインして投票

    こんにちは。

    この構成の場合、ウィンドウズファイアウォールの設定はご確認されましたか？

    OSの機能以外でも、セキュリティソフトのパーソナルファイアウォール機能が通信を妨げているケースも少なくありません。

    初歩的な確認となりますが、スイッチングハブの結線及びリンクアップはしていますか。

    コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。

    2017年2月3日 5:51
    |
  • Question
    サインインして投票
    0
    サインインして投票

    miyamam様
    ご回答ありがとうございます。

    ウィンドウズファイアウォール及びセキュリティソフトを無効にした状態で
    試行しましたが、状態は改善されませんでした。

    また、スイッチングハブの結線及びリンクアップはしています。
    (pingに対してはリモートデスクトップ接続が繋がらない状態でも安定的に応答があります)

    追加の情報としまして、
    ファイル名を指定して実行より、\\[IPアドレス] を開こうとした際に、以下のメッセージボックスが表示されます

    ----------
    \\[IPアドレス]にアクセスできません
    名前のスペルを確認しても問題がない場合は、ネットワークに】問題がある可能性があります。ネットワークの問
    題を識別して解決するには、[診断]をクリックします。
    ----------

    そこで、診断ボタンをクリックしたところ、見つかった問題として以下の内容が表示されます

    ----------
    リモートデバイスまたはリソースが接続を受け付けません
    ----------

    リモートデスクトップ接続ができる場合 \\[IPアドレス] で共有フォルダが開けます
    リモートデスクトップ接続ができない場合、\\[IPアドレス] で共有フォルダが開けません
    Pingに対しての応答はリモートデスクトップ接続ができない場合でもかえってきます。

    以上、よろしくお願いいたします。

    2017年2月6日 5:13
    |
  • Question
    サインインして投票
    0
    サインインして投票

    基本的な事ですが、IPアドレスの重複やサブネットマスクの設定ミスはありませんか?(クライアント, サーバいづれか)

    他に怪しそうなのは、スタンバイモードのあるOA機器との重複など。固定アドレスでDHCPサーバで除外していないとか。

    たまにウェイクアップしてpingは通っても\\ipでは繋がらないのではないでしょうか?

    2017年2月6日 11:10
    |
  • Question
    サインインして投票
    0
    サインインして投票

    念のためですが、Client,Server ともに最新のパッチが当たっているという前提で大丈夫ですよね？
    一応、クライアント側のリモートデスクトップ接続（mstsc) のバージョン情報を確認していただければと。
    最新同士の接続でエラーが起きるのであれば私もネットワーク関連を疑いますが、Client,Server ともにNICの状態も気になります。
    どのようなNICを使っていて、チーミングの有無など。。。
    もしチーミングをしているのであれば外してみて確認するなど、極力シンプルなネットワーク構成にして確認してみてはいかがでしょうか。

    2017年2月6日 17:19
    |
  • Question
    サインインして投票
    0
    サインインして投票

    tmori3y2様、snow--snow様、ご返信ありがとうございます。

    ご指摘いただいた下記内容確認いたしました。

    IPアドレスの重複やサブネットマスクの設定ミス
    →サーバ、クライアントとも再確認しましたが問題ありませんでした。

    スタンバイモードのあるOA機器との重複など。固定アドレスでDHCPサーバで除外していない
    →ＩＰアドレスの重複はありませんでした。
    ※サーバはWindowsServer2003からリプレイス。コンピュータ名及びIPアドレスは引継（同一）。
    　旧サーバは電源断、ネットワークケーブルも抜いてある。旧サーバでは問題なし。
    　新旧サーバ入替後にＬＡＮに新規接続機器なし。

    クライアント側のリモートデスクトップ接続（mstsc) のバージョン情報
    →最新のバージョンではなかったので、RDP8.1サポートのバージョンに更新しました。
    　6.3.9600 にて試行しましたが、状態は改善されませんでした。

    どのようなNICを使っていて、チーミングの有無など
    →サーバ側でチーミングは行って（設定して）いません。
    　以下、サーバ側のネットワークアダプタの状態です。

    Broadcom NetXtreme Gigabit Ethernetのプロパティ＞詳細設定
    802.3az EEE(Copper Only)：Disable
    ARP Offload：Enabled
    EEE Control Policies(Copper Only)：Optimal Powe and Perfomance
    Ethernet@WireSpeed(Copper Only)：Enabled
    Flow Control：Auto Negotiation
    Interrupt Moderation：Enabled
    Jumbo Mtu：1500
    Large Send Offload V2(IPv4)：Enabled
    Large Send Offload V2(IPv6)：Enabled
    Maximum Number of RSS Queues：RSS 4 Queues
    Network Address：存在しない
    NS Offload：Enabled
    Priority & VLAN：Priority & VLAN Enabled
    Receive Buffers：Default
    Receive Side Scaling：Enabled
    Speed & Duplex(Copper Only)：Auto Negotiation
    TCP/UDP Checksum Offload(IPv4)：Rx & Tx Enabled
    TCP/UDP Checksum Offload(IPv6)：Rx & Tx Enabled
    Transmit Buffers：500
    Virtual Machine Queues：Disabled
    VLAN ID：0
    Wake on Magic Packet：Enabled
    Wake on Pattern Match：Enabled
    WOL Speed(Copper Only)：Lowest Speed Advertised


    何かお気づきの点がありましたら、ご意見いただけると助かります。
    以上、よろしくお願いいたします。

    2017年2月7日 1:17
    |
  • Question
    サインインして投票
    0
    サインインして投票

    地道な解析が必要になりそうな雰囲気ですが、
    ・ほかのクライアントPCから接続して問題が再現するかどうか確認
    ・サーバー/クライアントそれぞれ、NICの Large Send Offload をはじめとするOffload系をDisableにしてみる
    ・サーバー/クライアントそれぞれ。NICのドライバを最新に更新する

    ・念のため、クライアント更新後に問題が発生した際のサーバーイベントログを際確認
    ・念のため、サーバー側のイベントログで アプリケーションとサービスログ/Microsoft/Windows/Microsoft-WIndows-TerminalServices-LocalSessionManager/Operational の中にセッション切断時の理由コードが出ていると思うので確認

    といったところでしょうか

    2017年2月7日 4:21
    |
  • Question
    サインインして投票
    0
    サインインして投票

    snow--snow様、ご返信ありがとうございます。

    状況に変化がありました。

     リモートデスクトップ接続が、「たまに」接続できます。
     →この状況は継続しております。

     接続できた場合でも、数分で切断されます。
     切断された場合、「たまに」再接続できます。ほとんど２０回試行後キャンセルされます。
     →接続後に切断されることはなくなりました。

     安定的に接続できるようにしたいので、ご教示いただきたい次第です。

    ほかのクライアントＰＣからも現象は再現しております。
    また、リモートデスクトップ接続に限ったことではなく、
    TCP通信全般に関して、接続できたりできなかったりという状況のようです。
    （いくつかのLISTENINGポートに対して接続テストを行った結果）。

    接続できる場合は、ほかの開いているポートにも接続できるし、
    接続できない場合は、ほかの開いているはずのポートにも接続できない
    (SYN+RSTパケットが返ってくる)、
    TCP接続できない場合でも、PING応答は返ってくるので、
    IP通信は問題ないかと思います。

    また、あるクライアントＰＣから接続できる場合でも、別のあるクライアントＰＣからは接続できない状態ということがあることも確認しております。

    何かお気づきの点がありましたら、またご意見いただけると助かります。
    以上、よろしくお願いいたします。

    2017年2月9日 2:41
    |
  • Question
    サインインして投票
    0
    サインインして投票

    チャブーンです。

    なるほど。TCP Offload系を無効にしたら、改善したのですね。

    念のためですが、OS側にもOffload系の設定がありますので、これも無効化すると改善するかもしれませんね。

    https://blogs.technet.microsoft.com/jpntsblog/2010/03/22/scalable-networking-pack/
    https://blogs.technet.microsoft.com/jpntsblog/2013/03/05/snp-scalable-networking-pack/

    上記は、サーバ側とクライアント側両方で行う必要があります。とくにWindows 7は「SNP華やかなりし」ころのOSですので、機能的には全部ONになっていたと思います。

    フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。

    2017年2月9日 2:53
    |
  • Question
    サインインして投票
    0
    サインインして投票

    チャブーン様、ご返信ありがとうございます。

    状況が改善したことについて、言葉足らずでした。

    ネットワークアダプタの設定については変更しておりません。

    クライアント側のリモートデスクトップ接続（mstsc) のバージョンをRDP8.1サポート（6.3.9600）に変更したことによって、

    接続後に切断されることはなくなりました。

    ※以前、この対応に関して、状態は改善されませんでした。というのが誤りでした。

    それで改めて、ネットワークアダプタのoffload系設定及び、ＯＳのSNP関係の設定をDisableにしてみましたが、

    接続ができないことが多い状況は改善されませんでした。

    クライアント側にSYN+RSTパケットが返ってくると以前書きましたが、このパケットはサーバ側ではキャプチャできませんでした。

    つまりサーバ側が送出しているパケットではないのでしょうか？しかし、クライアント側でキャプチャしたパケットのソースのIPアドレスはサーバのIPアドレスとなっています。

    また、pingの応答結果が、TTL=128の場合と、TTL=64の場合があることにも気づきました。WindowsServerのデフォルトの設定では、TTL=128となるものと思います（特に設定変更は行っていません）。

    さらに、このサーバはNICが2枚刺さっており、これまではNIC1（192.168.1.1）を使用し、NIC2は無効としていたのですが、

    NIC1のIPアドレスを変更（192.168.1.3）、

    NIC2のIPアドレスを元々のNIC1のIPアドレス（192.168.1.1）に設定したところ、

    NIC1（192.168.1.3）には安定して接続可能、NIC2（192.168.1.1）には接続できたりできなかったり、

    という状況が確認できました。

    したがって、下記のような状況であり、192.168.1.1のIPアドレスを設定することに問題があるのではと思っております。

    ×192.168.1.1 - NIC1

    ×192.168.1.1 - NIC2

    〇192.168.1.3 - NIC1

    何かお気づきの点がありましたら、ご意見いただけると助かります。
    以上、よろしくお願いいたします。

    2017年2月9日 8:12
    |
  • Question
    サインインして投票
    1
    サインインして投票

    すごく基本的なこと、かつ再確認になってしまうと思いますが、192.168.1.1の端末が他にありませんか？
    例えばルーターとか。。。

    クライアントPCでARPコマンドなどで意図したMACアドレスが取得できるかなど改めて確認されたほうが良いと思います。

    • 回答としてマーク npcSystem 2017年2月13日 3:00
    2017年2月9日 8:33
    |
  • Question
    サインインして投票
    1
    サインインして投票

    私もIPアドレスじゃなくてMACアドレスをチェックした方が良いと思いますね。

    WiresharkやMicrosoft Message Analyzerその他のパケットキャプチャ出来るツールで解析されているのですよね?

    RSTが出ている前後の応答やその時のMACアドレスをちゃんと見た方が良いのでは?

    あと、キャプチャしている端末と問題の通信をしている端末が同じだと正確なモニタが出来ないので、モニタポート付きのスイッチに別の端末を繋いで見た方が良いですね
    • 編集済み tmori3y2 2017年2月9日 10:54
    • 回答としてマーク npcSystem 2017年2月13日 3:00
    2017年2月9日 10:50
    |
  • Question
    サインインして投票
    0
    サインインして投票

    snow--snow様、tmori3y2様、ご返信ありがとうございます。

    ご指摘いただいたように、MACアドレスを確認してみました。


    確かに、接続できる場合と接続できない場合のARPテーブルの内容が異なっていました。
    IPアドレス192.168.1.1が重複して設定されているようです。


    クライアントＰＣでarpコマンドでIPアドレス192.168.1.1のMACアドレスを確認
    xx-xx-xx-xx-xx-F3：接続可
    xx-xx-xx-xx-xx-F5：接続不可


    サーバでIPCONFIGコマンドでMACアドレスを確認
    xx-xx-xx-xx-xx-F3（NIC1）
    xx-xx-xx-xx-xx-F4（NIC2）


    ※マスク部分はF3～F5ともすべて同じ値です。


    MACアドレス：xx-xx-xx-xx-xx-F5を持つ、IPアドレス：192.168.1.1が設定されている機器を特定すれば良いと思うのですが、思い当たる節がありません・・・。
    特定方法や対応方法など、更にアドバイスいただけると助かります。


    以上、よろしくお願いいたします。

    2017年2月9日 23:51
    |
  • Question
    サインインして投票
    0
    サインインして投票

    ルータや高性能スイッチだとMACアドレスのパケットがどのポートを通っているか調べられたと思います。


    • 編集済み tmori3y2 2017年2月10日 9:36
    2017年2月10日 3:45
    |
  • Question
    サインインして投票
    1
    サインインして投票


    ところで、MACアドレスはベンダーIDで始まり、残りはベンダーで固有のIDを割り当てます。

    NICベンダーの場合もあるのですが、仮想環境の場合は仮想環境固有のベンダーIDになります。

    仮想的なものでない場合に、今回のように連番になるのは同じロットのハードウェアを調達した時ぐらいなもんで、普通は仮想デバイスか、同じサーバに刺さっている複数のNICじゃないか？と思ってしまいます。

    ベンダーIDは、WiresharkやMicrosoft Message Analyzerなどで表示させることができるほか、IEEEのサイトでも検索できます。

    https://regauth.standards.ieee.org/standards-ra-web/pub/view.html#registries

    このベンダーIDで絞りこむ方法で特定できる場合もあります

    例えば、All MACで00DBDFで検索するとIntel Corporateという風にわかります。

    Hyper-VでMicrosoft Hyper-V Network Adapterの00155Dとかだと、Microsoft Corporationです。

    ちなみに、大きな会社だと複数のIDを割り当ててもらっているので、この値以外でもIntelやMicrosoftに該当する場合もあります。

    どちらにしても、同じ物理サーバのNICの3つのMACアドレス、同じ仮想サーバの3つの仮想スイッチのどちらかのパターンが濃厚かと思います。
    2017年2月10日 9:36
    |
  • Question
    サインインして投票
    0
    サインインして投票

    tmori3y2様、ご返信ありがとうございます。

    いただいた情報を元に対応した結果、事象は解決いたしました。

    環境：Dell T130サーバ
    iDrac8のネットワーク設定：NIC1：192.168.1.1（xx-xx-xx-xx-xx-F5）
    WindowsServerでのNIC1の設定　 ：192.168.1.1（xx-xx-xx-xx-xx-F3）

    原因：IPアドレスの重複

    真因：iDrac8についての理解不足

    対応：iDrac8に設定するIPアドレスを変更


    iDrac8について良く理解せずに、Windowsで設定したIPアドレスと
    同一のIPアドレスを設定したことでIPアドレスの重複が発生したことが
    今回の事象の原因でした。原因が分かったので対応ができました。


    皆様にご協力いただいたおかげで、原因特定と、問題解決することができました。
    どうもありがとうございました。

    • 回答としてマーク npcSystem 2017年2月13日 3:00
    2017年2月13日 2:59
    |