I recently transitioned from SBS 2008 to a clean install of Server 2012 Essentials. Most things went smoothly, but one issue took a lot of work to resolve: on an XP development machine, I could read from but not write to the SQL 2000 server running on Server 2003.
I narrowed this down to an MS DTC issue fairly soon with the help of the messages I was getting:
- “New transaction cannot enlist in the specified transaction coordinator.”
- “Supplied provider is different from the one already in use.”
MS DTC also makes sense as the culprit since my app only invokes a transaction, and thus MS DTC, when writing data.
The primary MSKB article on the first error, 922430, didn’t help. The registry change just made it take longer to fail.
MS DTC tracing showed the transaction timing out on the client, but never connecting to the server. (MS DTC tracing is a bit hard to set up. See MSKB 899115, this StackOverflow question, and this MSDN blog post.) But DNS was okay, and the server’s firewall is disabled, so why couldn’t it get through?
Solved: Client Firewall File and Printer Sharing
After installing WireShark, I finally stumbled onto the problem: MS DTC was not able to use RPC because the File and Printer sharing exception was not open in the client computer’s firewall (Windows XP). Once I opened those ports (137, 138, 139, and 445), MS DTC was immediately able to communicate with the target server and the write transactions succeeded.
I have to admit this was unexpected—when outbound connections are not working, I know to check the firewall on the target computer, but I wouldn’t usually think about checking the firewall on the source computer.
This goes back to a group policy that I failed to copy from SBS 2008. The policy "Windows SBS Client – Windows XP Policy" opens File and Printer Sharing. I’ve now duplicated most of that policy’s settings in a new policy on my Server 2012 installation.
MSKB 306843 didn’t appear in my earlier searches, but is probably a better resource for this issue: How to troubleshoot MS DTC firewall issues.
That article does confirm that, "The firewall must be open in both directions for the specified ports." However, the dynamic port mappings that it recommends in the firewall do not seem to be necessary. For me, it works with msdtc.exe as a program exception, the File and Printer Sharing ports open, and none of the registry changes recommended in 306843.
Taken from: http://support2.microsoft.com/kb/306843
If RPC has failed in at least one direction (for example, from Server1 to Server2), direct your firewall administrator to make sure that the Internet Control Message Protocol (ICMP) is open in both directions.
It seems then that only the following two inbound/outbound rules apply…
File and Printer Sharing (Echo Request – ICMPv4-In)
File and Printer Sharing (Echo Request – ICMPv6-In)
Paul, thanks for your comment. Not sure about opening ICMP. Note that I was working with XP here. ICMP has its own protocol and though I didn’t add an exception for that on the XP machine, it must be open by default because I can ping the machine. The XP File and Printer sharing ports (137, 138, 139, and 445) are TCP.
I also have this working on Windows 8.1 now and all File and Printer Sharing exception rules are active (including ICMP), but that’s how I’ve configured it in group policy now so I don’t know if it would work with fewer active rules.