Archive for the ‘SQL’ Category

SQL Server 2014 Create a New #SQL Server Failover #Cluster (Setup) in 5 minutes Source Files

When I started this blog post it was more a can I create a Fully cluster in 5 minutes and with 10 min extra a two node cluster and loaded with a two instance cluster. Well I could.

If I had better hardware SSD/fusionIO or other SMB 3.0 huge etc it would be much faster ( donations are Welcome  Winking smile ) Joking

I posted the vid on youtube and the blog and it seams it is not as common as I thought. no next next Finish Deployment.

As you already know deployments are time eating preparations.  But once you have it in place it rocks.

So I’ll place an update on the source files remember change the domain/user account server names

Old Source blog :

Get the ini files here  ( logon with your Microsoft Passport )

Watch this new video I made


In the source file there are image  Create SQL CSV Clustered instance and join other node to the instance.


image With the create cluster name IP , bind ISCSI etc and one Extra SQL install with out CSV also in 3 steps.


All the Files are there. just as an sample on how to do this.


Have Fun!


Posted July 10, 2014 by Robert Smit in SQL, SQL 2012, SQL Server 2014

Tagged with

AlwaysOn Availability Groups (SQL Server) Connecting To #Azure #part3 #AlwaysOn #winserv #SQL #msteched #mvpbuzz

As we did AlwaysOn FCI we make a step into the AlwaysOn AG. The Configuration options are divided with a lot of options. But the methods are the same. Pardon I did already a post

As there are a lot of extra options to extend your SQL server and give your DB the HA feeling. I hope the next post will give you insight in a how to get there. In a follow up post I will explain the Azure and extra options of SQL Server 2014.

AlwaysOn Availability Groups (SQL Server)

The AlwaysOn Availability Groups feature is a high-availability and disaster recovery solution that provides an enterprise level alternative to database mirroring. An availability group supports a failover environment for a discrete set of user databases, known as availability databases, that fail over together. An availability group supports a set of read-write primary databases and one to four sets of corresponding secondary databases.

Deploying AlwaysOn Availability Groups requires a Windows Server Failover Cluster. To be enabled for AlwaysOn Availability Groups, an instance of SQL Server must reside on a Windows Server Failover Cluster node, and the Windows Server Failover Cluster and node must be online. Furthermore, each availability replica of a given availability group must reside on a different node of the same Windows Server Failover Cluster.

AlwaysOn Availability Groups supports cross-cluster migration of availability groups for deployments to a new Windows Server Failover Clustering. A cross-cluster migration moves one availability group or a batch of availability groups to the new, destination WSFC cluster with minimal downtime.

By implementing AlwaysOn SQL Server FCI an availability replica can be hosted by either a standalone instance of SQL Server or an FCI instance. Only one FCI partner can host a replica for a given availability group.

AlwaysOn Availability Groups does not depend on any form of shared storage. However, if you use a SQL Server failover cluster instance (FCI) to host one or more availability replicas, each of those FCIs will require shared storage as per standard SQL Server failover cluster instance installation.

You might need to configure a Windows Server Failover Clustering (WSFC) cluster to include shared disks that are not available on all nodes. For example, consider a WSFC cluster across two data centers with three nodes. Two of the nodes host a SQL Server failover clustering instance (FCI) in the primary data center and have access to the same shared disks. The third node hosts a stand-alone instance of SQL Server in a different data center and does not have access to the shared disks from the primary data center. This WSFC cluster configuration supports the deployment of an availability group if the FCI hosts the primary replica and the stand-alone instance hosts the secondary replica.


AlwaysOn Availability Groups

I already had my cluster in place with the SQL AlwaysOn FCI and I have also installed a Second Cluster and a Second Instance on the cluster and already extended the SQL site to Azure and with several standalone server.

Before we start we need to enable the AlwaysOn HA option in on the server this is only done on the running server and is cluster aware. One setting for all the nodes for the same instance!

When we tried to enable the AG it is grayed out. in the SQL management.


Go to the SQL Server Configuration Manager

image image

When you are connecting to the passive node on the cluster you will see this, on a standalone install you can only connect to the active node.

Go to the other node and Set this setting. You can only change this setting on the running node that hold the SQL server

image  image

Now that we enabled the AlwaysOn Availability Groups we can start the wizard in SQL

image Pick a name for the AG


I just created a dummy DB just to set this up and I will later Add the real DB.

The dummy DB needs to have a full Backup ! So If your DB is as large as a TB a full backup is needed.


This is a interesting Screen Lots of Options and also Connections To Azure.

First we do a on premise connection and build a Replica to Azure.

and make a choice “ add Replica “  When we select the add replica a SQL login screen will popup.

 imageRemenber you need to connect to the replica SQL server.

This server is my standalone instance but installed on a failover cluster.

and as you can see I connected My Cluster SQL Server with the CSV installation now to a local SQL instance installed on Cluster Node 4

Some basics you need to know when connecting :

  • All the cluster nodes must be in the same Active Directory Domain Services (AD DS) domain.
  • Each availability replica in an availability group must reside on a different node of the same Windows Server Failover Clustering (WSFC) cluster.

  • The cluster creator must have the following accounts and permissions:



The Chosen Server is selected and added to secondary. In a cluster there is no automatically failover!

Readable secondary: No
In the secondary role, this availability replica will not allow any connections. I’ll use this pure as a backup and no changes will be made in the backup location. If the cluster is failing I have more problems than a not working Application.

All the options can be set but If you have multiple instances (AlwaysOn FCI ) and installed a local standalone Instance You may need to change the Endpoint Port! the default is 5022. I changed the port to 5023 just to make sure that there is no problem on my server.


Changing the port is easy “ SELECT * FROM sys.tcp_endpoints “  will show you the ports.


With “ ALTER ENDPOINT [hadr_endpoint] AS TCP (listener_port = 5023) “ you change the port to a better one.



Normally If you run this wizard and doing this steps you are fine, but in my demo site I had already a connection to Azure and therefor my listener want not only a local IP but also an Azure IP as described in the error message.

But this error is not saying he you need to do this again no simple add an IP address to your listener  You can Add this by hand or create listener in SQL




As you could see I needed to add a second IP for my listener that is I already setup a failover to azure.

In the fist step we could choose Azure Replica or a replica

image  And I dis the Azure Replica and If you are not already connected and added the thumbprint to your SQL server then you need to do this.

Just click Download and the Azure Login will popup and you need to login with the Azure Admin account that can create the Azure VM


image  When check the down the Azure login screen will pop up



a quick connection screen will popup and does fill in your subscriptions. If you have multiple just pick the right one.

So after connecting and downloading you will have the following. Reminder there is only creating NEW VM available ! If you want to use an existing VM then use the add replica just as in a normal situation.


The bad thing is here you can not pick a SQL server that already is build. But in the Screenshots you will see this is much easier. But it would be nice to tweak this a bit. It Would be handy if you could also pick an existing VM.

After filling in my name and version Size We can go to the next step. keep in mind you can always lower the size of the VM but now it is faster and the setup process will be quicker.


As you can see the Azure Replica server is added.


As I connected the Azure SQL with a Azure Gateway to my LAB environment we can share files thru the domain.


The wizard kick in and we have to wait until it is done. I did not create a listener for this, I just want to replicate the data to Azure.


Real Pity that there is no export to script I would like to see the script that created my azure SQL VM


The progress screen an this can take a while. With a quick peek in Azure We can see this.


This is a Critical Point I have done this now several times and sometimes it fails in a time out , and I found out that I used most of the time a small server and then the script will fail with “Error” so a quick tip use the default size and adjust this after the creation.

Checking the VM 4 cores and with an extra disk from 1TB holding my DB


My Lessons learned

As you can see there are multiple disks and the Wizard has run successfully.

My source was clustered and the DB is running on a CSV. Witch s a bad choice for running a Replica. The reason is the Replica wizard want to see the same disk and placing the DB files on C is no problem but a CSV volume placed  C:ClusterStorageVolume1MSSQL12.MSSQL001MSSQLDATA

and this path is available for every cluster node and therefore also in the Azure cloud. and the “ normal” wizard tells me he the DB is already there. but now this step is skipped.

Second mistake I used a sample DB. there is no way I can add a second DB because of the CSV problem “ Database is already there “ and this is the Source DB Winking smile I think this will be better in the next version. Or not using CSV with AlwaysOn AG


Now that the wizard is done and a lot of scripting is passed the line to azure. But what is changed and does it work ?


no votes and an extra node image

The replica is created and as shown in the dashboard replicated.


The Following Issue can happen when you use CSV and or you want to create a replica from FCI to FCI. The reason is the disk letter need to be the same on source and destination, as the CSV volume is mounted to every node and therefor the DB is already there and the setup will fail.


image image


Right I use CSV but is the CSV replicated to Azure Yes the cluster does this! But there is no disk mounted in azure and all the files will be placed on the c drive! and the replica can not be created on the location because the source DB is there. If you create the replica by hand you can do this but not by default with the wizard.  just a reminder when you playing with this.


There are some options when you enable AlwaysOn the easiest way is having standalone SQL server running on a cluster node. More advanced is using AlwaysOn FCI. But all this can be done just test everything before you go in production . So that you know how your configuration is working.

And just because you can will not say this is your best solution or design. There are many options and will grow are products evolve.


SQL Server AlwaysOn Availability Group concepts

A SQL Server Availability Group enables you to specify a set of databases that you want to fail over together as a single entity. When an availability group fails over to a target instance or target server, all the databases in the group fail over also. Because SQL Server 2012 can host multiple availability groups on a single server, you can configure AlwaysOn to fail over to SQL Server instances on different servers. This reduces the need to have idle high performance standby servers to handle the full load of the primary server, which is one of the many benefits of using availability groups.

An availability group consists of the following components:

  • Replicas, which are a discrete set of user databases called availability databases that fail over together as a single unit. Every availability group supports one primary replica and up to four secondary replicas.

  • A specific instance of SQL Server to host each replica and to maintain a local copy of each database that belongs to the availability group.

Replicas and failover

The primary replica makes the availability databases available for read-write connections from clients and sends transaction log records for each primary database to every secondary replica. Each secondary replica applies transaction log records to its secondary databases.

All replicas can run under asynchronous-commit mode, or up to three of them can run under synchronous-commit mode. For more information about synchronous and asynchronous commit mode, see Availability Modes (AlwaysOn Availability Groups).


Database issues, such as a database becoming suspect due to a loss of a data file, deletion of a database, or corruption of a transaction log do not cause failovers.

Read the following articles to learn required and important concepts about SQL Server AlwaysOn technology:

  • For details about the benefits of AlwaysOn Availability Groups and an overview of AlwaysOn Availability Groups terminology, see AlwaysOn Availability Groups (SQL Server).

  • For detailed information about prerequisites, see Prerequisites, Restrictions, and Recommendations for AlwaysOn Availability Groups (SQL Server). This article contains the following information:

    • Windows Server system requirements and recommendations

    • SQL Server instance prerequisites and restrictions

    • Prerequisites and restrictions for using a SQL Server Failover Cluster Instance (FCI) to host an availability replica

  • Availability group prerequisites and restrictions

  • Availability database prerequisites and restrictions

Posted May 23, 2014 by Robert Smit in SQL, SQL Server 2014

Tagged with ,

AlwaysOn Failover Cluster Instances SQL Server 2014 in #part2 #azure #winserv #SQL #msteched

As described in the other post AlwaysOn Options the First AlwaysOn option is the FCI version.

AlwaysOn Failover Cluster Instances (SQL Server)

Failover cluster instance (FCI)  is in short the old active/passive configuration – Protection level SQL Server / instance

As part of the SQL Server AlwaysOn offering, AlwaysOn Failover Cluster Instances leverages Windows Server Failover Clustering functionality to provide local high availability through redundancy at the server-instance level—a failover cluster instance (FCI).

An FCI is a single instance of SQL Server that is installed across Windows Server Failover Clustering nodes and, possibly, across multiple subnets. On the network, an FCI appears to be an instance of SQL Server running on a single computer, but the FCI provides failover from one Windows Server Failover Clustering node to another if the current node becomes unavailable.

Building the Basic Cluster

The Basic is a Cluster based on Hyper-v with the shared VHDX option. So starting with a PowerShell script that Creates a Two node Cluster and with a file share witness. You can easily change the PowerShell script and use this in your own environment.  ( Make sure when you grab the script the “ are correct. )

#Install cluster options
Get-WindowsFeature Failover-Clustering
install-WindowsFeature “Failover-Clustering”,”RSAT-Clustering” -IncludeAllSubFeature
#Create cluster validation report
Test-Cluster -Node mvpsql141,mvpsql142
#Create cluster
New-Cluster -Name MVPSQL1401 -Node mvpsql141,mvpsql142 -NoStorage -StaticAddress “″
#Add disks to the cluster
Get-ClusterAvailableDisk -Cluster MVPSQL1401
Get-ClusterAvailableDisk -Cluster MVPSQL1401 |Add-ClusterDisk
#Add disk to CSV
Add-ClusterSharedVolume -Cluster MVPSQL1401 -Name “Cluster Disk 1″
#Set Cluster Quorum
Set-ClusterQuorum -Cluster MVPSQL1401 -FileShareWitness \mvpdc01cluster
#set network configuration
(Get-ClusterNetwork “Cluster Network 1”). Role =3

(Get-ClusterNetwork “Cluster Network 2”). Role =1


Remember this is a Lab environment

Now that the Cluster is up and running we can start with the next steps.

AlwaysOn Failover Cluster Instances (SQL Server)

This Cluster will be the basic of all SQL installations. Speaking off SQL Installations I use only 2014 SQL servers and guess what it has new options that I will show you later.

AlwaysOn Failover Cluster Instances (SQL Server)

Well now that the cluster is ready we will deploy SQL 2014 ENT to the cluster, everybody can follow a wizard So we do as usual a Command line install based on ini files. This works the best and the result is always the same. But you can use also VMM or SCCM to do this.

First I use My SQL Ini files, If you don’t have the ini files no problem You can easily create them during the SQL setup. But if you install only one SQL server there is no point of doing this. Only just because you can Winking smile

And If you want to install this by Gui Fine just remember, I always install in advanced mode If one step is failing I can rerun the second step without the long wait of installing the whole server. Setups are always failing at the end.

AlwaysOn Failover Cluster Instances (SQL Server)

When running these steps at the end there is a location where the ini file is stored. copy the ini and put it on a save spot.

In my case I use c:SQL

There is only one thing that you need to change UIMODE="Normal" you need to turn it off by placing “ ; “ or delete the line we do not do a UI setup

And if you don’t like the interface is showing what the setup is doing then turn this off also. I like to watch so that my boss is thinking I work hard.

; Parameter that controls the user interface behavior. Valid values are Normal for the full UI,AutoAdvance for a simplied UI, and EnableUIOnServerCore for bypassing Server Core setup GUI block.


; Setup will not display any user interface.


When the ini files are in place remember you need 3 ini files

Step 1 : SQL server Advanced Cluster Preparation

Step 2 : SQL server Advanced Cluster Completion

Step 2 : SQL server Join Cluster Node

I mounted the ISO to the Cluster nodes and run this batch file on the first node. As you can see the password is in the file and unencrypted. You can be prompted for this but as this is a how to it is not important right now.

After this is done you will have a One node SQL instance.

AlwaysOn Failover Cluster Instances (SQL Server) 


Add A second node To the SQL FCI

The Second step will be running the step3 script Adding the Second node to the Cluster.

And Again I do this by Command line But Did you know there is an option in the setup UI that you can use INI files during the setup ?

AlwaysOn Failover Cluster Instances (SQL Server)

When using this the setup is not unattended but all the values are used in the ini file. So it is a NEXT NEXT FINISH install this could be handy if you want to change something.

AlwaysOn Failover Cluster Instances (SQL Server) AlwaysOn Failover Cluster Instances (SQL Server) 

Or run the Command line below the join the node to the SQL Instance.


After these steps the SQL AlwaysOn Failover Cluster Instances is ready.


But there are no disks yes that is right in SQL 2014 you can use Cluster shared Volumes (CSV) this is a new feature of SQL server 2014


If you want to see the installation Steps I created a movie with about the same steps. the whole Process creating and install SQL in just 15 Minutes. not fully untended just for showing you what is possible.

Next part will be AlwaysOn Availability Groups (SQL Server) With a connection to Azure

Posted May 15, 2014 by Robert Smit in SQL, SQL Server 2014

Tagged with

  • Tag