Creating a Cloud Witness


Thanks for visiting!  The post for today is about configuring a Cloud Witness using Azure Storage. In today’s day and age, you always hear about High Availability and redundancy.  A Cloud Witness provides you with an option in Azure as a Quorum type. As a DBA, Quorum is just as important to me as my backup/recovery strategy. With a Cloud Witness, there is no need for another machine to provide Quorum.  No extra hard drives to purchase. No maintenance costs.  In short, no extra work on top of the configuration!  Once I configure it, I won’t need to check the space used/fragmentation/OS patches/etc.  This gives me back my already preciously short time to focus my efforts elsewhere.


I hope you enjoy and please let me know if there are any questions!


Scenario 1


In this scenario above, we see three Data Centers.  In Data Center 1, and 2, we have our SQL Servers(1 primary, and 1 secondary in each Data Center). In the third Data Center, we have our Quorum.  This, to me, is a solid configuration.  The reason for 3 Data Centers is so that Quorum can always be achieved.  By keeping the Quorum outside of Data Center 1, or Data Center 2, you remove the possibility of losing Quorum if the Data Center with the Quorum type goes down.  In this model, we have a 5 node WSFC(Windows Failover Cluster).  Our WSFC configuration consists of the following: 4 SQL servers(2 in each Data Center) and 1 Quorum Type(For our scenario, we will use FSW).

However, think of your overhead costs to maintain this type of configuration.  You have to have 3 separate Data Centers, space at each Data Center for the servers, network connectivity, OS costs, power, etc.


Scenario 2


In this scenario, this is what I see majority of the time when I first begin working with a client.  In the scenario above, we still see a 5 node WSFC(4 SQL Servers, and 1 FSW Quorum Type).  Now, let’s say a power outage strikes the area where Data Center 1 is located, and the entire Data Center goes dark(offline).  Well, your ENTIRE WSFC is down.  Most clients do not understand why that happens, and I always answer with, “It is simple arithmetic. 5-3=2”  5 is the number of nodes in your WSFC, 3 is the number of nodes lost when Data Center 1 went down, 2 is the remaining two nodes in Data Center 2.  Well, you lost majority of your nodes, not to mention your Quorum(In this case our FSW), the cluster is unable to run as there are not enough votes to keep the WSFC online.


Well, that is easy to fix, right?  Let’s just spin up a VM in Azure, and host the FSW on that machine.  Problem solved!  Technically yes, that is a viable option.  But, let’s consider the cost of that scenario in the breakdown below:

  1. VM with OS licensed and Disk space allocated for FSW
  2. NSG/Firewall to protect said resource from outside 
  3. VNET

Also, you have to figure in the man hours in configuring all of those things(Let’s say 4 hours total.  Insert your hourly rate here:  Rate x 4 = Setup fee for VM in Azure


Now, here is where Cloud Witness saves the day!  The Cloud Witness WSFC Quorum type will utilize BLOB Storage in Azure to act as the point of arbitration.  Not sure what that means?


Here is a brief explanation: Have you ever played Capture The Flag? Not where both teams have a flag, and you defend/attack until one team grabs the opposite teams flag and returns to their base with it.  No, our server are not constantly attacking one another or defending themselves from the other in order to achieve Quorum.  The Capture The Flag scenario I am referring to is when there is ONE flag placed somewhere, and both teams have to find said flag, and return it to their respective base first.  The team that does wins!  Well, with the scenarios above and below, the nodes that are able to reach the Cloud Witness in Azure “capture the flag”, or in technical speak, achieve Quorum.




With the configuration above, there is absolutely no need for the 3rd data center, no extra VM needed in Azure.  Your Cloud Witness gets to vote and it can participate in any of the Quorum calculations, while saving you money! Now, normally the technical aspects of the conversation are typically ignored, but once you say you can save some money, suddenly the ears in the room perk up.



Key points to drive when discussing using Cloud Witness in your WSFC Configuration:

  1. It is using Azure!  Microsoft is developing heavily into their Cloud platform and this is one of MANY features to come that will begin to allow a hybrid configuration to be easily configured!
  2. It’s using BLOB storage!  Why spend extra money on a server/disk somewhere else to setup exactly what you can with the Cloud Witness without all of the SLA’s/Guarantees from Microsoft?
  3. You can reuse the SAME STORAGE ACCOUNT for MULTIPLE WSFC’S!  A one-to-many relationship for all of my DBA/Data nerd friends out there.  I won’t have to beg and plead for another LUN/Disk/Server from the powers that be, I can simply utilize what is already available!
  4. It is pretty cheap money wise.  It does not write a ton of data, and it is ONLY updated once when cluster nodes state changes.  Focus on the first part of that sentence, here I will repeat it: It is pretty cheap money wiseWho DOESN’T like to save money!?
  5. This is now a standard feature in Microsoft Windows Server 2016, so it’s not a preview feature.  This means it is fully supported by Microsoft and it doesn’t cost you extra $$$ for turning it on!




Well Jim, this is great stuff, but can you show me how to set it up already and start saving me money!?  Absolutely, keep reading!


Let’s Build it!


Creating the Storage Account

To create a storage account to use as a Cloud Witness, perform the following steps:

  1. Enter a name for your storage account, I normally use something along the lines of clusternamecloudwitness(So, if my cluster name was, flipflops, I would set my storage account name to flipflopscloudwitness).
    Storage account names must be between 3 and 24 characters in length and may contain numbers and lowercase letters only. The storage account name must also be unique within Azure.
  2. For the Account kind, select General purpose.
    Blob Storage is NOT compatible with Cloud Witness.
  3. For Performance, select Standard.
    Azure Premium Storage is NOT compatible for a Cloud Witness.
  1. For Replication, select Locally-redundant storage (LRS).
    The WSFC uses the blob file for the arbitration point, of which there has to be some consistency guarantees when the data is read. So, the only option which allows that is Locally-Redundant Storage for the Replication Type.

See the below screen shot:

Once your Storage Account is created and available to view in the Azure Portal, you will see the following options once you select your newly created Storage Account(See below screenshot):



The section you want next is this one:


When I am configuring one of these, I always keep a notepad open to copy down the strings and keys that I will need for the WSFC setup.  Both of these can actually be found on the Access keys section of the Storage Account.  See the settings here:



When a Storage Account is created, they each get a URL like the following: https://<StorageAccountName>.<StorageType>.<EndPoint>


To see your unique endpoints and copy the URL’s easily, go to the Properties section and you see all of them(Primary Blob, Primary File, Primary Queue, and Primary Table endpoints).


Configuring the WSFC for Cloud Witness

Following the screenshots here, you should be able to follow along on how to configure the Cloud Witness in your WSFC.  The first thing to do is right-click on your cluster name, then choose More Actions, then finally select Configure Cluster Quorum Settings:

Once there, you should see the following screen:

Select the center option “Select the Quorum Witness”, and press Next.


On this screen below, choose the following option “Configure A Cloud Witness, then press Next.

On this last screen, configure it with the information below the screenshot:

Storage Account Name: Name of Storage Account being used for Cloud Witness

Azure Storage Account Key: When creating first time, use Primary Access Key.  When rotating keys, use your Secondary Access Key

Azure Access Endpoint: Normally, the default value here is fine. Unless you are in a different region such as China and the endpoint needs updated


If all is successful, you should see the Cloud Witness as Online in the Cluster Core Resources like the below screenshot:



Congratulations!  You have now configured a Cloud Witness for your Windows Server 2016 WFC.  Now, would you like to be able do it even faster next time?  Have you heard of PowerShell?  Of course you have!  You have probably also heard at how easy it makes many of these types of tasks.  So, in the spirit of helping you save time, and have some extra time for yourself, here is the PowerShell to create the Cloud Witness on your WFC.

DISCLAIMER: Cmdlets change ALL of the time!  Be sure to confirm cmdlet is still valid before running.  I take no responsibility for any failed executions of the PowerShell script below!

Run this on the primary node of your WSFC:


$StorageAccountName = ‘<StorageAcccountName>’ #The name of your Storage Account. Make sure the text is added inside of the quotes and you remove the <>.
$AccessKey = ‘<YourAccessKey>’ #Access key from the Azure Portal. Make sure the text is added inside of the quotes and you remove the <>.

Set-ClusterQuorum -CloudWitness -AccountName $StorageAccountName -AccessKey $AccessKey




This is how a Cloud Witness is configured for a Windows Failover Cluster.  I hope you found this informative and of course, if you have any questions/suggestions/issues please contact me!  Thank you for reading!



Be the first to comment

Leave a comment

Your email address will not be published.