ドメイン内SQL Server 2022クラスタとDMZ非ドメインSQL Express間でDTCが失敗する原因と対処法（1753／No Endpoints Available）

SQL Server間で「取り込み→同期→削除」を1つのトランザクションで完結させたいとき、候補に挙がるのがMicrosoft Distributed Transaction Coordinator（MSDTC／DTC）です。ところが、ドメイン環境のSQL Server 2022 Always On（可用性グループ）クラスタと、DMZ上の非ドメインWindows Server 2022＋SQL Server Express 2022をまたぐ構成では、DTCが想定どおり動かず、1753 (There are no more endpoints available from the endpoint mapper.) や No transaction is active. といったエラーで詰まりやすくなります。

この記事では、典型的な落とし穴を「ネットワーク/RPC」「DTC設定」「Always Onクラスタ特有」「SQL側の挙動」の順に切り分け、短時間で原因に近づく実践的な手順をまとめます。

• ドメイン内SQL Server 2022クラスタとDMZ非ドメインSQL Express間でDTCが失敗する原因と対処法（1753／No Endpoints Available）
  • 現象の整理：今回の2つのエラーが意味すること
    • 1) DTCPingの 1753（Endpoint Mapperに空きがない）
    • 2) SQL側の No transaction is active.
  • 最短で切り分ける：まずはRPC疎通の確認から
    • ステップ1：TCP 135 が通るか
    • ステップ2：動的RPCポートが通るか（ここが本丸）
  • 対処の王道：MSDTCのポートを固定して最小開放にする
    • 固定ポート運用のメリット
    • 固定ポート運用で見るべき注意点
  • DTCセキュリティ設定：No Authentication Requiredでも落ちる理由
    • 1) 名前解決と接続先名のズレ
    • 2) NAT越え・アドレス変換
    • 3) EDR（例：SentinelOne）のRPC/SMB系制御
  • Always On 可用性グループ（AG）＋クラスタ特有の落とし穴
    • 1) クラスタ化DTC（Clustered MSDTC）が必要になるケース
    • 2) 接続先が“いまアクティブなノード”になっているか
  • SQL Server側で見直す設定：DTCに“昇格”させない検証
  • 決定打：両側同時の相関パケットキャプチャで落ち場所を確定する
  • どうしてもDTCが難しいときの代替案（現場向け）
  • まとめ：この順で潰せば解決が近い

現象の整理：今回の2つのエラーが意味すること

1) DTCPingの 1753（Endpoint Mapperに空きがない）

これは多くの場合「DTC以前にRPCが成立していない」サインです。MSDTCはRPC/DCOMを使って通信しますが、その入口が TCP 135（RPC Endpoint Mapper） です。ここが到達できない、または到達後に割り当てられる 動的RPCポート が塞がれていると、1753が出やすくなります。

ポイントは「Windows Firewallを切ったのに直らない」ケースが普通にあることです。経路上にあるNWファイアウォール、ACL、IPS/IDS、NAT、マイクロセグメンテーション、EDRの通信制御など、OS外の要因でも同じ症状になります。

2) SQL側の No transaction is active.

これは「分散トランザクションとして昇格（promotion）できなかった」または「接続先でDTCハンドシェイクが成立しない」時に見えることが多いです。リンクサーバー経由の操作やリモートプロシージャ呼び出しで、SQLが分散トランザクションを開始できず、結果として「トランザクションがアクティブではない」と言われます。

最短で切り分ける：まずはRPC疎通の確認から

DTCの設定をいじる前に、RPCが通っているかを事実で押さえます。ここが崩れていると、以降の設定は全部無意味になりがちです。

ステップ1：TCP 135 が通るか

ドメイン側 → DMZ側、DMZ側 → ドメイン側の両方向で、TCP 135が通るかを確認します。片方向だけ通っても失敗します（DTCは双方向を要求しやすい）。

• 到達できない：ネットワーク機器、ACL、経路、名前解決、EDR遮断が疑わしい

• 到達できる：次は「135の後に使われる動的RPCポート」が問題になりやすい

ステップ2：動的RPCポートが通るか（ここが本丸）

Windows Server 2022のRPC動的ポート範囲は一般に 49152–65535（環境で変更可能）です。DTCはEndpoint Mapper（135）で「これから使うポートはこれ」と交渉し、その先の動的ポートに接続します。
つまり 135だけ開けても失敗します。

ここでの典型的な誤解：

• 「Windows Firewallを無効にした」→ それでも NWファイアウォールで動的ポートが閉じている

• 「メインFWログに出ていない」→ そもそも別の区間（DMZスイッチACL、EDR、ホスト型FW、IPS）で落ちている

• 「DTCPingを別端末でも試した」→ 経路が同じなら結果は同じ（逆に“経路依存”が濃厚）

対処の王道：MSDTCのポートを固定して最小開放にする

DMZ越えで49152–65535を丸ごと開けるのは現実的でないことが多いです。そこで、MSDTCが使うRPCポートを固定し、そのポート＋135だけを開ける設計に寄せます。

固定ポート運用のメリット

• 開放ポートが明確になり、セキュリティ部門と合意しやすい

• FWログで追いやすく、原因究明が一気に進む

• 「Windows Firewallを切ってるのに…」という状態から脱出できる

固定ポート運用で見るべき注意点

• 「MSDTCだけ固定」しても、別COMコンポーネントが動的ポートを要求する場合があります

• それでも、DTC起点の問題なら固定化は非常に効きます

• 固定化後は、NWファイアウォール／ホストFWの両方に例外を入れ、双方向で許可します

DTCセキュリティ設定：No Authentication Requiredでも落ちる理由

提示されている設定（Network DTC Access、Allow Inbound/Outbound、No Authentication Required）は、非ドメイン相手では一般的な落としどころです。ただし、次の要素で失敗することがあります。

1) 名前解決と接続先名のズレ

DTCはホスト名・IP・SPN的な扱いに敏感な場面があり、DMZ側の名前解決が中途半端（hosts頼み、逆引き不可、別名参照）だとハンドシェイクが不安定になります。
可能なら「往復で一貫した名前解決」を作り、リンクサーバーも同じ名前で解決させます。

2) NAT越え・アドレス変換

DMZでNATが絡むと、RPC/DCOMのネゴシエーションと相性が悪くなることがあります。FWログに出にくいのに失敗する、キャプチャすると片側だけ返ってこない、という症状が出やすいです。

3) EDR（例：SentinelOne）のRPC/SMB系制御

「停止したつもり」でも、ドライバ層の制御が残る製品もあります。DTCは古典的なRPC/DCOMスタックを通るため、EDRが“怪しい横移動”として抑止することがあります。
切り分けとしては、EDRの除外ポリシー（RPC/DCOM、msdtc.exe、dllhost.exeなど）を明示的に設定し、監査ログでブロック有無を確認するのが確実です。

Always On 可用性グループ（AG）＋クラスタ特有の落とし穴

SQL Server 2022のAGクラスタから外部へ分散トランザクションを投げる場合、クラスタ側のMSDTCが単体サーバーの感覚と違う点に注意が必要です。

1) クラスタ化DTC（Clustered MSDTC）が必要になるケース

AGのリスナー名やクラスター仮想名を経由してトランザクションを扱うなら、クラスタにDTCリソース（役割）を作って整合させる設計が必要になることがあります。
「片方は単体、片方はクラスタ」構成では、DTCの名前解決・到達性・フェイルオーバー時の一貫性が崩れやすいです。

2) 接続先が“いまアクティブなノード”になっているか

リンクサーバーがノード名を指していたり、逆にリスナー名がNW的にDMZから到達できない場合、DTC以前に接続が揺れて混乱します。
DTCを疑う前に「SQL接続として正しい経路・名前・ポートになっているか」を固定します。

SQL Server側で見直す設定：DTCに“昇格”させない検証

根本解決はRPC/ポート問題の解消ですが、切り分けとして 「分散トランザクションに昇格させない」 検証は有効です。

• リンクサーバーの remote proc transaction promotion を無効化して挙動が変わるか

• まずは“読むだけ／書くだけ”の単純操作で接続や権限の問題を排除する

• その後、明示トランザクション＋リモート操作で昇格が走る瞬間を特定する

これで「DTC通信の問題」なのか「SQLの昇格条件・設定の問題」なのかが分かりやすくなります。

決定打：両側同時の相関パケットキャプチャで落ち場所を確定する

DTC/RPCは、片側のログだけ見ても真相に届きにくいです。効果が大きいのが、ドメイン側・DMZ側の同時キャプチャです。

見るポイントはシンプルで、

1. 135へのSYNが届いているか

2. 135の応答後、提示された動的ポートへ接続しているか

3. その動的ポートのSYN/ACKが返っているか

4. 片側には出ているのに、反対側に入っていないパケットがどこで消えるか

これで「ホストで落ちているのか」「FW/IPSで落ちているのか」「経路/NATで壊れているのか」がほぼ確定します。設定の試行錯誤より、結果的に最短で解けます。

どうしてもDTCが難しいときの代替案（現場向け）

DMZ越えのDTCは、セキュリティ要件と真正面から衝突しやすい方式です。要件次第では、次の代替が結果的に堅牢になります。

• DMZ側は「削除せず処理済みフラグ」で冪等にし、ドメイン側が定期取得（再実行しても壊れない）

• キュー/メッセージング（例：サービス連携基盤）で“確実に届ける”を担保し、DB間2PCを避ける

• ETL（SSIS等）やアプリ層で「取り込み→確認→削除」を2段階にし、監査ログで整合性を担保する

「完全な分散トランザクション」が必須か、「結果整合でよいか」を整理すると、設計そのものが楽になることもあります。

まとめ：この順で潰せば解決が近い

• 1753はDTC以前にRPCが詰まっている合図。TCP 135＋動的RPCポートを疑う

• Windows Firewallを切っても直らないなら、NWファイアウォール/ACL/IPS/EDR/NATが本命

• DMZ越えは「動的ポート全開」が難しいので、MSDTCの固定ポート化＋最小開放が王道

• Always Onクラスタは単体と違う。必要なら クラスタ化DTC や接続名の整合を見直す

• 最短は 両側同時の相関パケットキャプチャ で“落ち場所”を確定すること

この手順で進めると、「設定は合っているのに動かない」状態から抜け出しやすくなります。DTCは“設定項目”よりも“通信の事実”が支配する領域なので、まずはRPC経路を固定し、キャプチャで証拠を取るのが勝ち筋です。