Troubleshooting MSDTC Communication Checklist

Article
11/22/2011

Throughout this document you may refer to this diagram to help you see how the each step relates to the overall problem domain. At the beginning of each step the problem domain is specified:

Problem Domain (letter)

Verify the DTC Service is started and running as Network Service / Problem Domain: E.

Verify Network DTC Access is Enabled / Problem Domain: F.

Determine whether any local software or hardware firewall is enabled between any of the systems which will be performing a distributed transaction. / Problem Domain: B.

Verify if the customer has restricted RPC Ports / Problem Domain: J, K.

If the environment has any firewall enabled at any layer in the communications channel, please verify those settings against the Firewall Check List. / Problem Domain: B, M, L.

Verify each computer’s NetBIOS name and IP Address / Problem Domain: A.

Verify DTC Security Bindings / Problem Domain: I, F, G, H

DTCPing.exe Tests.

WinRM/RMClient Test.

Verify the DTC Service is started and running as Network Service / Problem Domain: E

1. Click on Start and then search and execute the View Local Services MMC

2. Find the Distributed Transaction Coordinator Service and verify that is started and running as the Network Service Account

3. Ensure the COM+ System Application is started and running as Local System

Verify Network DTC Access is Enabled / Problem Domain: F

1. Click Start, click Run, type dcomcnfg and then click OK to open Component Services.

2. In the console tree, expand Component Services, expand Computers, expand My Computer, and then expand Distributed Transaction Coordinator.

3. Right click Local DTC, and click Properties to display the Local DTC Properties dialog box.

4. Click the Security tab.

5. In the Security Settings section, click Network DTC Access. (This is required for Distributed Transactions from remote systems)

6. In the Client and Administration section, select Allow Remote Clients and Allow Remote Administration. (You do not need to perform this step unless another system will use your DTC as it’s won transaction manager)

7. In the Transaction Manager Communication section, select Allow Inbound and Allow Outbound. (This is required for Distributed Transactions from remote systems)

8. In the Transaction Manager Communication section, select Mutual Authentication Required (if all remote machines are running Windows Server 2003 SP1), select Incoming Caller Authentication Required (if running MSDTC in a cluster), or select No Authentication Required if some of the remote machines are pre-Windows Server 2003 SP1.

Determine whether any local software or hardware firewall is enabled between any of the systems which will be performing a distributed transaction. / Problem Domain: B

Some client machines have software which monitors and even blocks RPC traffic such as Symantec Endpoint Protection. It may be necessary to configure this software to allow the specific ports and applications to communicate over RPC.

To determine whether the Windows Firewall is enabled Open a Command Line and run the following order:

Verify if the customer has restricted RPC Ports / Problem Domain: J, K

Even if your customer is not using a firewall at all, it may still be a good idea to verify if the customer has RPC ports restricted. In some cases, a customer may try to restrict ports too far and end up in a scenario where transactions seem to randomly fail under load.
In a higher volume service, the RPC Endpoint Mapper may exhaust all available ports and therefore be unable to provide a service with a communications port, until another becomes freed.
How many ports should a customer use? That depends on how many they need. And to determine how many they require, the customer should run performance tests of their application and monitor the port usage; which is a topic beyond the scope of this troubleshooting guide.

1. Click Start, click Run, type dcomcnfg and then click OK to open Component Services.

2. Expand Component Services, Computers, and then My Computer

3. View the Properties of My Computer, select the Default Protocols Tab, and examine the properties for Connection-oriented TCP/IP

4. If there is an entry in the dialogue box for Properties for COM Internet Services, RPC port restrictions are in place. Take note of the range that is specified. You will need to verify that the firewall rules allow these ports specifically.

If the environment has any firewall enabled at any layer in the communications channel, please verify those settings against the Firewall Check List. / Problem Domain: B, M, L

Verify each computer’s NetBIOS name and IP Address / Problem Domain: A

1. Click on Start and then search and execute the cmd.exe.

2. Run the command ipconfig /all

3. Take note of the Host Name and IP Address of each machine involved in the distributed transaction. If it would help you, try out a simple chart like this:

4. If any NetBIOS name is greater than 15 characters in length, you must stop here and resolve this issue. Communications problems will occur between DTC partners who do not follow the recommended guidance around NetBIOS names.

5. Verify that each machine involved in the distributed transaction can ping its partner by Host Name and the verified IP Address is returned.

6. If any of the machines are unable to ping by Host Name, you must resolve this before continuing.

7. If any of the machines are returned an IP address which does not match the IP Address contained in the local IPCONFIG /all output, you must resolve this before you continue.

Often, you can work around WINS issues by using the local host file (c:\Windows\System32\drivers\etc\hosts) and adding (or removing if there’s an invalid address) the host name to IP address mapping. This may get you by the actual WINS issue the customer is facing but they will still need to investigate the name resolution issue (this particular subject is not in scope but here is a reference: Troubleshooting WINS ).

Verify DTC Security Bindings / Problem Domain: I, F, G, H

1. Click Start, click Run, type dcomcnfg and then click OK to open Component Services.

2. In the console tree, click to expand Component Services, click to expand Computers, click to expand My Computer, click to expand Distributed Transaction Coordinator and then click Local DTC (note: or select a clustered DTC instance if running within the context of a cluster system) .

3. Right click Local DTC and click Properties to display the Local DTC Properties dialog box.

4. Click the Security tab.

5. Configure the Security based on the customer's requirements: Rule: Match the binding for each partner. If Example: If Mutual Authentication is used on one side, use Mutual Authentication on the other.

6. It’s also important to remember that if you are propagating a transaction, you must “Allow Outbound” transactions. And, if you are accepting propagated transactions you must “Allow Inbound” transactions.

DTCPing.exe Tests

Use DTCPing to determine if a client may communication over RPC with another system running the RPC server component of the test (also DTCPing). The tool should be run against each partner in the transaction. NetBIOS names should be used; never use FQDN names.

You’ll notice that the DTCPing tool creates a file on each system in the directory it was executed from, which obtains useful information that will help you fill out our common questions and more (like the host file). It would be wise to get your hands on these files to make direct comparisons for your customer. Note: If you have trouble with the DTCPing tool, check out Troubleshooting MSDTC issues with the DTCPing tool

Start the DTCPing tool on both nodes. After both processes are up, you can select one system to start the test. Enter the remote server’s NetBIOS name and select Ping. If for any reason, you enter something invalid there or there’s an exception, you’ve got to restart the whole test. There’s no refresh button. Just be aware of this point when you’re testing. Here’s an example of two systems just prior to executing the DTCPing ping button:

WinRM/RMClient Test

WinRM is the tool which tests whether we can commit a transaction locally and remotely. Click here for a recap on the resource manager’s role in transactions. Most DTC scenarios will involve SQL and some other server. Make sure you execute WinRM on the servers accepting the transaction (if you don’t know, run this on every machine – when we get specific scenarios, you’ll have a better idea of which systems need to be tested). In this case I’ll assume that is the SQL machine. Execute WinRM and you’ll get a Windows form that looks something like this:

Afterwards, you can test a local transaction by opening a command prompt and running the RMClient.exe tool without any parameters. Doing so will attempt to commit a local transaction. If everything went successfully, you’ll see the following data on your screen:

To test whether remote transaction will work copy RMClient.exe to the partner machine and perform the same RMClient.exe test from a command prompt. This time though supply the “ -s” parameter for server_machine – the NetBIOS name of the SQL server which is running the WinRM.exe application already. If you are successful, you’ll see a very similar window on your client screen:

Download DTCPing and WinRM/RMClient DTCTOOLS