Configuring a File Share Witness on a Scale-Out File Server

Configuring a File Share Witness on a Scale-Out File Server

Rate This
  • Comments 14

In this blog, I am going to discuss the considerations for configuring a File Share Witness (FSW) for the Failover Cluster hosting your workloads, on a separate Scale-Out File Server cluster. You can find more information on Failover Clustering quorum here.

File Share Witness on a Scale-Out File Server

It is supported to use a file share as a witness that is hosted on a Scale-Out File Server cluster. It is recommended that the following guidelines be considered when configuring your File Share Witness on a Scale-Out File Server:

  • Starting in Windows Server 2012 R2, the recommendation is to always configure a Witness for your cluster. The cluster will now automatically determine if the Witness is to have a vote in determining quorum for the cluster.
  • Create a new Server Message Block (SMB) share on the Scale-Out File Server for the exclusive use of a cluster. Note that the same share can be used for multiple clusters.
  • Ensure that the File Share has a minimum of 5MB provisioned per cluster it is used for.
  • The Scale-Out File Server hosting the file share to be used as a quorum witness should not be created within a Virtual Machine hosted on the same cluster for which the File Share Witness is being created. 
  • Multi-site stretched-clusters:
    • With the Service Level Agreement (SLA) of automatic failover across sites, it is necessary that the Scale-Out File Server backing the File Share Witness be hosted in an independent third site. This enables sites with nodes participating in quorum equal opportunity to survive in case a site experiences a power outage or WAN link connectivity breaks.
    • With the SLA of manual failover across sites, we still recommend that the Scale-Out File Server backing the File Share Witness be hosted in an independent third site. This simplifies the recovery steps necessary in case of a primary site power outage. You may also configure the Scale-Out File Server to be hosted in the primary site. However note that this would require recreating the quorum witness while recovering the cluster from the Backup Disaster Recovery site.
  • Create a non-CA file share for the witness on the Scale-Out File server. A non-CA file share can result in a faster failover of the file share witness resource in the event the Scale-Out File server cluster is unavailable. For a CA share, the file share witness resource may not experience an immediate failure and may only timeout after the 90 second quorum timeout window. On a non-CA share, the file share witness resource will fail immediately, triggering remedial actions from the cluster service. Setting up the configuration for a non-CA share is explained in the next section. 
  • The Scale-Out File Server hosting the File Share Witness should be a member of a domain in the same forest as the cluster it is a Witness for. This is because the Cluster uses the Cluster Name Object to set the permissions on a folder in the share containing the cluster specific information. This ensures that the Cluster has appropriate permissions needed to maintain appropriate cluster state in the share. Additionally, the cluster administrator configuring the File Share Witness needs to have Full Control permissions to the share. This is necessary to set the permissions for the Cluster Name Object to the folder in the share.
  • It is important that the file share created on the Scale-Out File Server is not part of a Distributed File System (DFS) Namespace. The cluster needs to be able to arbitrate a single point for quorum.


Configuring a File Share Witness on a Scale-Out File Server

In this section, I will explain how you can create a file share on a Scale-Out File Server that will act as a witness for the cluster hosting your workloads. Therefore, you have two clusters – a “storage” cluster hosting your file share witness and a “compute” cluster hosting your highly available workloads.

You can configure a File Share Witness on a Scale-Out File Server as follows:

1)      Create the Scale-Out File Server as described in Section 2.1 of this article

2)      Create a File share on the Scale-Out File as described in Section 2.2 of this article.

a.       Modify the properties of the share to make it a non-CA share. Right-click on the share, select Settings and uncheck the Enable continuous availability checkbox.


b.      Ensure that you have Full Control to the newly created share. 


3)     Configure the File Share as a Witness on your cluster

a.       Using the Failover Cluster Manager 

i.     Type cluadmin.msc on an elevated command prompt

ii.     Launch the Quorum Wizard by Right-clicking on the Cluster Name, Selecting More Actions and then selecting Configure Quorum Settings                

iii.     Select Next and then choose the Select the quorum witness option and select Next.   


iv.     Choose the Configure a file share witness option and select Next.


v.     Specify the path to the File Share on your Scale-Out File Server and select Next.


b.      Using Windows PowerShell

i.     Open a Windows PowerShell® console as an Administrator

ii.   Type Set-ClusterQuorum –FileShareWitness <File Share Witness Path>


You should now see the File Share Witness configured for your Cluster.


When you navigate to your File Share Witness share you will see a folder created for your Cluster.


This folder will have permissions for the Cluster Name Object of your “Compute” Cluster so that the entries in the folder can be modified on Cluster membership changes.


You will also notice a file Witness.log which contains the membership information for the Cluster.


You have now successfully configured a File Share Witness on a Scale-Out File Server, for the cluster hosting your workloads.



Subhasish Bhattacharya

Program Manager

Clustering and High Availability


Leave a Comment
  • Please add 8 and 5 and type the answer here:
  • Post
  • Hi, this guide helped me a lot. However i am experiencing a problem with my fileshare witness. My cluster keeps reporting a warning 1562 and error 1069: "Cluster resource 'File Share Witness' of type 'File Share Witness' in clustered role 'Cluster Group' failed."

    It happens every couple of hours, but it seems that the virtual machines running of other shares have no problems. So i am hoping its not a problems with the SOFS cluster.

    Have you experienced this before? and is the non-CA option involved?

  • Same problem as Max's in my place. Any idea?

  • Hi Max and Mixer,

    If the SOFS cluster is functional and only the FSW is hitting issues, then this is most likely due to inappropriately configured Permissions.

    Which OS version was this configured on? How was the FSW configured (ex: FCM GUI or PowerShell)?

    When using FCM GUI, the CNO is automatically given permissions on the share (assuming the logged in user has permissions on the share). However, this is not the case when configuring with PowerShell.

    Try to give the CNO full permission on the Share & File System under the share. If configured with PowerShell attempt to reconfigure the FSW using FCM GUI.



  • I manually created the file share, gave domain admins full control (removed everyone from the file security). Created the File Share Witness and it failed.

    The CNO had been assigned to the file permissions, but it had no rights. Gave the CNO object full control at the file level , re-ran the file share wizard and the witness was successfully created

  • Hello Subhasish:

    We have 2 data centers .  to setup the SOFS  how storage needs to be clustered is it data center specific or non shared storage like always-on..

  • Hi Sri, The following technet article provides the information you are looking for:

  • Same issue as Max and MIXER.  All nodes and CNO have full control over share and file system, so don't think it's a permissions configuration problem.  Tried both FCM GUI and PowerShell.

    All servers running 2012 R2 Datacenter with the December 2014 UR.

  • This is great and helped me out while I try and tune everything. I currently have it configured for Continuous Availability. I was going to configure another volume/share for this but I noticed I can just remove the "Continuous Availability" check mark (like 2a) which would save me time, but do you see it causing any issues with the currently configured cluster witnesses that are already configured on that CA share?


  • Hi John, This would not have an impact on the clusters currently using the share as a FSW.

  • Subhasish,

    We have a SOFS/Hyper-V cluster that's constantly flagging 1562 and 1062 on the Hyper-V side plus when we go to reboot one of the Hyper-V nodes we get a 1561 for the rebooted node "cluster service determined this node does not have the latest copy of cluster configuration data".

    Permissions were verified and verified yet again for the FSW at all levels.

    OS is 2012 R2 across both pairs of nodes.

  • Thanks Philip for reaching out. What you are observing is the “Partition In Time” scenario for quorum.

    It seems that the timestamp updated in FSW is newer than the copy of the cluster database stored on the local node that you are starting.

    Consider a scenario:

    Node 1, Node 2 & FSW

    a. Node 2 goes down (T1)

    b. FSW & Node 1 stay up because they have quorum vote (T2 – timestamp updated with latest cluster membership)

    a. FSW has T2 timestamp, Node 2 has T1 timestamp, Node 1 has T2 timestamp

    c. Node 1 goes down (causing cluster to go down)

    d. Admin tries to start Node 2 with FSW (assuming enough votes)

    e. Node 2 recognizes that FSW has T2 which is later than T1 within its own copy of cluster database

    f. Cluster service on Node 2 does not start because that would lead to the loss of any changes done on Node1 (when Node 2 was down)


    Either try starting all the nodes in your Hyper-V cluster (there by including the node which has the latest copy of cluster database).

    Or simply override quorum manually to recover from this situation by running:

    On exactly one node:

    Start-ClusterNode –Node <name> -ForceQuorum

    On all the remaining nodes:

    Start-ClusterNode –Node <name> -PreventQuorum

  • Hi Max, Mixer, EJ Henry and Subhasish Bhattacharya.

    I too have been having problems with 1562 and 1069 errors in my Hyper-V cluster.

    I currently have an open ticket with Microsoft Support looking into this problem.

    They have found that these errors are related to the SMB WitnessClient share move requests interrupting the cluster host node checking the File Share Witness.

    I am sorry I cannot explain more because they have not resolved the ticket yet, but to give you an idea goto your SMB-WitnessClient event log on the Hyper-V cluster host node and see how its filling up continuously.

  • Hi Subhasish Bhattacharya,

    is there any resolution regarding 1562 and 1069 errors ?

    My FSW quorum goes down when using non CA share and brings also the errors.

    The only workaround is to have CA share

  • I'm another person experiencing intermittent 1562 errors. They happen several times a day, then may skip a couple of days before they happen again. As Moen has noted, some happen during move requests, but they sometimes occur without any other cluster activity.

Page 1 of 1 (14 items)