A couple of weeks ago, I released a blog post about Hyper-V VM Configuration versions to give an overview about the version history of Hyper-V virtual machines. After that I had the chance to work with John Marlin (Microsoft Senior Program Manager High Availability and Storage) on a similar list of Windows Server Cluster Functional Levels.
Why Cluster Functional Levels are important
With Windows Server 2016, Microsoft introduced a new feature called Cluster OS Rolling Upgrade or Cluster Rolling Upgrade. This feature allows you to upgrade the operating system of the cluster nodes to a new version, without stopping the cluster. With mixed-OS mode, you can have for example 2012 R2 and 2016 nodes in the same cluster. Keep in mind that this should only be temporary, while you are upgrading the cluster. You can basically upgrade node by node, and after all nodes are upgraded, you then upgrade the Cluster functional Level to the latest version.
List of Windows Server Cluster Functional Levels
Since the feature Cluster OS Rolling Upgrade was first introduced with Windows Server 2016, you never really knew about Cluster Functional Levels before. However, it already existed since Windows Server NT4.
| Windows Server Version | Cluster Functional Level |
|---|---|
| Windows Server 2019 | 10.x |
| Windows Server 2016 | 9 |
| Windows Server 2012 R2 | 8 |
| Windows Server 2012 | 7 |
| Windows Server 2008 R2 | 6 |
| Windows Server 2008 | 5 |
| Windows Server 2003 R2 | 4 |
| Windows Server 2003 | 3 |
| Windows Server 2000 | 2 |
| Windows Server NT4 | 1 |
Tips and PowerShell
If you want to know more about Cluster OS Rolling Upgrade, you can check out the Microsoft Docs. Together with John, I created a quick list of some tips for you, and some of the important PowerShell cmdlets.
To check which Cluster Functional Levels your cluster is running on, you can use the following PowerShell cmdlet:
Get-Cluster | Select ClusterFunctionalLevel
If you have upgraded all nodes in the cluster, you can use the Update-ClusterFunctionalLevel to update the Cluster Functional Level. Also make sure that you upgrade the workloads running in that cluster, for example upgrade the Hyper-V Configuration Version or in a Storage Spaces Direct Cluster, the Storage Pool version (Update-StoragePool).
Update-ClusterFunctionalLevelIn Windows Server 2019 the Clustering team introduced a new PowerShell cmdlet to check how many nodes of the cluster are running on which level. Get-ClusterNodeSupportedVersion helps you to identify the Cluster Functional Level and the Cluster Upgrade Version.
Get-ClusterNodeSupportedVersion
This means that the functional level is 10 (Windows 2019). The Upgrade version column is what you can upgrade to/with, meaning 11.1 or Windows 2019 only.
This means your Cluster Functional Level is 10.
If you are running System Center Virtual Machine Manager, the Cluster OS rolling upgrade can be fully automated as well. Check out the Microsoft Docs for Perform a rolling upgrade of a Hyper-V host cluster to Windows Server 2016 in VMM.
To find out more about information Cluster operating system rolling upgrade, like how-to, requirements and limitations, check out the Microsoft Windows Server Docs page.
Tags: Cluster, Cluster Functional Level, Cluster OS rolling upgrade, Cluster Upgrade, Clustering, Failover Cluster, Functional Levels, Microsoft, Windows Server, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019, Windows Server Cluster Last modified: July 25, 2019
Hi, Thanks for this blog post.
I just updated a two node (native) cluster 2016 to 2019 (most fresh release of today). Then I run “Update-ClusterFunctionalLevel” followed by “Get-ClusterNodeSupportedVersion” and strangely, I get 10.3, what relates to Windows Server RS4 and not 2019.
I cannot find the reason. If you have any ideas…
Thanks and best regards.
Thomas.
I get the same thing after upgrading to 2019. Cluster functional level is 10.3. Other documentation on the web indicates that 10.3 is correct for 2019. I’m not sure where Thomas got those version numbers from.
Hi
The version for 2019 is fixed. Small glitch in the docs :) Sorry about that.
With Azure Stack HCI i’ve also some strange behaviour with those versions.
PS C:\temp> Get-Cluster | Select ClusterFunctionalLevel
ClusterFunctionalLevel
———————-
10
PS C:\temp>
PS C:\temp> Get-ClusterNodeSupportedVersion
ClusterFunctionalLevel ClusterUpgradeVersion
———————- ———————
10 32771
PS C:\temp> Update-ClusterFunctionalLevel
Updating the functional level for cluster CLUSTERNAME.
Warning: You cannot undo this operation. Do you want to continue?
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is “Y”): a
Update-ClusterFunctionalLevel : Updating the cluster functional level failed.
The Cluster Functional Level could not be increased because not all nodes in the cluster support the updated version
At line:1 char:1
+ Update-ClusterFunctionalLevel
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Update-ClusterFunctionalLevel], ClusterCmdletException
+ FullyQualifiedErrorId : Update-ClusterFunctionalLevel,Microsoft.FailoverClusters.PowerShell.UpdateClusterFunctionalLevelCommand
But all Hosts are UP and have the latest Windows Updates installed…
Invoke-Command -Computername $a -ScriptBlock {(Get-CimInstance Win32_OperatingSystem -Property Version).Version }
10.0.17784
10.0.17784
10.0.17784
10.0.17784
10.0.17784
10.0.17784
Maybe only a Azure Stack HCI Bug?