Monthly Archives: April 2015

Steps for Installing SQL Server AlwaysOn Availability Groups

–by Ginger Keys

After you make sure you have everything in your environment ready to go and all the prerequisites that need to be done before deployment have been done, we are ready to install the AlwaysOn Availability Group!

The following steps need to be performed in this order:

  1.  Add Windows Failover Clustering (WSFC) to each replica (server)
  2. Configure WSFC on your primary replica
  3. Configure SQL Server on each replica
  4. Configure Logins & Replicas
  5. Install AlwaysOn

1. Add Windows Failover Clustering:

On each replica, open Server Manager > click Add Roles & Features > select Add Failover Clustering > click Install

Proceed through the wizard, and when you get to the Select Features page, select the Failover Clustering checkbox.

And if you don’t already have .NET Framework 3.5.1 or greater installed on your server, select that checkbox as well to install. (If you do need to install the .NET Framework, you will need to reboot the machine after installing).

Proceed next through the wizard and click Install to finish the wizard. You will need to do this on every replica in your AlwaysOn group. Blog_20150430_12. Configure Windows Failover Cluster (WSFC)

On your primary replica, open the Server Manager console > open Failover Cluster Manager

Click on Validate Configuration.


Add the names of all the SQL Servers you want to configure as replicas in your AlwaysOn group. Blog_20150430_3

On the Testing Options page, click Run all tests (recommended). It is normal to see some warning messages, especially if you decide to use shared storage.



After the validation and summary is complete, the Create Cluster Wizard will open.

In the Access Point for Administering the Cluster dialog box, enter the virtual cluster name (not the server or instance name), and the virtual IP address of your cluster.


Proceed next through the wizard, and your cluster will be created. The secondary nodes will be added to the cluster, and your cluster should now show up on all replicas (through Failover Cluster Manager). You don’t have to go through these steps on the other replicas…you’re all done with setting up the cluster.

3. Configure SQL Server

Assuming you have already installed SQL Server 2012 or 2014 Enterprise edition on all of your replicas, and have installed it as stand-alone instances, we are ready to configure SQL Server. On each of your replicas, open SQL Server Configuration Manager.

Expand the SQL Server Network Configuration node, and click on Protocols for MSSQLSERVER. You will see in the right panel of the dialog box the TCP/IP entry. Right click on the TCP/IP entry and select EnableBlog_20150430_7

While you are still in SQL Server Configuration Manager, right click on SQL Server Services to open the Properties dialog box.   Navigate to the AlwaysOn High Availability tab, and select Enable AlwaysOn Availability Groups checkbox. Blog_20150430_8

Restart the SQL Server Service after making these changes.

Do these steps on all of your replicas.

4. Configure Logins and Replicas

If it isn’t there already, add your SQL Service account (which should be a domain account – not the local machine service account) as a SQL login through SQL Management Studio (SSMS).

Add your SQL Service account to the Administrators group on each replica (via Computer Management)

Give connect permissions to the SQL Service account through SSMS: Right click on the SQL Service login to open the Properties dialog box. Navigate to the Securables page, and make sure the Connect SQL Grant box is checked. You will do this on every replica. Blog_20150430_9

Make sure all your replicas Allow Remote Connections. You can do this through SSMS in the instance Properties, or by using sp_configure.

EXEC sp_configure ‘remote access’, 1;




 Make any necessary adjustments to your Windows Firewall, to allow the replicas to communicate with each other.

Create a File Share (through Server Manager) that your SQL Service account and all your replicas can access with read/write permissions. This file share will be used for the initial backup/restore process that happens when your databases are joined to the AlwaysOn group during setup.   There are other options to join your databases to the AlwaysOn group, if you prefer not to create this temporary File Share. In fact, if your databases are large I would recommend using one of the other options, in which you would restore the databases yourself on all of the secondary replicas, instead of having the wizard do this step. We’ll look at that step in a minute…

5.  Install the AlwaysOn Availability Group

Make sure full backups have been run on each database.

Make sure all databases are in Full Recovery mode.

Remove these databases from any tlog backup maintenance during the installation of AlwaysOn (you can add them back later). You don’t want tlog backups happening on these databases while the AlwaysOn group is being created.

On your primary replica, open SQL Management Studio (SSMS) and expand the AlwaysOn High Availability folder. Right click on Availability Groups and select New Availability Group Wizard… to open the wizard: Blog_20150430_10

First, you will specify your AlwaysOn group name. Name it something descriptive and unambiguous: Blog_20150430_11

Next, you will select the databases you want to include in your AlwaysOn group. All of the databases in your instance will show up in this list…you don’t have to include all of them in your group… select only the ones to be included in the AlwaysOn group. Blog_20150430_12

Also, next to each database is a blue link that signifies whether your database is ready to be included into your group or not. If the link does not say ‘Meets prerequisites’, then you can click on the link to get a more in-depth explanation of what you need to do. Blog_20150430_13

Correct any discrepancies, and then select the databases to include in the AlwaysOn group: Blog_20150430_14

Next, is the Specify Replicas page where you will add the replicas to be included in your AlwaysOn group. Add and connect the replicas by clicking the Add Replica… button.

For each replica, you will need to specify whether you want Automatic or Manual Failover, Synchronous or Asynchronous Data Replication, and what type of Connections you will allow your end users to connect with. Blog_20150430_15

On this Specify Replicas page, there are several tabs at the top. The second tab is the Endpoints tab. On this tab verify that the port number is 5022. If you have more than one instance on your server, you might need to create another endpoint. Click here for further explanation:  Blog_20150430_16

Next tab is the Backup Preferences tab.   This is where you will choose where you want your backups to occur, and how you prioritize which replica will run your backups. Blog_20150430_17

The last tab in the page is the Listener tab. Here you will select the Create an availability group listener button.

Enter the DNS name, which is the name that will be used in your application connection string.

Enter port number 1433.

And enter the IP address for your listener. This should be an unused IP address on your network. Blog_20150430_18

Next page in the wizard is the Select Initial Data Synchronization page. Here is where you will join your databases to the AlwaysOn group. The Full option is the Microsoft default option, and is the one that uses the File Share.   The other two options (Join and Skip) are fine too, especially if you have large databases. With these other two options, you will restore the databases yourself, to each secondary replica.   But this example uses the Full option, so you will browse to and select the File Share created earlier. And remember the SQL Service account and all replicas must have read/write permission to the File Share. Blog_20150430_19

Next, ensure that your Validation checks return successful results. If you get any errors, you need to stop and correct these before proceeding. Blog_20150430_20

In the Summary page, verify that all your configuration settings are correct, and click Finish.


The Results page will show the progress of the installation. Verify that all tasks have completed successfully.   Because there was no quorum set up while creating the WSFC earlier, we are seeing a warning message here….this will not cause the installation to fail. Blog_20150430_22

After the results are complete, and everything has finished successfully, you can now see the AlwaysOn Availability Group created in SSMS:

The Availability Group Name: AGroup_Dev

All the Replicas, and whether they are primary or secondary

All the Databases included in the AlwaysOn group

And the Listener created for the group.

This AlwaysOn Group will also be visible on all of the replicas as well.


For more information about AlwaysOn Availability Groups, concepts, definitions, further explanations, or questions you may have…please contact us at We will be happy to help!

Prerequisites for Installing SQL Server AlwaysOn

-by Ginger Keys

Before implementing your AlwaysOn Availability Group, make sure you have everything in your environment ready to go. There are several prerequisites that need to be done to ensure a successful deployment. These prerequisites focus on your Windows environment, the SQL instances, and the databases to be included in your AlwaysOn group.


Windows Server 2008 R2. Windows Server 2008R2 is the minimum Windows Server edition allowed for deploying AlwaysOn. However, it is strongly recommended that you use Windows Server 2012 instead, as there are many issues and headaches associated with 2008R2. Click here for a more in-depth explanation:

Windows Server Failover Cluster. WSFC must be installed on every replica (primary and secondaries) in the AlwaysOn group. This is done through Server Manager > Add Roles & Features > Add Failover Clustering.

And each SQL Server that hosts an availability group replica must reside on separate nodes of a single WSFC cluster.

.Net 3.5.1 or greater. If .net 3.5.1 or greater is not already installed on your primary and secondary replicas, you will need to install this. This can be installed at the same time you install your Windows Failover Cluster (via Server Manager > Add Roles & Features > Add Failover Clustering):


Windows hotfixes. You need to install all available windows hotfixes on every replica prior to deploying AlwaysOn. This is particularly important if you are using Windows Server 2008R2, as most of the hotfixes are aimed toward that version.   Again, it is strongly recommended that you use Windows Server 2012 on all of your replicas instead. Here is a list of the available hotfixes at this time:

Windows Domain.   All replicas in your AlwaysOn group must be in the same windows domain. They must be able to communicate with each other.

No domain controller. None of your replicas can be a domain controller. AlwaysOn groups are not supported on a domain controller.

Windows Firewall. Most likely you will need to adjust your Windows Firewall setting to allow the replicas to communicate with each other.

Sufficient Disk Space. You don’t have to have identical hardware on each replica, but you do need enough disk space to hold all of your databases, and to account for the growth of those databases.   As your databases on the primary replica grow, the replicated databases on your secondaries will also grow the same amount. And if you have other databases on your secondary replicas that are not part of your AlwaysOn group, your disk space must account for the size and growth of those databases as well.

Sufficient Resources. Again, you don’t have to have identical hardware on each of your replicas, but you need to have sufficient resources on your secondaries to handle the same workload as your primary. If you’re thinking that “we’ll use our good, powerful server as the primary replica, and use the slower, weaker server as a secondary” with the thought that if we do have to fail over, we will just know up front that the performance will be a little slower while we get the primary server back up and running… well guess what. You’re right. It will be slower performance if you have to fail over. But it will also be slower if you don’t fail over! That’s because the primary sends transactions to the secondary, and with synchronous data replication, the primary has to wait for the secondary to harden the log before it can move on to the next task. So your primary will only operate as fast as your slowest secondary.   Your AlwaysOn group is only as fast and strong as your weakest link.   So be very familiar with your workload, and try and make sure your replicas are equally yoked.


SQL Server 2012 or 2014 Enterprise Edition. For testing or development purposes, you can install Developer or Evaluation edition, but for a production environment, you must install Enterprise edition. Standard edition will not work.

Database Collation. Databases in your AlwaysOn group must use the same collation…they cannot differ across replicas.

SQL Server Collation. All replicas in your AlwaysOn group must use the same SQL Server collation.

Active Directory Services. No replicas can run Active Directory services. This is not supported with AlwaysOn.

Database Mirroring Endpoint. Each instance needs a database mirroring endpoint. If you have more than one instance on your server, you will need to create an additional endpoint so the instances can communicate with each other. Here is instructions on how to do that:

SQL Service Account. Your account that runs SQL Services must be a domain account. Do not use the local machine service account. The SQL service account must be able to access every replica, and therefore must be a domain account.

Also, this account must belong to the Administrators Group on each of the replicas.

And this SQL service account needs connect permissions (given through SSMS). Right click on the SQL Service login to open the properties dialog box, go to the Securables page, and make sure the ‘Connect SQL’ Grant box is checked. Do this on all your instances:



Full Recovery Model. Make sure your databases are in Full Recovery Mode, not Simple or Bulk Logged. Also, these databases must be taken out of any tlog backup maintenance process while the AlwaysOn group is being created.

User database. Databases included in your AlwaysOn group must be user databases. System databases cannot participate in AlwaysOn Availability Groups.

Read/Write database. Read-only databases cannot belong to an AlwaysOn group.

Multi-user database. Databases must be in multi-user mode, they can’t be in single user mode.

Don’t use AUTO_CLOSE. Check the properties of your databases, and make sure this option is set to ‘False’.

DB in only one Availability Group. Databases may only belong to one availability group at a time. You can have more than one AlwaysOn Availability Group on your instance, but databases cannot belong to more than one group.

Not configured for database mirroring. Your databases cannot be enabled for database mirroring. Make sure this feature is not enabled.

Full Backups. Make sure full backups of each of your databases are made prior to installing AlwaysOn.

Allow Remote Connections. This can be done in SSMS either through the Instance properties, or by using sp_configure, which ever you prefer.

EXEC sp_configure ‘remote access’, 1;




More content here…

Steps for Installing AlwaysOn:


Features and Benefits of AlwaysOn Availability Groups

-by Ginger Keys

AlwaysOn is a great new feature in SQL Server 2012 and 2014 Enterprise edition. It has been described as the next evolution of database mirroring. AlwaysOn enhances the existing technologies of database mirroring and failover clustering to provide a strong layer of high availability and disaster recovery.

The way it works is that you have your production databases residing on a primary server (replica), and these databases are replicated over to secondary server(s). The databases on your secondary replicas are available to use in read only mode. With SQL Server 2012 you can have up to four secondaries, and with SQL Server 2014 you can have up to seven secondaries.


The following are some of the features and benefits of using AlwaysOn:

Combined HA / DR.   AlwaysOn provides both high availability and disaster recovery because you have live copies of your databases residing on several secondary servers. These are not just backups, but live, up-to-date copies of your databases that are usable in read-only mode.

Zero Data Loss Protection. AlwaysOn provides for zero data loss protection. This assumes that you are using synchronous data replication. Synchronous data flow is where the primary replica sends a transaction to the secondary, and it waits for the secondary to harden that transaction to the log before it (the primary) will move on to the next task. So your data is absolutely safe, even though there is some latency. You can also set up asynchronous data flow, which is where the primary replica sends a transaction to the secondary, but it does not wait for the secondary to harden the log…it moves on ahead to the next task. With asynchronous data flow, there is a possibility for data loss, but the transactions execute faster.

Failover of Multiple Databases. Databases in an AlwaysOn group will all fail over together. This is unlike database mirroring where the databases fail over individually. And it is also unlike failover clustering where the entire instance fails over.

Automatic or Manual Failover. You can set your AlwaysOn group to fail over automatically or manually. If you use automatic failover, you must also use synchronous data flow. If you are using asynchronous data flow, failover must be manual.

Local or Shared Storage. Unlike failover clustering, shared storage is not a requirement with AlwaysOn. And by not using shared storage, you remove your SAN or other shared storage device as being a possible point of failure.

Automatic Page Repair. This feature is available with AlwaysOn.

Active Use of Secondaries. The databases on your secondary replicas are not just backup copies, but usable for read-only tasks. You can query the data, and do your reporting on the secondaries.   And you can direct your end-user connections to specific secondary replicas to spread out the workload.

You can also do some of your maintenance tasks on the secondary replicas: full and log backups, and integrity checks.

Enhanced Performance. Because you can offload some of these read-only and maintenance tasks to the secondary replicas, the performance of your primary replica will be enhanced. Because a lot of these operations can consume a lot of resources, offloading them will optimize the performance of your primary replica.