現在オフラインです。再接続するためにインターネットの接続を待っています

MS DTC ファイアウォールの問題をトラブルシューティングする方法

この記事は、以前は次の ID で公開されていました: JP306843
サポート期間が終了した「サポート技術情報」資料に関する免責事項
この資料は、マイクロソフトでサポートされていない製品について記述したものです。そのため、この資料は現状ベースで提供されており、今後更新されることはありません。
概要
この資料では、Microsoft 分散トランザクション コーディネータ (MS DTC) を有効にして、ファイアウォールを介して他の MS DTC と通信する際のトラブルシューティングに役立つ手順を紹介しています。ファイアウォールを介して MS DTC を使用した場合に発生する可能性のある問題の一部を次に挙げます。
  • MTS または COM+ コンポーネントの [トランザクション サポート] が [未サポート] または [サポート] に設定されている場合はアプリケーションが正常に機能しますが、これが [必要] または [新しく必要] に設定されている場合はアプリケーションが正常に機能しません。

    注 : MTS の場合はそれぞれ [トランザクションをサポートする]、[トランザクションをサポートしない]、[トランザクションが必要]、[新しいトランザクションが必要] と表示されます。
  • 次のエラー メッセージが表示されます。
    指定されたトランザクション コーディネータに、新規トランザクションを参加できませんでした。
  • 次のエラー メッセージが表示されます。
    エラー 8004d00a
    分散トランザクションエラー
これらの問題に対処する方法は他のいくつかのマイクロソフト ドキュメントでも説明されていますが、この資料でそのほとんどをまとめて説明します。

: ここで示すトラブルシューティング手順は、Microsoft Windows NT オペレーティング システムおよび Microsoft Windows 2000 オペレーティング システムのみを対象としています。
詳細

トラブルシューティングの手順

  1. 両方のサーバー上で MS DTC サービスが開始されていることを確認します。
  2. Windows NT 4.0 を実行しているサーバーの場合は、Windows NT 4.0 Option Pack (NTOP) をインストールした後に Windows NT 4.0 Service Pack 6 (SP6) を再度適用する必要があります。次の表に示すファイルのバージョンを調べて、Windows NT 4.0 Option Pack をインストールした後に Windows NT 4.0 SP6 が適用されているかどうかを確認してください。

    ファイル名NTOP をインストールした後のバージョンSP6 を再インストールした後のバージョン
    Msdtcprx.dll1997.11.5321999.6.854.0
    Msdtctm.dll1997.11.5321999.6.854.0
    Xolehlp.dll1997.11.5321998.08.762

    Windows NT 4.0 Option Pack のインストールの詳細については、次のマイクロソフト ホワイト ペーパーを参照してください。
    IIS 4.0 の推奨されるインストール手順
    http://support.microsoft.com/support/iis/install/install_iis4.asp
  3. MS DTC 通信がファイアウォールを介して行われるように両方のサーバーを構成します。関連情報を参照するには、以下の「サポート技術情報」 (Microsoft Knowledge Base) をクリックしてください。
    250367 [INFO] MS DTC をファイアウォール経由で動作可能にする
    Windows 2000 での TCP ポートの構成方法の関連情報を参照するには、以下の「サポート技術情報」 (Microsoft Knowledge Base) をクリックしてください。
    300083 [HOWTO] Windows 2000 および Windows XP で TCP/IP ポートを制限する方法
  4. 以上を試してもまだ MS DTC がファイアウォールを介して機能しない場合は、DTCPing.exe ツールをダウンロードし、両方のサーバーにこのツールをインストールします。下記のファイルは、「Microsoft ダウンロード センター」からダウンロードできます。
    DTCPing.exe ファイルには、次のファイルが含まれています。
       日付            時刻   バージョン  サイズ    ファイル名   ----------------------------------------------------------   29-Oct-2003  22:56  1.8.0.1  274,490  Dtcping.exe   15-Dec-2003  22:05             1,618  Eula.txt   24-Nov-2003  20:59             1,560  Machinea_failure.log   24-Nov-2003  20:21             1,901  Machinea_success.log   24-Nov-2003  20:55               999  Machineb_failure.log   24-Nov-2003  20:31             1,750  Machineb_success.log   24-Nov-2003  20:15             2,325  Readme.txt
    リリース日 : 2003 年 11 月 24 日

    マイクロソフトのサポート ファイルのダウンロード方法の関連情報を参照するには、以下の「サポート技術情報」 (Microsoft Knowledge Base) をクリックしてください。
    119591 オンライン サービスからマイクロソフトのサポート ファイルを入手する方法
    マイクロソフトでは、アップロード時点の最新のウイルス検査プログラムを使用して、配布ファイルのウイルス チェックを行っています。配布ファイルはセキュリティで保護されたサーバー上に置かれており、権限のない第三者が無断でファイルを変更できないようになっています。
  5. ダウンロードした DTCPing.exe に含まれている Readme.txt ファイルを使用して、まず、Server1 から Server2 へのリモート プロシージャ コール (RPC) 通信および分散トランザクション コーディネータ (DTC) 通信をテストします。このテストに成功した場合は、Server2 から Server1 への通信をテストします。

    送信方向または受信方向のいずれかについて RPC が実行できない場合、MS DTC はどちらの方向についても通信に失敗します。RPC 通信が失敗する場合、(両方のサーバーの) DTCPing ウィンドウにこの失敗が表示され、その内容は関連する dtcping.log ファイルにも保存されます。詳細については、Readme.txt ファイルを参照してください。RPC テストがいずれかの方向で失敗する場合で、ログに RPC 通信の失敗が記録されているときは、次の手順に進みます。RPC テストがいずれかの方向で失敗する場合で、ログに DTC 通信の失敗が記録されているときは、手順 9. に進みます。
  6. いずれかの方向 (たとえば、Server1 から Server2) で RPC が失敗した場合は、ファイウォールの管理者に問い合わせ、インターネット制御メッセージ プロトコル (ICMP) が両方の方向について開かれているかどうかの確認を依頼します。

    : RPC が失敗したかどうかは、通常、dtcping.log ファイルの内容から判断できます。

    デフォルトでは、ICMP はポート 1 です。これは、%windir%\WinNT\System32\Drivers\ フォルダにあるプロトコル ファイルで確認できます。Server1 から NetBios 名で Server2 に ping を実行します。ping が失敗する場合は、次の手順に進みます。それ以外の場合は、手順 8. に進みます。
  7. Server1 から IP アドレスで Server2 に ping を実行し、ファイアウォール上で ping のための正しいポートが開かれていることを確認します (ネットワーク モニタのトレースで、これを確認できます)。IP アドレスでの ping は成功し、NetBios 名での ping に失敗する場合は、名前解決に問題があります。

    : ipconfig /all コマンドを使用すると、サーバーの IP アドレスを取得できます。

    クライアント サーバー (NetBios 名での ping に失敗したサーバー) の Hosts ファイルにエントリを作成すると、簡単に名前解決をテストできます。エントリ作成は、このファイルに含まれているサンプル エントリを参考にして行ってください。

    : トラブルシューティングが目的の場合を除き、Hosts ファイル内にエントリを作成しないでください。新しいエントリを作成することで名前解決の問題が解消した場合は、そのエントリを Hosts ファイルから削除したうえで、DNS、WINS サーバー、または LmHosts ファイル内に必要なエントリを作成します。

    名前解決に問題がある場合、その他の解決策もありますが、この資料ではそれらについては言及しません。
  8. Server1 から Server2 への NetBios 名での ping に失敗する場合や、Server1 から Server2 への NetBios 名での ping には成功しても RPC 通信に対する DTCPing テストに失敗する場合は、ファイアウォール上でポート 135 (End Point Mapper、EPM) が双方向で開かれていない可能性があります。ファイアウォールを調べ、EPM が両方の方向で開かれていることを確認してください。この時点で、ネットワーク モニタ トレースが問題を突き止めるための参考になる場合があります。
  9. この手順に至るのは、DTCPing テストでの RPC 通信が両方の方向で機能する場合のみです。両方の方向で成功する場合は、RPC と MS DTC 通信が正常に流れています。
  10. DTCPing テストにおいて、少なくとも片方の方向 (たとえば、Server1 から Server2) で DTC 通信に失敗する場合、ファイアウォールの管理者に連絡し、MS DTC 構成の資料 (手順 3. を参照) で開発者が指定したポートを開いているかどうかの確認を依頼します。また、何らかの規則がファイアウォールに適用されていて、それがいずれかの (または両方の) サーバーの RPC コールバックを妨げている可能性もあります。ネットワーク モニタ トレースがこの特定の状況をトラブルシューティングするための参考になる場合があります。
  11. DTCPing が次のようなエラー メッセージを返す場合は、以下のように対処します。
    Unexpected: My session guid is same as partner's guid
    現在のサーバーが重複していないかどうか、および他のサーバーからのクローンではないかどうかを調べ、該当する場合は、レジストリの HKEY_CLASSES_ROOT\CID キーを探します。このキーの下に、複数の GUID が見つかる場合があります。下にある Description キーが MSDTC になっている GUID を探します。この GUID は、DTCPing の出力ウィンドウにも表示されます。他のサーバーがそのレジストリ内で MS DTC にまったく同じ GUID を持っている場合は、どちらかのレジストリ内で MS DTC 用の新しい GUID を作成する必要があります (これには、GuidGen を使用できます)。

    この新しい GUID およびその下のすべてのキーを HKEY_CLASSES_ROOT\CID に追加した後は、必ずそのキーで置き換える古い GUID を削除します。

    この手順で問題が解決する場合は、次の資料を参照して重複するコンピュータ ("ゴースト" コンピュータ) の詳細について調べることを強くお勧めします。関連情報を参照するには、以下の「サポート技術情報」 (Microsoft Knowledge Base) をクリックしてください。
    162001 インストール済みの Windows のバージョンのディスク複製に関するマイクロソフトの方針
プロパティ

文書番号:306843 - 最終更新日: 10/29/2007 14:54:58 - リビジョン: 4.1

Microsoft COM+ 1.0, Microsoft Transaction Services 2.0

  • kbproductlink kbdownload kbdtc kbhowto KB306843
フィードバック