MSDTC - Confusing Recommendations from MS - Answer!!

I think I found the answer to this confusing recommendation (http://santhoshsivarajan.blogspot.com/2006/10/msdtc-confusing-recommendations-from.html)Even Microsoft was confused at one time. Here is the actual answer.

http://msexchangeteam.com/archive/2005/01/17/354497.aspx

”Here's where it gets interesting. Consider the characteristics of a typical, real-world Exchange 200x cluster server: heavily-loaded, never enough disk spindles, etc. If you follow this path of recommendations, now all of a sudden you need to add AT LEAST one extra IP, one extra network name, and one extra physical disk. Just to support this MSDTC resource that 99% of Exchange clusters only need for setup/upgrade purposes. If you have to choose between allocating this extra disk spindle to an underutilized MSDTC resource or to an under provisioned database store LUN, most Exchange design architects will choose the second!

Microsoft has long advocated the first option (dedicated group/disk/etc for MSDTC) as a best practice, since it maintains the cluster group containing the quorum disk untouched. Pretty much all of the documentation and KBs currently state this position. However, after a bunch of internal discussion and debate, this recommendation is about to change and the KB/documentation will be updated shortly.

So, if you have long ignored older recommendation and placed the MSDTC resource in the cluster group containing the quorum... you're fine. Exchange so minimally utilizes DTC that the performance hit and impact to cluster availability are negligible and generally not worth allocating the additional resources. Put that extra disk toward your Exchange data storage instead (see previous postings here, here, and here for more). Additionally, it is recommended that you remove (uncheck) the option to "Affect the Group" from this MSDTC resource, so that if it does ever fail it will not impact the cluster group containing the quorum resource.

Note that this recommendation change does NOT apply if you are running SQL or some other application that utilizes MSDTC extensively. If your MSDTC is being utilized, you definitely still should keep this resource out of the cluster group containing the quorum to avoid any possible negative effect on cluster availability”

Read More

MSDTC - Confusing recommendations from Microsoft

Following are the two separate "best practice" recommendations from MS regarding a MSDTC configuration for Exchange cluster:

According to Exchange 2003 Deployment Guide on page number 128

Note In Windows Server 2003, it is a best practice to create a separate cluster group containing the Physical Disk, Network Name, and IP Address resources (for example, MSDTC Group), and then add the MSDTC resource to that cluster group. Creating the MSDTC resource in its own cluster group helps ensure that a failure to the MSDTC resource does not affect the overall availability of your entire cluster or Exchange resources.

Note It is not recommended that you create the MSDTC resource in the default Cluster Group or the group containing Exchange resources.

According to KB Article # 301600 (http://support.microsoft.com/default.aspx/kb/301600)

Note 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. To do this, follow step 2 to create this new group. If you cannot do this, or if you have a light-use DTC scenario such as a cluster dedicated to Exchange Server, proceed and use the Cluster group. On dedicated Exchange Server clusters, the MSDTC resource should be placed in the default cluster group.

I believe it is very confusing. As per KB article # 301600 for Exchange the MSDTC "should" be placed in the default group. As per Exchange 2003 Deployment Guide "It is not recommended that you create the MSDTC resource in the default Cluster Group or the group containing Exchange resources." I can understand the light use of MSDTC for Exchange servers but I never came across a "shared" cluster for Exchange server. I believe it is another best practice recommendation (or industry recommendation) to use a "dedicated" cluster for Exchange. Anyone have any comments or thoughts on this?

Read More