A quick glance at this page here Formal Reading for AAG is always a good start. This post would cover some of the more technical aspects involved. To begin with setting up the Windows Failover Cluster would be the initial task to be completed.

Windows Failover Cluster

Windows Server Failover Clustering (WSFC) cluster is a group of independent servers that work together to increase the availability of applications and services. SQL Server 2012 takes advantage of WSFC services and capabilities to support AlwaysOn Availability Groups and SQL Server Failover Cluster Instances.

Also ensure that the following Hotfixes are applied to your servers before heading down the WSFC path WSFC Hotfixes.

For the sake of this post, I will be using 3 nodes of Windows 2008 R2 SP1 Servers that have all the hotfixes above mentioned installed. They also have Windows Failover Cluster service running as well.


Validation Tests


Running the validation checks is quite important, as it would provide for a ton of information regarding your windows cluster, possible speed bumps for your deployment.

A sample validation report would look like below

It helped me resolve issues like this one http://wellytonian.com/2013/02/windows-failover-cluster-errors/


To setup a basic SQL 2012 Always On High Availability Mode, based on Node Majority / Vote Majority, you would need Odd number of Windows 2008 R2 SP1 servers running within the cluster. The various options of setting up the Cluster can be obtained by running the Configure Cluster Quorum Wizard. Basically the Wizard will go through the nodes and suggest the best configuration for your cluster. Since there is no Shared Storage with the cluster for this example, it suggested Node Majority as shown below

What it basically means is that the cluster could easily loose one server within the nodes and has its Services and Applications function as per their configuration.


Setting up the nodes is as simple as:

  1. Adding the nodes to the cluster.
  2. Getting the validation checks to run. If they are warnings, safe to ignore them but worthwhile to read through and make fixes if possible.
  3. Once the validation has been run, the cluster should start functioning.

This completes Part 1 of setting up SQL Always on High Availability.