I respectfully disagree.  And, as the MSDN article that Tom provided
suggests, for a single-instanced SQL Server, leaving the MSDTC resource in
the "SQL Server resource group" is viable.

The most recent article, however, has striped the Cluster Resource group
"alternative" and has made compelling arguments for a dedicated resource
group.  Article dated November 1, 2006, revision 20.4.

Where do you get your information?

How to configure Microsoft Distributed Transaction Coordinator on a Windows
Server 2003 cluster
http://support.microsoft.com/kb/301600/en-us

Note When creating the MSDTC, moving the resource group into a group other
than SQL Server or Exchange Server group is highly recommended. Creating the
MSDTC resource in its own resource group and assigning it to a separate
cluster group keeps the resource highly available.

Note If you create the resource in the same cluster group, and if Resource A
has failed over, Resource B will also failover. When you create the resource
in a different cluster group, even when Resource A has failed over, the
resource B does not failover. Creating Cluster Resources in the different
cluster groups decreases unnecessary failovers of the Cluster Resources.

Important After the new group for MSDTC is created you must create the
Network Name, IP address and Physical Disk for Msdtc. You may already have
the physical disk resource that can be moved into the new group. After the
MSDTC Group is created you must create the IP address resource, Network Name
resource and the Physical disk resources. You may already have a physical
disk resource that must be moved into the new MSDTC group.

Sincerely,

Anthony Thomas

Just to play devil's advocate, there are some SQL scenarios that make heavy
use of DTC without using linked server queries or two-phase commits.  I
refer to ODBC transactions.  Since ODBC doesn't have pass-through
transaction support (remember, it was intended to abstract Jet/Access) it
uses the Microsoft Transaction Server interfaces, which are implemented via
DTC on a cluster.  So, if you have lots of ODBC clients, you can
inadvertantly have a high DTC throughput without meaning to.

Having said that, the original SAN problem that caused the KB article change
only happens in rare cases on certain hardware platforms, but to retain
hardware neutrality, MS made it a general recommendation.  They later backed
down and put the "light duty" words in the article.

And SQL 2005 supports mount points so disk drive letters are no longer sold
by the each and thus in limited supply

Play nice.

Russ,

not sure what horse died on you, I think I do not appreciating that remark :

To follow my logic, in my opinion people should follow Microsofts
Recommendation

"We recommend that you create the MSDTC resource in its own resource group,
such as you would for Microsoft SQL Server, where you can do so."

Clearly detailed in KB-301600
I am aware that this article has changed a bit over time and probably will
change over time, but it is clearly documented and Microsofts recommendation
at this moment.

I understand that there are reasons not to follow this, and I understand
that lite use of DTC will perfectly run in harmony with cluster resources in
the cluster group. As you said before "when done right", this will cause no
problems. I am fully aware that microsoft and its cluster team has fully
tested such scenarios, and that it is what they call "supportable". And I
have come accross many clusters with the DTC in the cluster group, without
any problems.

This, however, is not the point. The point is to give advice and help to the
community, which should be based on Microsofts recommendation.

For advice to the outside world, I, for one, will stick with KB-301600 for
the moment:
1) Microsoft Recommendation : create seperate group, where you can
2) lite usage : allowed in cluster group
3) dedicated Exchange cluster : should be in cluster group

Rgds,
Edwin.