How to Configure a File Share Witness for a Hyper-V Cluster

Save to My DOJO

How to Configure a File Share Witness for a Hyper-V Cluster

Traditionally, the preferred choice for a cluster quorum witness has been some type of networked disk. Small SAN LUNs do the trick nicely. Things have changed a bit, increasing the viability of the file share witness. You can configure one easily in a few simple steps.

Prerequisites for a File Share Witness

Just as with a cluster disk witness, you need to do a bit of work in advance.

  1. First, you need to pick a system that will host the share. It needs to be reliable, although not necessarily bulletproof. We’ll talk about that after the how-to.
  2. Space used on that share will be extremely tiny. Mine doesn’t even use 100 bytes.
  3. You need to set adequate share and NTFS permissions. I just used my domain group that includes the cluster and nodes and gave it Full Control for both and that worked. From my observations, only the domain account that belongs to the cluster name object is used. It seems that Change on the share and Modify on NTFS are adequate permission levels.
  4. If you have firewalls configured, the cluster node needs to be able to reach the share’s host on port 445.

The cluster will create its own folder underneath the root of this share. When you configure the witness, it will generate a GUID to use as the folder name. Therefore, you can point multiple clusters at the same share.

Using PowerShell to Configure a File Share Witness

As with most things, PowerShell is the quickest and easiest way. You will use the Set-ClusterQuorum cmdlet.

From any node of the cluster, you can use that cmdlet with the FileShareWitness parameter:

Set-ClusterQuorum -FileShareWitness \svstore01Quorum

Once you have the name of the sharing host entered, you can use tab completion to step through the available shares.

If you want to run it remotely, make sure that you log in with an account that has administrative access to the cluster:

Set-ClusterQuorum -Cluster clhv01 -FileShareWitness \svstore01Quorum


Using Failover Cluster Manager to Configure a File Share Witness

Failover Cluster Manager has two different ways to get to the same screen.

  1. In Failover Cluster Manager, right-click the cluster’s root node, go to More Actions, and click Configure Cluster Quorum Settings.
  2. Click Next on the introductory screen.
  3. If you choose Advanced quorum configuration, you can change which nodes have quorum votes. That is not part of this article, but you’ll eventually get to the same screen that I’m taking you to. For my directions, choose Select the quorum witness. Click Next.
  4. Choose Configure a file share witness and click Next.
  5. You can manually enter or browse to the shared location.
    1. Manual entry:
    2. Browse:
  6. The next screen summarizes your proposed changes. Review them and click Next when ready. The cluster will attempt to establish your setting.
  7. The final screen shows the results of your action.

Checking/Verifying Your Cluster Quorum Settings in Failover Cluster Manager

The home screen in Failover Cluster Manager shows most of the pertinent information for a file share witness. Look in the Cluster Core Resources section:

You can see the most important things: the state of the share and where it lives. You cannot see the name of the sub-folder used.

Checking/Verifying Your Cluster Quorum Settings in PowerShell

The built-in PowerShell module does not join the information quite as gracefully. You can quickly see the status and mode with Get-ClusterResource:

If desired, you can pare it down a bit with Get-ClusterResource -Name ‘File Share Witness’ or just Get-ClusterResource ‘File Share Witness’.

You can see the mode with Get-ClusterQuorum, but it doesn’t show much else.

If you want to see the settings, you’ll need to get into the registry. The pertinent keys:

  • HKEY_LOCAL_MACHINEClusterResources<quorum GUID>
  • HKEY_LOCAL_MACHINEClusterResources<quorum GUID>Parameters

The value for the quorum GUID can be found in the Resource key-value pair under HKEY_LOCAL_MACHINEQuorum. The PowerShell interface for the registry is a bit messy:

(Get-ItemProperty HKLM:ClusterQuorum -Name Resource).Resource

That will output the GUID used in the other registry keys and the subfolder that was created on the file share witness. You can use it to retrieve them:


Troubleshooting a Cluster File Share Witness

There isn’t a lot to the file share witness. If the cluster says that it’s offline, then it can’t reach the share or it doesn’t have the necessary permissions.

I have noticed that the cluster takes longer to recognize that the share has come back online than a cluster disk. You can force it to come back online more quickly by right-clicking it in Failover Cluster Manager (screenshot above) and clicking Bring Online.

Why Use a File Share Witness for a Hyper-V Cluster?

With the how-to out of the way, we can talk about why. For me, it was because of the evolution of the cluster that I use to write these articles. I’ve been running the Microsoft iSCSI Target. But, as my cluster matured, I’ve been moving toward SMB. I don’t have anything left on iSCSI except quorum, Keeping it makes no sense.

To decide for your own option, analyze your options:

  • No witness: In a cluster with an odd number of nodes, you can go without a witness. However, with Microsoft Failover Clustering’s Dynamic Quorum technology, you’ll generally want to have a witness. I’m not sure of any good reason to continue using this mode.
  • Disk witness: Disk witness requires you to configure a standard Cluster Disk and dedicate it to quorum. Historically, we’ve built a SAN LUN of 512MB. If you have a SAN or other fiber channel/iSCSI target and don’t mind setting aside an entire LUN for quorum, this is a good choice. Really, the only reason to go with a disk witness when you have this option available is if you want to have your quorum be separate from your target.
  • Cloud witness (2016+): The cloud witness lets you use a small space on Azure storage as your witness. It’s a cool option, but not everyone has reliable Internet. Since you’ve already got storage for your cluster, cloud quorum might be overkill. But, it’s not a bad thing if you’ve got solid Internet. I would choose this for geographically dispersed clusters but otherwise would probably skip it in favor of a disk or share witness.

Realistically, I think the share witness works great when you’re already relying on SMB storage. As those builds become more common, the file share witness will likely increase in popularity.

Reliability Requirements for a File Share Witness

You want your file share witness to be mostly reliable, but it does not need to be 100%. Do the best that you can, but do not invest an inordinate amount of time and effort trying to ensure that it never fails. If you have a scale-out file server that always is online, that’s best. But, if you just have a single SMB system that hosts your VMs, that will work too. Remember that Dynamic Quorum will work to keep your cluster at a reasonable quorum level even if the file share witness goes offline.

Need any help?

If you’re having any issues setting up and configuring a File Share Witness for a Hyper-V Cluster let me know in the comments below and I’ll help you out. Also, if you’ve got any feedback at all on what’s been written here I’d love to hear it!

Altaro Hyper-V Backup
Share this post

Not a DOJO Member yet?

Join thousands of other IT pros and receive a weekly roundup email with the latest content & updates!

13 thoughts on "How to Configure a File Share Witness for a Hyper-V Cluster"

  • Mamadou says:

    Thanks Eric , definitely will consider that. I’m new to failover cluster , and I’m trying to set it up ar work for the first time with two nodes . I have been stuck for a while with shared storage . Been encountering no disk suitable for cluster were found . It’s very frustrating. I tried a third server for ISCSI target and use the two nodes clusters as initiator but still same error . Same things with my local disk raid 10 that I setup to each cluster node . Any help with that error and how to make those disk available as shared storage . Thank you .

    • Hi Eric,

      Good article, i have a question. We started with a default Cluster Quorum configuration with 4 DataON nodes. So the dynamic quorum works with a odd number of votes and 1 node will be excluded for votes.
      In this cluster i have 128 vm’s and 12 volumes. Is there any risk when i enable the quorum share which is a server share, Is there a possible risk that those cluster resources (vm’s) could initiate a failover to another node

      • Eric Siron says:

        If the share itself just disappears then Dynamic Quorum will figure that out. I can’t say that it would never trigger a failover because it will depending on what else is going on, but losing only the quorum won’t cause that.

  • Good article! I have a question I’ve not been able to find the answer for. What are the consequences of having two or more witness shares? I have a 2 node S2D cluster and have been able to configure and have two file share witnesses show online at the same time. Is that a good thing? Will it increase reliability? Is it even supported? I ask because it would be nice to be able to do maintenance while still having at least one share available.


    • Eric Siron says:

      I don’t know. Never something that I tried. Dynamic quorum should be able to figure it all out. I’m not sure that I understand why, though. You shouldn’t need an additional witness just for maintenance.

  • Filip says:

    Hi Eric,

    Thanks for nice article!
    Do you have any written pieces on load balanced hyper-v clusters (2 or more nodes working simultaneously and sharing workloads/vms)? I cannot find anything reliable on that topic. I am really not sure how to set it up not only from the cluster but also storage perspective. Also what if I want to have it in hybrid mode – say azure & on site (1 each).
    I know now you should be able to use Windows Admin Center (former P Honolulu) but maybe this is not the best way to do it. Not sure about its support for 2012r and older version of Windows, too.

    • Eric Siron says:

      2016 will auto-balance compute and CSVs. 2012 R2 and below require you to balance manually or use something like SCVMM or your own automation scripts to balance. I had started work on a balancing script but cancelled development when the capability was released natively in 2016.

  • Iftikhar says:

    Hi Eric,

    I am configuring 2 nodes Microsoft Hyper-V Failover Cluster on Windows server 2016 for first time.
    I will use Quorum Disk & CSVs from my Storage, do I still require to configure Fileshare witness ?? Or it is used instead of quorum ??
    I have configured 2 nodes cluster on Windows server 2008 R2 with Quorum & CSVs from storage.
    Would appreciate your response on my email.

    • Eric Siron says:

      Configure whatever witness works best for you. There is no “instead of quorum”. Quorum is a condition, not a thing that you configure.

  • Andres Perales says:

    Do you know if the File Share Witness can be on a hidden share?


Leave a comment or ask a question

Your email address will not be published. Required fields are marked *

Your email address will not be published.

Notify me of follow-up replies via email

Yes, I would like to receive new blog posts by email

What is the color of grass?

Please note: If you’re not already a member on the Dojo Forums you will create a new account and receive an activation email.