MSDTC and MSMQ - Brothers in Arms

I've just responded to a newsgroup poster asking how to avoid using MSDTC on a cluster. Their applications weren't using distributed transactions and they didn't want to have to provide another shared disk just for MSDTC.

On a cluster, there is only one instance of MSDTC so the MSMQ services (clusterised and local) cannot be dependent on it being up and running. It is  perfectly legitimate to have MSDTC down (because of failover) while MSMQ on the local node or in a different resource groups continue to run.

Should MSMQ require to perform some activity that needs a distributed transaction, such as sending or receiving a message in the context of a COM+ transaction (MQ_MTS_TRANSACTION or MQ_XA_TRANSACTION), then a call will be made to start the MSDTC service. If the service is unavailable then MSMQ will return an exception:

0xC00E004C   ( -1072824244 ) MQ_ERROR_DTC_CONNECT     Cannot connect to MS DTC.

So if you are not using distributed transactions then you should be OK.

Well, almost. This applies to standard MSMQ messages. If you try to install the following extra functionality on the local nodes, setup will complain.

 

To generate these errors, I ensured the local MSDTC services were stopped and removed the clustered MSDTC resource.

0x8004e00f means "COM+ was unable to talk to the Microsoft Distributed Transaction Coordinator."

You can't get round this by starting the local node's MSDTC service as that will fail. A local MSDTC service cannot be started on a machine configured to be part of a cluster.

So, in summary, MSDTC is required by MSMQ for any of its components that make use of COM+.