MSDTC changes in WS2008, Part 1: Introduction

Windows Server 2008 has a number of significant changes to MSDTC, addressing issues from performance, simplicity, and reach.  These changes are the culmination of a stream of work that began with Vista, and was heavily influenced by .Net from 2.0 onwards.

The changes in WS2008 had the following goals:

• Support the use of transacted NTFS and transacted Registry operations.
• Increase flexibility of deployment, predictability of performance in a Windows cluster.
• Improve the diagnostics available for troubleshooting.
• Be a 'good Windows citizen'.

Much of the visible changes to support transacted NTFS and registry operations showed up in Vista.  The changes in WS2008 are largely to support those features in a cluster.  I'll talk about them in passing as part of the overall cluster changes.

The biggest set of changes, by far, had to do with the cluster support.  This is what I'm going to focus on in parts 2 & 3.

Through WS2003, MSDTC could only have a single instance on a cluster.  This paralleled the single-instance-per-node assumption that holds for non-clustered systems.  However, it meant that entering a cluster meant that the local MSDTC was disabled, thus preventing it from completing any outstanding recovery.  It also meant that you could be very asymmetric performance patterns depending on where failovers had taken the recovery resource, such as a SQL server instance, and the MSDTC instance.  As you can imagine, you'd get much better performance when they happened to be on the same system vs. when they weren't.

In WS2008 the underlying assumption has been removed.  You can have any number of MSDTC cluster resources, they can be affinitized to other cluster resources (so that you can keep the transaction on the same system, regardless of failover patterns), you can retain the use of the local (per-node) MSDTC instances for those cases where the application is not cluster-aware, and you can split a cluster safely without requiring that all transactions be resolved.

Finally, there were two sets of changes that we made that should be considered largely internal.  One was a set of changes to unify and extend the advanced diagnostic tracing features that PSS would typically use when resolving a customer problem.  The other was a set of changes related to the quality and feature expectations for any component going into Windows.  Although neither should directly impact any customers, I'll touch on those in part 4.

Jim.