サーバー上で実行され、他の 4 つのサーバー (すべてドメイン内のメンバー) にアクセスして、各プライベート キュー内のメッセージを取得する Windows アプリケーションがあります。新しいサーバーをインストールしたばかりですが、何らかの理由でアプリケーションがそのコンピューターにアクセスしようとすると、「リモート コンピューターが利用できません」というメッセージが表示されます。
アプリケーションは、管理ドメイン ユーザーであるユーザーを使用して他のサーバーにアクセスします。
誰かがそのような問題に遭遇したことがありますか、または何が原因であるかについての手がかりを持っていますか?
4 に答える
おそらくこのスレッドには遅すぎるかもしれませんが、ここで答えを見つけました: http://blogs.msdn.com/johnbreakwell/archive/2008/07/10/getting-msmq-messages-out-of-windows-server -2008.aspx
Microsoft Network MonitorやWiresharkなどのパケット キャプチャ ツールを起動して、エラーが発生したシステムとの間で送受信されるトラフィックを調べましたか? 多くの場合、これは多くの時間のかかる実験をせずに何が起こっているかを確認する最も確実な方法です。
エラーが発生したボックスからキャプチャをセットアップし、エラーが発生するまで実行し、すぐにキャプチャを停止します。そのシステムとの間のトラフィックだけを見るようにフィルタを設定します。キャプチャ ツールをボックス自体にインストールできない場合は、そのボックスからのすべてのトラフィックを認識できるようにネットワーク上に配置してください。(つまり、スイッチの隣接ポートに配置しないでください。スイッチの仕事は、各ポートのトラフィックを互いに隔離することだからです)。
問題のリモート サーバーに実際のトラフィックが送信されていない場合は、名前付け/ディレクトリ/DNS の種類に問題がある可能性があります。つまり、ローカルサーバーは他のサーバーがどこにあるかを把握できません。これは Windows ドメイン タイプの状況であるため、Active Directory で手がかりを探し始めます。
トラフィックがリモート サーバーに送信されているのが確認できるが、障害が発生する前にそこから戻ってくるパケットが 1 つも見られない場合は、リモート ボックスまたはここからそこへのルートにファイアウォールの問題がある可能性があります。
トラフィックがリモート サーバーとの間を行き来しているのに停止した場合は、それらのパケットを掘り下げて、トラフィックに存在する可能性のある低レベルのエラー コードを確認する必要があります。NETMON と Wireshark の両方に Microsoft プロトコルの適切なデコードがあるため、何が起こっているかを正確に確認できるはずです。これらのプロトコルに慣れていない場合は、比較できるように、最初に他のサーバーのいずれかへの正常に機能している接続をキャプチャすることをお勧めします。
ファイアウォールの問題でしょうか?
問題は最終的に解決され、誤って解決されました。DNSサーバーに混乱があり、キャッシュサーバーが正しいサーバーにアクセスするのが困難だったようです。私たちのウェブマスターはすべてのサーバー名を修正し、それによってMSMQの問題も解決されました。