That is, until I came upon a blog by a woman named Irina Tudose, who went by "yrushka" on several technical forums. She did *not* leave out any steps! I included a link to her blog post in one of my own blog posts, because it made sense for me to not "reinvent the wheel" when she had already done it so well! I have even given out the URL to her blog post to other people that I've worked with when they needed to set up MSDTC. I'd really like to thank her!!
But today, while I was in the midst of writing a different blog post (which will be published soon), I realized that I needed again to include a link to Irina's blog. Unfortunately, it is gone (or hijacked) and the URL gets redirected to another other site (that MalwareBytes tells me is fraudulent).
Luckily, a little over 2 years ago, I had used EverNote to "clip" the entire page about DTC (and not clip the link) for just this reason! In case Irina's blog ever disappeared. I hope that she doesn't mind if I recreate it here (and, Irina, if you happen to find *my* blog, please let me know if you have moved your site elsewhere)!
https://web.archive.org/web/20160615025531/http://yrushka.com/index.php/sql-server/security/configure-msdtc-for-distributed-transactions/
Here is Irina's post, in its entirety:
Few days ago, inside a Software project, I had to enable and configure MSDTC (Distributed Transaction Coordinator) between 2 machines: a Web Server using NServiceBus to process messages in a transaction and a SQL Server.
I encountered some issues and I would like to detail the order of few configuration steps as well as testing methods that should be done/checked before MSDTC in fully functional.
Step 1: Network connectivity
Make sure both servers can ping each other by the machine name, cause MSDTC uses netBIOS to establish a connection.
Start a command prompt window and execute on both servers:
ping [SERVER_NAME1]
ping [SERVER_NAME2]
Step 2: Enable MSDTC on both servers.
There are pictures for Windows 2008 Server and Windows 2003 Server because MSDTC location is changed from one WIndows edition to another. The options to check are the same though.
- Open Component Services:
- Access DTC Properties
- Enable MSDTC according to below options selected.Check only the red check boxes and click Apply.
- Set the startup type of Distribution Transaction Coordinator Windows service to Automatic.
- Open Component Services properties windows
- Access Default Protocols tab and insert a new port range.
Windows 2003 - MSDTC location
Windows 2008 - MSDTC location
A warning message will be popped in to inform that the Distribution Transaction Coordinator Windows service will be started (or restarted).
If you don’t have Firewalls that prohibit external access to machine’s ports than you can stop here with the MSDTC configuration.
MSDTC will function great with basic configuration (Step 1 & Step 2) done only when there is no Firewall involved in network external communication. What do you do when there is a Firewall afterwards? In most Network configurations it is mandatory for securing the external access. If you follow all the steps detailed below, you should be able to make the MSDTC work without problems. Take a look at next steps.
Step 3: Restrict MSRPC dynamic port allocation.
MSDTC service depends on RPC protocol which stands in front of every Windows process that uses RPC. When you deal with MSDTC, you also have to consider the RPC access points. When MSRPC protocol is left with its default setting, all depending services including MSDTC is free to use a dynamically allocated port in the port range 1024-65535 . Basically, it means that each re-start of MSDTC will result in a different port number. Fortunately you can restrict this port range which means that, instead of creating a rule in Firewall that opens all the ports from 1024 – 65535 you only need to insert the range of ports restricted in RPC setting.
There is one thing to be considered though :
There can be up to 100 services that depend on RPC and will be affected by this change. Make it not too small… not to big. Doing a little reading on the internet I saw that 50 – 100 ports would be a minimum – maximum for RPC depending services to function, but again it depends on each machine and how many processes depend on RPC. If you want to find out which are these look at RPC service at Dependencies tab and count the active ones.
Perform these steps on both machines in order to configure a different port range. The port range does not have to be the same on both machines.
Next, in order to be able to start a Distributed Transaction through MSDTC service – both participating servers must be configured to trust each other by allowing access to the each other’s port used by MSDTC service.
Step 4: Add Firewall Inbound rules
on SERVER 1: to allow inbound requests to the port range configured.
on SERVER 2: to allow inbound requests to the port range configured.
This will enable the communication between SERVER 1 and SERVER 2 through MSDTC service.
SERVER 1 will be able to access MSDTC allocated port from SERVER 2 and SERVER 2 will be able to access MSDTC allocated port from SERVER1.
Step 5: Restart both machines
You need to restart both machines where the port range was changed in order for these modifications to take effect.
Step 6: Testing MSDTC connectivity
After you had done all of the above, you might want to test first if a Distributed Transaction can be initialized and committed. There are 2 important Microsoft troubleshooting tools that I used and worked for me: DTCping and DTCtester. I will not detail the testing steps because all of them are covered in
this post at step 2 and step 4.
Hi Bonnie,
ReplyDeleteGreat text, good reminder!
I know that this question of mine is not related to this text, but I am interested our opinion about WPF MVVM and will you write something on that topic as well?
Thanks
best regards
Sorry I missed your comment ... it's been a couple of weeks! Thank you for your input.
DeleteI haven't worked with WPF MVVM in many years, but I *will* tell you that MVVM is definitely the way to go when working with WPF. I don't actually feel comfortable right now writing a blog about it simply because I've been away from it for too long to write anything coherent about it.
I have only written one article years ago, and it wasn't really much about MVVM, but if you're interested it's here:
https://geek-goddess-bonnie.blogspot.com/2014/11/xaml-data-binding-faux-pas.html
This is a great bblog
ReplyDeleteThanks, Teresa!
Delete