Category Archives: Failover Cluster

Modifying Windows Server Failover Cluster (WSFC) node subnets the quick and dirty way

We were in the middle of expanding a server subnet and ran into complications. If you did not bring down the entire cluster and tried to make subnet mask changes to a NIC you ran into all kinds of complications which could take a while to fix. We wound up evicting nodes, removing/recreating SQL AG listeners (for SQL AlwaysOn nodes), rebooting nodes, etc. Basically, WSFC pulls subnet configuration directly from the NICs used in the cluster and you have to bring cluster services down, make changes, bring them back up in a specific order to avoid issues. I decided to find a faster way to accomplish this. It involves modifying the CLUSDB cluster configuration registry hive (here is a good page on this database). When cluster services are actually running this registry hive is mounted as ‘HKLM\Cluster‘, but we will be taking down the cluster and manually mounting the hives for offline modification.

  1. Stop other cluster-related services (like SQL Server) on all nodes
  2. Shutdown the entire cluster. You can do this from the ‘Failover Cluster Manager’, PowerShell, or the old ‘cluster.exe’ utility
  3. Verify the ‘Cluster Service‘ service is stopped on all nodes
  4. Update the subnet mask(s) on the appropriate NICs on all nodes
  5. Update the CLUSDB registry hives on ALL nodes. Make sure you are updating the correct registry values with the correct values. There are both regular subnet mask values AND subnet CIDR values to update
    • BACKUP THE ‘C:\Windows\Cluster\CLUSDB’ files on all nodes BEFORE making any changes. You may want to backup/snapshot the server as well
    • Load the ‘C:\Windows\Cluster\CLUSDB’ registry hive (REG LOAD HKLM\CLUSDB “C:\Windows\Cluster\CLUSDB”)
    • Edit HKLM\CLUSDB\NetworkInterfaces\OBJECTGUID\AddressPrefixList\0000  values
    • Edit HKLM\CLUSDB\Networks\OBJECTGUID  values
    • Edit HKLM\CLUSDB\Networks\OBJECTGUID\PrefixList\0000  values
    • Edit HKLM\CLUSDB\Resources\OBJECTGUID\Parameters values (for IP address resources)
  6. Start cluster again
  7. Verify all networks and IP address cluster resources are displaying right subnet values
  8. Start any other cluster-related services you may have stopped in step #1
  9. Verify functionality of the cluster and all other services

This method could also be used to move the cluster to an entirely new subnet, but it might be easier just to create new IP resources (which will create new cluster networks) at that point.

Here are the first two examples of the registry changes above: