Windows 10: Managing Server 2019 clustering

RohitYadavR · Jan 11, 2022

SQL Server 2019 Always-on implemented on 2 Nodes on Windows Server 2022 and when i perform manual failover to the second node I got this warning "the current wsfc cluster quorum vote configuration is not recommended for this availability group", and the Always-on availability group is healthy and no problem with it.i tried the following without no luckUpdate Windows Server 2022 to latest updatereconfigure WSFC quorum to use Defualt configurationreconfigure WSFC quorum to use Witness fileShare.

:)

theBoringCoder at CSB · Jan 11, 2022

Windows 2019 Datacenter Cluster - Configuring Cluster Aware Updating

Hello, everyone.

I am trying to configure Cluster Aware Updating (CAU) on a 2-node, Windows 2019 Datacenter Cluster. Using Failover Cluster Manager, when I run the "Analyze cluster updating readiness" function, I receive a report with two errors and one warning.

The first error is "The failover cluster nodes must be enabled for remote management via WMIv2". They already are. When I run "WINRM QUICKCONFIG -q" on each node, I get no errors; in fact I get "WinRM service is already running on this machine. WinRM is
already set up for remote management on this computer."

The second error is "Windows PowerShell remoting should be enabled on each failover cluster node". It already is. When I run "Enable-PSRemoting" on each node, I get no errors;. in fact I get no messages back at all.

The one warning is "The CAU clustered role should be installed on the failover cluster to enable self-updating mode". I think this will go away once I get CAU set up and running on this cluster.

My command to add CAU to my cluster ends up being:

Add-CauClusterRole -ClusterName ES19TESTCL1 -Force -CauPluginName Microsoft.WindowsUpdatePlugin -MaxRetriesPerNode 3 -CauPluginArguments @{ 'IncludeRecommendedUpdates' = 'True' } -RequireAllNodesOnline -StartDate "8/1/2020 12:00:00 AM" -DaysOfWeek 64 -WeeksOfMonth
@(3) -VirtualComputerObjectName ES19TESTCL1CAU -EnableFirewallRules;

ES19TESTCL1CAU is a computer name I pre-staged in my Active Directory.

The results of running that PowerShell script was: "Validation failed for adding CAU cluster role." I'm guessing once I figure out and fix what's causing the validation errors, the script will work. Any suggestions are greatly appreciated. This is my first
cluster.

Brink · Jan 11, 2022

New File Share Witness Feature in Windows Server 2019

This blog discusses a new feature in the upcoming release of Windows Server 2019. Currently, Windows Insiders receive current builds of Server 2019. We urge you to become an Insider and play a part in making Windows Server 2019 the best that it can be. To do so, go to this link and sign up.

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 Windows Server holding the file share must be domain joined and a part of the same forest.

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:

No or extremely poor Internet access because of a remote location, so cannot use a Cloud Witness

No shared drives for a disk witness. This could be a Storage Spaces Direct hyper-converged configuration, SQL Server Always On Availability Groups (AG), Exchange Database Availability Group (DAG), etc. All of which do not utilize shared disks.

A domain controller connection is not available as the cluster has been dropped behind a DMZ

A workgroup or cross-domain cluster where there in no active directory CNO object

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!!

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:

Log on to SERVER and create a local user account (i.e. FSW-ACCT)

Create a folder on SERVER and share it out

Give the local user account (FSW-ACCT) full rights to the share

Log in to one of your cluster nodes and run the PowerShell command:

Set-ClusterQuorum -FileShareWitness \\SERVER\SHARE -Credential $(Get-Credential)

You will be prompted for the account and password for which you should enter SERVER\FSW-ACCT and the password.

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.

Just as an FYI, the original demo of this feature was using a USB thumb drive holding the share plugged into a router. Not that we would recommend doing it, but does show how far you could take this.

Please try out this new feature and provide feedback through the Feedback Hub app.

Thanks,
John Marlin
Senior Program Manager
High Availability and Storage
Click to expand...

Source: New File Share Witness Feature in Windows Server 2019 | Clustering and High-Availability

Brink · Jan 11, 2022

New File Share Witness Feature in Windows Server 2019

This blog discusses a new feature in the upcoming release of Windows Server 2019. Currently, Windows Insiders receive current builds of Server 2019. We urge you to become an Insider and play a part in making Windows Server 2019 the best that it can be. To do so, go to this link and sign up.

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 Windows Server holding the file share must be domain joined and a part of the same forest.

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:

No or extremely poor Internet access because of a remote location, so cannot use a Cloud Witness

No shared drives for a disk witness. This could be a Storage Spaces Direct hyper-converged configuration, SQL Server Always On Availability Groups (AG), Exchange Database Availability Group (DAG), etc. All of which do not utilize shared disks.

A domain controller connection is not available as the cluster has been dropped behind a DMZ

A workgroup or cross-domain cluster where there in no active directory CNO object

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!!

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:

Log on to SERVER and create a local user account (i.e. FSW-ACCT)

Create a folder on SERVER and share it out

Give the local user account (FSW-ACCT) full rights to the share

Log in to one of your cluster nodes and run the PowerShell command:

Set-ClusterQuorum -FileShareWitness \\SERVER\SHARE -Credential $(Get-Credential)

You will be prompted for the account and password for which you should enter SERVER\FSW-ACCT and the password.

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.

Just as an FYI, the original demo of this feature was using a USB thumb drive holding the share plugged into a router. Not that we would recommend doing it, but does show how far you could take this.

Please try out this new feature and provide feedback through the Feedback Hub app.

Thanks,
John Marlin
Senior Program Manager
High Availability and Storage
Click to expand...

Source: New File Share Witness Feature in Windows Server 2019 | Clustering and High-Availability

Windows 10: Managing Server 2019 clustering

Managing Server 2019 clustering

Managing Server 2019 clustering

Managing Server 2019 clustering

Managing Server 2019 clustering - Similar Threads - Managing Server 2019

Windows Server 2019 Failovercluster physical mgmt cluster nic connection error

Windows Server 2019 Failovercluster physical mgmt cluster nic connection error

Server 2022 Cluster Functional Levels

Server 2022 Cluster Functional Levels

Windows Servers 2019 Failover Cluster Node2 Shared volume error

Windows Servers 2019 Failover Cluster Node2 Shared volume error

Windows Servers 2019 Failover Cluster Node2 Shared volume error

Managing Server 2019 clustering

Managing Server 2019 clustering