MSDTC through a firewall to an SQL cluster with RPC

You may also like...

13 Responses

  1. Jeremy says:

    Thanks useful information! Wish MS had this documented somewhere.

    I will be testing this out myself, not the cluster portion but the firewall and specific ports being required.
    This page cannot be viewed in IE for some reason Firefox only.

  2. Lewis says:

    Hi Jeremy, thanks for the feedback. I noticed it works ok in IE8 but does flag an error about parent and child elements. Not entirely sure what that’s all about but I’ll have a look.

  3. What I don’t understand is where those settings which I make using the GUI are being saved to…
    I have already scanned the registry several times for the the port numbers I have entered but they are just not there.
    I would have expected that even if the GUI does not create the very same registry keys as desribed in the article
    it would still save the values somewhere in the registry but that is clearly not the case…
    So is there maybe an INI file for RPC if yes where on the filesystem is it?…

  4. pls ignore by previous comment,
    i have now tried it on another server and now I see the corresponding keys & values in the server’s registry, maybe it was a kind of permissions issue in the first server’s case…
    my compliments for this great blog posting!

  5. Anonymous says:

    Good job with the article!

  6. Gina says:

    Great post! Just what I was looking for.

  7. CreepyC says:

    This is a fantastic article! I struggled in much the same way with this and it took me a good few days to finally get my head around it. But this is bang on! Wish I had this then.

    Good job Lewis! A*

  8. Adam says:

    Great article, I’m having this issue right now with a SQL Server 2005 test instance hosted on a Windows Server 2008 R2 cluster. I have two SQL Server 2008 R2 instances and one SQL Server 2005 instance on this cluster. My only question is, why don’t the 2008 R2 instances have problems communicating to the MSDTC but the 2005 instance requires the configuration change documented in your article?


  9. Tammy says:

    Great Article and enjoyed reading it

  10. Lewis says:

    February 2013 and I’m still using the information detailed here for SQL 2012 and Windows 2008 R2 communications. Am I glad I took the time to write this article 4 years ago!

  11. Jason Miller says:

    Thanks so much for this excellent resource! We used it late last night with “Great Success.” We also had to open up port 135 which began the communication between the servers. It seems that both source and destination are initiators, so the FW needed to be open both ways. Incoming Caller Authentication Required worked fine for us (Same domain, source: SQL2008R2 dest: SQL2000).

  12. F. Matin says:

    Great article and well written. I am a Firewall Engineer & this article helped with a few pointers. Therefore, I like to share this with you. On an enterprise FW, you don’t have to open those dynamic ranges of 1024 – 65535 or as above states 5000+ if you don’t want to. Much like FTP, as the FW knows, once the client connects to server via port 21, the server will ask the client, to connect once more via 20. The FW does this without the FW engineer configuring anything but a one line of access that allows TCP FTP. For DTCRPC to work In this same manner, the FW engineer must write a simple policy and only allow TCP 135 from clients to server. The server then dictates what port for clients to connect back (hopefully, via steps above, you modify this by opening 200 or so ports instead 64000+ ports). The FW then looks at the one line of allow to 135 and the policy and knows (as it does with FTP) to dynamically allow subsequent ports dictated by the server. without an issue.

  13. Some Guy says:

    And it’s still good!

Discover more from

Subscribe now to keep reading and get access to the full archive.

Continue reading