DTCの「1753: エンドポイントマッパーから使用できるエンドポイントはこれ以上ありません」――ドメイン外SQL（DMZ）とSQL Serverクラスタ間で分散トランザクションが失敗する原因と解決策

SQL Server クラスタ（Always On 可用性グループ）側から、ドメイン非参加のDMZ上SQL Expressへリンクサーバー経由でアクセスし、「コピーしてから削除する」を1トランザクションでやりたい──この要件でよく立ちはだかるのが、MSDTC（Microsoft Distributed Transaction Coordinator）周りの通信障害です。

典型例が、DTCPing で 1753 (There are no more endpoints available from the endpoint mapper) が出るケース。これは「DTCが壊れている」というより、ほぼ確実に RPC/DCOMの到達性（ポート/経路/フィルタ） の問題です。Windows ファイアウォールを切っても直らないことが多いのは、通信が落ちている場所が“OSの内側”ではなく、DMZ境界のFW/ACL/IPS/EDRの挙動だったり、RPCの性質上「必要ポートが多く、どこかで取りこぼす」からです。Microsoft Learn+1

DTCの「1753: エンドポイントマッパーから使用できるエンドポイントはこれ以上ありません」――ドメイン外SQL（DMZ）とSQL Serverクラスタ間で分散トランザクションが失敗する原因と解決策

起きている現象を整理する：エラーの意味

今回の症状は大きく2つです。

SQL側エラー：MSOLEDBSQL のリンクサーバーで "No transaction is active."
→ 分散トランザクション開始（昇格）に失敗し、リモート側に“トランザクションが存在しない”状態で操作しようとしているサインになりがちです。関連エラーとして 7391/7399（分散トランザクションを開始できない）系が知られています。Microsoft Learn
DTCPing 側エラー：1753 エンドポイントマッパーに到達できない
→ RPC Endpoint Mapper（多くの場合 TCP 135）や、そこから割り当てられる 動的RPCポート に到達できていない可能性が高いです。Microsoft Learn+1

ポイントは、MSDTCはRPC/DCOMに依存し、動的ポートを使うこと。境界FWをまたぐと「135は開いているが、その後に使う動的ポートが閉じていて失敗」という構図が非常に多いです。Microsoft Learn+1

最短で切り分ける：まず確認すべき5項目

ここからは「設定は入れたのに動かない」時に、効果が出やすい順で書きます。

1) そもそもRPC 135が通っているか（DMZ境界FW含む）

DTCPing の 1753 は、最初の入口（Endpoint Mapper）に届かない時にも出ます。Windowsファイアウォールを止めても、DMZの境界FWやセキュリティ機器で止まっていれば同じです。
まずは クラスタ側 → DMZサーバーの TCP 135 が確実に許可されていることを、FWログと到達試験（ポート疎通）で確認します。Microsoft Learn+1

2) 「135の次」に必要な動的RPCポートが落ちていないか

135が通っても、RPCはその後に 動的ポート（既定は 49152–65535 を推奨とする文書が現行） を使います。ここが閉じていると、DTCPingやDTC開始で失敗します。Microsoft Learn

DMZでこの範囲を全開放できないのは普通なので、次のどちらかが現実解になります。

MSDTCに固定ポートを割り当て、そのポートだけ通す（推奨される“現場向け”解）
もしくは RPC動的ポート範囲を狭めて、その範囲をFWで許可（設計が必要）

Microsoftの公開情報でも「ファイアウォール越しなら固定ポート化、または既定の動的レンジを考慮」といった方針が示されています。Microsoft Learn+1

3) DMZ側のEDR/IPS（例：SentinelOne）がRPC/DCOMを遮断していないか

質問文では一時停止も試されていますが、製品によっては「サービス単位」「ポリシー単位」で残る場合があります。
相関パケットキャプチャ（両端同時） を取る、という助言はかなり核心です。FWログに出ない“ホスト内ブロック”もこれで見えます。Server Fault

4) クラスタ側のMSDTCが「クラスタ対応」になっているか

SQL Server Always On 可用性グループ環境では、分散トランザクションが絡む構成で クラスタ化MSDTC（Clustered MSDTC） が論点になることがあります。
「サーバー単体のLocal DTC設定は揃っているのに、クラスタからの分散トランザクションだけ失敗する」なら、クラスタ側のDTCリソース設計（役割/ネットワーク名/依存関係）を疑う価値があります。類似の相談も見られます。Microsoft Learn+1

5) DTCの認証設定は“安易にNo Authentication”で固定しない

DMZとドメイン内の組み合わせは認証が難しく、切り分けのために No Authentication Required に寄せがちです。ただ、セキュリティ境界でRPCを扱う時点で設計難度が上がるため、最終的には「必要最小限の許可」と「固定ポート化」で落としどころを作る方が運用が安定します。
（No Authentication 自体が直接1753を生むというより、通信面が未解決のまま設定だけ増えて泥沼化しやすい、という意味です）

実務で効く解決パターン：固定ポート化＋FW許可の設計

結論から言うと、DMZ越しにMSDTCを通すなら、次のセットが最も成功率が高いです。

MSDTCを固定ポートで運用（サーバーA/B双方）
FWで TCP 135（RPC Endpoint Mapper） と 固定化したMSDTCポート を相互許可
併せて、名前解決や双方向通信（Inbound/Outbound）を前提に経路を整える
仕上げに両端でパケットキャプチャし、SYN/ACK～RPCバインドまで成立しているか確認

Microsoftのガイダンスでも、ファイアウォール越しのDTCは「固定ポート」または「動的レンジを考慮」する方針が明示されています。Microsoft Learn

それでも危ない：DTCをDMZ越しで使う前に知っておきたい代替案

運用面・監査面で「DMZからドメイン内へRPC/DCOMを通す」のが重い場合、要件（コピーして削除）を満たす別ルートもあります。

アプリケーション側で“確定済みID”を持ち、冪等に取り込み→取り込み済みのみ削除
1トランザクションにこだわらず、「取り込み済みフラグ」「バッチID」「再実行しても二重登録しない」設計で整合性を確保します。
DMZ側はステージングとして保持し、ドメイン内からPullするETL（SSIS等）
ネットワーク境界は「DB接続（1433等）のみ」に寄せ、RPCを持ち込まない。
メッセージング（キュー）で転送し、処理成功時にACKで削除
監査ログや再送制御を含めて“業務トランザクション”として完結させやすいです。

DTCが必要な場面もありますが、DMZという条件が付いた瞬間に「通すための作業」と「通し続ける運用」がコスト化します。1753が出ている段階では、まず通信設計（ポート戦略）を固め、それでも難しければ代替方式へ切り替えるのが、最終的に早く安定します。

まとめ：1753は“DTC設定不足”ではなく“RPCの到達性問題”として扱う

DTCPing 1753 は、ほぼ RPC Endpoint Mapper（135）または動的RPCポート の問題。WindowsファイアウォールOFFでも直らないのは珍しくありません。Microsoft Learn+1
DMZ越しは 固定ポート化＋FW許可 が王道。動的レンジ全開放は現実的でないことが多いです。Microsoft Learn
クラスタ（Always On）から開始するなら、クラスタ対応MSDTC の設計も確認ポイント。Microsoft Learn+1
仕上げは 両端同時のパケットキャプチャ。落ちている場所（境界FW/EDR/経路）を一発で特定できます。Server Fault

元ネタになった質問ページ（Server Fault）の状況は、まさに「RPCがDMZ境界で落ちている」典型パターンです。まずは 135＋（固定化した）DTCポート という“通すべきものを通す”設計に寄せる。それが、最短距離で「No transaction is active」から抜け出す道になります。

DTCの「1753: エンドポイント マッパーから使用できるエンドポイントはこれ以上ありません」――ドメイン外SQL（DMZ）とSQL Serverクラスタ間で分散トランザクションが失敗する原因と解決策