On both the database server and the application server, you have to make sure the firewall doesn't block the MSDTC service. Technically, MSDTC uses the RPC endpoint mapping service on port 135 to determine the port for the DTC endpoint, which can be dynamic (within the range of 49152-65535).

There should be an existing enabled rule for this already, but the RPC port 135 must be opened.

There are two different strategies to open the required ports:

• Enable the (preconfigured) firewall rules for dynamic MSDTC ports (recommended if possible)
• Configure a fixed port for MSDTC and customize the port range for RPC, and open those ports on the firewall (only recommended if the IT security policy requires it)

Custom ports should only be necessary if the customer's IT security policy requires it (e.g., if there's an external firewall that doesn't care much about the dynamic ports in your database server).

Please make sure the firewall is configured correctly both on the client machine (e.g., the application server) and the host machine (e.g., the DB server).

Customizing the dynamic ports mostly makes sense on the DB server, but it might also be necessary on the client machine depending on the customer's IT security policy.

Default dynamic ports

If you use the default dynamic ports, there are different ways of adding the firewall rules to open them:

• Powershell:
  Enable-NetFirewallRule -DisplayGroup "Distributed Transaction Coordinator"
• Netsh:
  netsh advfirewall firewall set rule group="Distributed Transaction Coordinator" new enable=yes
• Windows Firewall Advanced Settings UI: Enable the 3 Inbound and 1 Outbound Rules regarding the "Distributed Transaction Coordinator"
• Windows Firewall: Add a rule allowing the program MSDTC inbound and outbound (the path usually is "C:\windows\system32\msdtc.exe")

Custom dynamic ports

Here it is described how to configure a specific port for MSDTC and how to customize the port range used by RPC:

• Configure DTC to work through firewalls (learn.microsoft.com)

Long story short, we have to add a couple of registry entries:

• HKEY_LOCAL_MACHINE\Software\Microsoft\MSDTC
  • Add value: Name "ServerTcpPort", Type "DWORD (32-bit)", value "40299" (you can choose a port here, that's just a suggestion)
• HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc
  • Add key (folder): "Internet"
    • Add value: Name "Ports", Type "REG_MULTI_SZ", value "40200-40299" (you can choose a range of ports here, that's just a suggestion, but the DTC port should be within that range)
    • Add value: Name "PortsInternetAvailable", Type "REG_SZ", value "Y"
    • Add value: Name "UseInternetPorts", Type "REG_SZ", value "Y"

If you use a custom ports range, you have to create new rules to open that range specifically (inbound and outbound).

Here's a documentation about how to add firewall rules with the Powershell:

• Powershell New-NetFirewallRule (learn.microsoft.com)

Test-Dtc

You can use the Powershell module (or cmdlet) "Test-Dtc" to check if everything was configured correctly:

• Test-Dtc (learn.microsoft.com)

For an end-to-end test, you have to open an inbound port for the resource manager service created by this (3002 by default, but you can specify a different one).

DTCPing

Also, the DTCPing tool can be applied to test the correct setup:

• Trouble-shoot MSDTC connectivity issues (learn.microsoft.com)

A good thing about this program is that it makes you notice to use the involved machine's names instead of IP addresses.

Here's a link to a detailed article describing how to trouble-shoot MSDTC issues using the DTCPing tool:

• Trouble-shooting MSDTC issues with DTCPing (puneet-gupta.github.io)

The DTCPing program has to run on both the host and the client machine.