Changing Microsoft Failover Cluster File Share Witness

I need to migrate my Microsoft Failover Clusters (FOCs) from one file share witness (FSW) quorum to another. Currently they point to a virtual machine (VM) running from an old site with a single rack mount server. This isn’t ideal and was only ever a temporary solution and now we are ready to move the VM to its new home in a proper datacentre with multiple hosts, SAN storage and far more resilient links. This new site has excellent connectivity to our 2 primary active-active datacentres and will be the permanent home for our witness.

I’ll cover the steps involved in creating a file share witness server and then the configuration of the clusters. As always you will find sections blanked out to hide sensitive information.

Acronyms FYI

  • FSW – File Share Witness
  • FOC – Failover Cluster

Note – This work was undertaken on Microsoft Server 2012 R2 FOCs, steps for other versions may vary. For example, Microsoft Storage Server 2012 will require you to set the quorum to a ‘NodeMajority’ to remove the FSW then you will need to configure the FSW. Commands below for reference

 

 

File Share Witness Server Configuration

I chose Microsoft Server 2012 R2 as the FSW operating system and ensured all necessary Windows updates were installed along with anti-malware protection and system monitoring by our SolarWinds platform. Once the standard setup was complete I moved on to the file share configuration.

We need to make sure the VM has the correct Windows Feature installed – in this case the File Server role.

We can quickly check the install state with PowerShell –

 

If the role was not installed we can make use of the Install-WindowsFeaure cmdlet

 

 

Or we can use Server Manager –

Server Manager

Once the role is installed we can check Server Manager for the ‘Shares’ option to begin configuration –

Server Manager

Click the ‘Tasks’ menu and select ‘New Share’

Server Manager

Select the ‘SMB Share – Quick’ option and click ‘Next’

New Share Wizard

Select the ‘Type a custom path’ radio button and then enter a file path for your FSW location. I would suggest naming the folder after the cluster name object which you are protecting. For example if your cluster name object is LAB-SQLFOC03 then name the folder as such, then click ‘Next’

New Share Wizard

Review the ‘Share name’ details and add a description if you wish then click ‘Next’

New Share Wizard

In my instance I didn’t create the folder in the path in advance so the system presented me with the message below asking me to confirm creation

New Share Wizard

Make sure you un-tick ‘Allow caching of share’ as we do not want this option enabled. I would also suggest selecting the ‘Encrypt data access’ option. This will ensure the file share leverages SMBv3 encryption for data in flight however you must be mindful that by default this will prevent any clients not running SMBv3 from connecting. For further info see the following MS article

New Share Wizard

The next screen will display the current permissions for our share – we need to modify these so click on the ‘Customise permissions’ option

New Share Wizard

Click the ‘Disable inheritance’ button

New Share Wizard

You will be prompted to either convert or remove the inherited permissions, choose to remove them all

New Share Wizard

You will see all the permissions now vanish, click on the ‘Add’ button so we can populate the required permissions

New Share Wizard

Click on the ‘Select a principal’ link

New Share Wizard

Type in the cluster name for the Failover Cluster you are creating. Using the example from above we would enter LAB-SQLFOC03. Make sure you click on the ‘Object Types’ button and select ‘Computers’. Failure to do so will mean the search doesn’t bring back the cluster computer object.

New Share Wizard

New Share Wizard

Click on the ‘Check Names’ button, in my instance I was asked to confirm which computer object I wanted to use, the cluster object and the actual nodes were presented. Make sure to select the cluster object and not an individual node

New Share Wizard

Select the ‘Full control’ basic permission and click ‘OK’

New Share Wizard

I also chose to add the local administrators group with ‘Full Control’ permissions, this isn’t necessary for the cluster quorum to work however it can be useful if I ever feel the need to dig into the folder without having to modify the permission later on.

New Share Wizard

I left the ‘Share’ permissions as ‘Everyone’ with ‘Full Control

New Share Wizard

Click ‘OK’ to close the permissions menu and apply our selected settings. The ‘New Share Wizard’ menu will display our chose settings, click ‘Next’

New Share Wizard

The wizard now presents us with a summary screen, we can click the ‘Create’ button to finish

New Share Wizard

The system will now implement the changes and we should see all tasks as ‘Completed’, click ‘Close’ to exit the wizard

New Share Wizard

We have now completed all the steps required on the FSW server so it’s time to move on to our Failover Clusters and configure them to point at this new location.

 

Failover Cluster Configuration

As I am migrating from one FSW to another I already have a quorum witness configured in my FOCs. If we look under the ‘File Share Witness’ option in the Cluster Core Resources we can see an existing witness setup.

Failover Cluster Manager

This is where things become interesting – if we try to remove the existing FSW the cluster will come back with an error.

Error Message

The cluster will let you add another FSW so you would see two of them listed however this isn’t what we want – so how do we remove the existing resource and add the new one?

We have two easy options – first use PowerShell to disable the use of a witness and secondly use the GUI ‘Configure cluster quorum settings’ wizard.

PowerShell – Set-ClusterQuorum

Using the set-clusterquorum cmdlet

 

GUI – Configure cluster Quorum Settings

Configure Cluster Quorum Wizard

Configure Cluster Quorum Wizard

Regardless of which method used, you should see the witness vanish from the Failover Cluster Manager MMC

Cluster Core Resources - Witness

Now that we have removed the old witness we can add the new one.

PowerShell – Set-clusterquorum

Use the set-clusterquorum cmdlet to configure a new FSW. The cmdlet is very simple, all we need to do is provide a file path and the name of the cluster.

 

GUI – Configure cluster Quorum Settings

Launch the wizard

Configure Cluster Quorum Settings

Configure Cluster Quorum Settings

Configure Cluster Quorum Settings

Configure Cluster Quorum Settings

Configure Cluster Quorum Settings

Configure Cluster Quorum Settings

Configure Cluster Quorum Settings

 

 

If we do a quick check we can see that the FSW folder for this cluster now has the relevant witness files.

 

 

Witness Files

 


That’s it – we now have our FSW setup and will add it’s vote to any cluster decisions. Remember we always want to have an odd number of votes in a cluster, if we have an even number there is the potential for a deadlock if half the cluster votes one way and the other half of the cluster another.

15 thoughts on “Changing Microsoft Failover Cluster File Share Witness

  1. Excellent article, Alex, thank you.

    One thing I didn’t see covered; perhaps it’s moot, but I’d appreciate knowing for safety’s sake.

    In a 2-node Hyper-V failover cluster where the VMs are balanced between both nodes for performance sake (half on each), when the first FSW is removed (immediately before configuring the new one), will the cluster crash, i.e. should I stop all roles on both nodes before switching the FSW?

    • Hi Robert,

      Thank you for the kind words. To answer your question – I ran this against many failover clusters in our production environment without any of them reacting in a bad way. I wouldn’t want to guarantee that you don’t have any problems, what version of Windows are you running? We have 2012 R2 deployed and the failover clusters I worked on were a mix of Hyper-V, SQL and file shares all running a 2012 R2 OS so it was a good mix. We are also running active-active datacenters with stretched clusters (20 miles apart) with the FSW probably 15-20 miles from each of those datacenters. I’d like to think if it worked without a hitch in that setup you’ll be fine but let me know more about your setup and we can take it from there.

      Regards,

      Alex

      • Hi Alex,

        Wow, quick reply, thanks! They’re two identical 2012 R2 commercial servers running in the same rack, both are up to level on all software and hardware service. I’ve gotten the same response from Microsoft, but I enjoyed your post in performing my due diligence, particularly the clarity of your writing style, so I figured no harm in getting your expert second opinion.

        Appreciate the feedback. I’ll proceed as outlined. I’m sure it will go well.

        Best regards,

        Robert

  2. Hello,

    we have created the FSW on scale out file server cluster. If the FSW is not continious available (recommended) the Hyper-V cluster becomes many problems. If the FSW is continious available it seems to work but i have read this ist not a supported solution. What is wrong?

    • Hi Andreas,

      Thank you for the question. Firstly I will answer as best I can but of course it is best to confirm with Microsoft for a concrete response. Now that my disclaimer is out of the way…

      Continuous Availability (CA) will mask the movement of a CA share between cluster nodes such that a client device will pause I/O and resume once the failover has occured. This prevents the traditional error messages we used to receive from being presented to the host and applications. It should be noted that CA requires SMB3 and the share to be set with CA. Disabling CA can result in a faster failover of the witness resource. When it is enabled it could take up to 90 seconds for the quorum timeout window to be reached. When disabled the failover would be immediate.

      I am guessing that you have problems when the FSW moves between cluster nodes and when CA is disabled the Hyper-V cluster will see the FSW as having gone down resulting in remediation action. When CA is enabled the cluster does not see the FSW go down, it just has a pause while it moves. I could of course be wrong so if you have more information on the setup I’d be happy to discuss further and hopefully get you to a happy place.

      Perhaps these articles will provide further information to aid you –

      Configuring a File Share Witness on a Scale-Out File Server
      https://blogs.msdn.microsoft.com/clustering/2014/03/31/configuring-a-file-share-witness-on-a-scale-out-file-server/

      Configure and Manage the Quorum in a Windows Server 2012 Failover Cluster
      https://technet.microsoft.com/en-us/library/jj612870.aspx

      Alex

  3. This is an excellent article. I had been searching for this for so long and nowhere is this configuration mentioned in such detail.
    Very easy to understand.

    Thanks for giving your time to explain everything with a screenshot.

  4. GM Sir, Great article by the way! I’m not sure if you are receiving my questions because when I come back to your site my question is gone. So excuse me for the same question over and over. I am about to through changing my file share witness to another file share server. When I remove or add a new file share will it require a reboot? Thank you!

    • Hi,

      Comments go through an approval and spam checking process – this can delay them from showing for a period of time. With regard to the witness role change requiring a reboot, no it should not require a reboot of any nodes for the changes to complete.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.