[Cross post from StackOverflow]

Brent Ozar published this webcast (slides, video with free registration) entitled "Real-Life SQL Server 2012: AlwaysOn Lessons Learned", in which he repeatedly states, with varying degrees of force, that

using Windows 2008R2 with SQL Server 2012 Availability Groups is a bad idea

Among issues he raises are:

  1. Quorum recalculation (a feature of Windows Failover Clustering introduced in Windows 2012)
  2. Numerous bugs requiring Windows Hotfixes (list in AlwaysOn docs, "StackOverflow patch"), though I'm much less interested in problems that are fixed by bringing my deployment up to date.

He doesn't talk about other specifics of why using AGs with Win2008R2 is a bad idea, other than stating that AlwaysOn "pushes Windows clustering harder than any other app, and is uncovering breaking points". It is worth noting though that this is a supported configuration (AlwaysOn system requirements).

What problems have been seen in new deployments using SQL Server 2012 AlwaysOn Availability Groups with Windows Server 2008 R2, and are these eliminated by using Windows 2012? Are there problems seen in Windows 2008R2 that are fixed in Windows 2012 but do not have hotfixes available in 2008R2?

2 Answers 2


We have multiple customers using SQL Server 2012 with availability groups on Windows Server 2008 R2. The fixes listed in the pre-requisites for implementing availability groups needs to be applied for Windows to ensure that you don't run into known issues.


While I haven't run AlwaysOn in production on 2008 R2, I have experimented with a VM lab using 2008 R2 guests on 2012 Hyper-V. The only real issue I encountered was having to install hotfix KB2494036 to enable changing the node weight property of the cluster nodes. My test environment simulated three quorum-voting nodes in the primary facility, two of which were hosting SQL Server (with Availability Groups), and a fourth "off-site" non-voting node hosting a third replica of the Availability Group.

I threw a bunch of tests at it, like ungraceful power downs, fiddling with TDE settings, manually joining nodes to the AG, etc. and I at least wasn't able to make it break down in testing. There may be some edge cases where 2008 R2 clustering falls apart, but I wasn't able to uncover any while playing around.

However, if I were building a new production machine from the ground up, I'd probably use 2012 to be on the safe side, and avoid the manual hotfix patching.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.