行业共识认为，服务器上的MS DTC不可用，多数情况不是组件损坏，而是服务没启动、安全配置漏勾、端口被防火墙或安全组挡住，先查服务状态，再查组件服务安全项，最后查网络放行，大部分问题能在十几分钟内恢复。
服务器上的msdtc不可用怎么解决：先看服务状态
很多管理员遇到MS DTC报错，第一反应是重装系统，其实真没必要，MS DTC是一个依赖项很多的服务，先把它本身的状态摸清楚,往往就找到了根因。
用services.msc确认服务是否在跑
按Win+R输入services.msc，找到Distributed Transaction Coordinator服务,重点看两处：
- 状态栏是否显示“正在运行”
- 启动类型是否设置为“自动”
如果启动类型是“手动”，服务器重启后服务不会自己起来，很多企业应用在重启后突然报MS DTC不可用，就是因为这个原因，右键改成“自动”,再点启动即可。
用命令行启动并读取错误码
图形界面有时看不出具体原因，打开管理员CMD,直接执行：
net start msdtc
如果启动失败，会返回错误码，常见的有1068、1075、1067，这些错误码不要死记,把它们拿去事件查看器里筛更直接。
事件查看器路径：
应用程序和服务日志 -> Microsoft -> Windows -> DistributedTransactionCoordinator
这里能看到具体是账户权限不足，还是依赖服务没启动,还是注册表键值缺失。
依赖服务要一并检查
MS DTC不是独立工作的，它依赖RPC Endpoint Mapper和DCOM Server Process Launcher，这两个服务没启动，MS DTC一定起不来。
在服务属性里点“依存关系”选项卡，能看到依赖关系，排查时顺手把这两个服务确认一下,能少走很多弯路。
win server msdtc配置最容易漏掉的安全项
服务明明在运行，应用还是报MS DTC不可用，问题大概率出在组件服务的安全配置上，这是Windows Server里最容易漏的一环。
四个勾选项一个都不能少
打开组件服务：运行dcomcnfg,依次展开：
组件服务 -> 计算机 -> 我的电脑 -> Distributed Transaction Coordinator -> 本地 DTC -> 右键属性 -> 安全选项卡
必须勾选的项包括：
- 网络DTC访问
- 允许远程客户端
- 允许入站
- 允许出站
“不要求进行验证”也建议勾上，域内环境如果两边认证方式一致，可以选其他验证级别；但混合环境里选“不要求进行验证”,能减少相当一部分互访失败。
固定MS DTC端口让防火墙少折腾
MS DTC默认使用135端口加RPC动态端口，动态端口范围很宽，防火墙不好放行,建议在注册表里固定一个端口。
路径：
HKEY_LOCAL_MACHINESOFTWAREMicrosoftMSDTC
新建DWORD值，名称写ServerTcpPort，值填一个固定端口，比如5000，然后给防火墙添加入站规则,放行135和5000两个端口。
改完重启MS DTC服务即可生效，据微软官方文档，固定端口后远程事务不会再随机切换端口,排查起来会稳定很多。
SQL Server集群场景下msdtc服务启动不了怎么排查
数据库服务器和业务服务器分离部署，或者使用SQL Server链接服务器做跨库事务时，MS DTC不可用会直接阻断操作,这个场景下的排查要比单机多一层。
典型报错：无法启动分布式事务
在SQL Server里执行BEGIN DISTRIBUTED TRANSACTION时，如果报“MS DTC不可用”或“无法启动分布式事务”，要记住一点：两边服务器都要配MS DTC,不是只配数据库那一台。
两边需要分别检查：
- 服务是否都处于运行状态
- 安全选项卡四个勾选项是否都完整
- 防火墙是否都放行135和固定端口
- 服务器之间名称解析是否正常
只要有一边漏了,分布式事务就会失败。
账户与注册表权限
MS DTC默认以Network Service账户运行，如果被管理员或安全软件改成了其他低权限账户，启动就会失败，先把它改回Network Service。
还有一种情况是优化工具或杀毒软件清理注册表时，误删了HKLMSOFTWAREMicrosoftMSDTC下的键值，此时直接手工重建容易漏项,不如用命令重装。
重装命令在管理员CMD下按顺序执行：
msdtc -uninstallmsdtc -installnet start msdtc
执行前先停止服务，重装完成后，组件服务里的安全选项卡要重新勾选一遍,因为卸载会清掉原有配置。
云服务器msdtc不可用和本地服务器对比要注意什么
云服务器和本地服务器在MS DTC问题上，大部分排查逻辑完全一样，但云环境多了一层安全组,漏掉它的人不在少数。
安全组是云上特有的一道闸
本地服务器只有Windows防火墙，云服务器除了系统防火墙，还有云平台的安全组，很多管理员在系统里放行了端口，但安全组没放行,外部业务服务器还是连不上。
需要在云控制台检查入方向规则，放行135和固定端口，国内云服务器一般还涉及白名单机制，只放行给业务服务器的固定IP,不要开放到全网段。
下面这张表对比了本地与云端的排查重点：
| 排查项 | 本地服务器 | 云服务器 |
|---|---|---|
| 服务状态 | services.msc | 相同 |
| 安全配置 | dcomcnfg | 相同 |
| 系统防火墙 | 放行135和固定端口 | 放行135和固定端口 |
| 额外网络层 | 无 | 云安全组入方向规则 |
| 常见漏点 | 安全选项卡 | 安全组未放行 |
服务器msdtc修复多少钱：自己排查和远程支持的成本差异
服务器msdtc修复多少钱没有统一定价，远程支持通常按次收费，价格在百元级；云厂商工单一般免费,但深度排查可能不在基础支持范围内。
多数MS DTC不可用问题按本文步骤自行处理，成本为零，只有涉及域控、多节点集群、注册表损坏修复时才需要额外付费支持，自己先排查一遍,也能避免花冤枉钱。
核心排查顺序再重复一遍
压缩成一张可执行的清单：
- 查Distributed Transaction Coordinator服务状态
- 查事件查看器里的错误码
- 查RPC Endpoint Mapper和DCOM Server Process Launcher依赖服务
- 查组件服务安全选项卡四个勾选项
- 注册表固定端口并放行防火墙
- 云服务器额外放行安全组入方向规则
- 仍不行则用命令重装MS DTC组件
按这个顺序走,一般不需要重装操作系统。
Q&A：关于服务器上的msdtc不可用
服务器上的msdtc不可用会影响哪些业务？
主要影响SQL Server跨库事务、链接服务器、IIS应用里的COM+事务、消息队列与数据库联动等，只要涉及多个资源管理器参与同一个事务，都会调用MS DTC,单库事务不受影响。
msdtc服务无法启动提示错误1067怎么办？
错误1067多与依赖服务或账户有关，先确认RPC Endpoint Mapper和DCOM Server Process Launcher已启动，再把登录账户改回Network Service，最后重启服务，若注册表键值被删，执行msdtc -uninstall和msdtc -install重装即可恢复。
云服务器上msdtc配置和本地服务器一样吗？
大部分一样，但云服务器要额外检查安全组是否放行135和固定端口，系统防火墙放行了，安全组没放行，外部业务服务器仍然连不上,这是云环境与本地环境最明显的差别。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/671174.html
