First published on MSDN on Apr 16, 2018
One of the quorum models for Failover Clustering is the ability to use a file share as a witness resource. As a recap, the File Share Witness is designated a vote in the Cluster when needed and can act as a tie breaker in case there is ever a split between nodes (mainly seen in multi-site scenarios).
I don't want to go through the list of all the requirements but do want to focus on one in particular.
The reason for this is that Failover Cluster utilizes Kerberos for the Cluster Name Object (CNO) to connect and authenticate the share. Therefore, the share must reside on a domain member that is in the same active directory forest.
There are scenarios where this is not possible. These scenarios are:
We have had a lot of requests over the years for how to get around these scenarios and there wasn't a good story for it. Well, I am here to tell you we listened, and we produced something better than a workaround.
In comes Windows Server 2019 and the new File Share Witness feature to the rescue.
We can now create a File Share Witness that does not utilize the CNO, but in fact, simply uses a local user account on the server the FSW is connected to.
This means NO kerberos , NO domain controller , NO certificates , and NO Cluster Name Object needed. While we are at it, NO account needed on the nodes. Oh my!!
There are multiple scenarios where this can be used such as a NAS appliance, non-domain joined Windows installations, etc.
The way it works is that on the Windows Server you wish to place the FSW, create a local (not administrative) user account, give that local account full rights to the share, connect the cluster to the share.
Let's take for example, I have a server called SERVER and a share called SHARE I want to utilize as the File Share Witness. For creating this type of File Share Witness can only be done through PowerShell. The steps for setting this up are:
Set-ClusterQuorum -FileShareWitness \\SERVER\SHARE -Credential $(Get-Credential)
Viola!! You are done as we just took care of all the above scenarios. The cluster will keep the name and password encrypted and not accessible by anyone.
For those scenarios where a additional server is not available, how about using a USB drive connected to a router? Yes, we have that capability and just as simplistic as setting it up on a server.
Simply plug your USB drive into the port in the router and get into your router's interface. In there, you can set up your share name, username, and password for access. Use the PowerShell command above pointing it to the router and share, and you are good to go. To answer your next question, this works with SMB 2.0 and above. SMB 3.0 is not required for the witness type.
Please try out this new feature and provide feedback through the Feedback Hub app.
Senior Program Manager
High Availability and Storage
Follow me on Twitter @JohnMarlin_MSFT
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.