How to Set Up Remote Desktop Profile Management on Windows Server 2022

How to Set Up a Hyper-V Cluster on Windows Server 2022

A Hyper-V failover cluster on Windows Server 2022 provides high availability for virtual machines — if a host node fails, VMs automatically restart on surviving nodes within seconds. This guide walks through the complete process: from prerequisite installation through cluster creation, shared storage configuration, VM migration to the cluster, quorum settings, and Cluster-Aware Updating.

Prerequisites and Planning

Before installing clustering, your environment must meet specific requirements. Hardware requirements: all cluster nodes must have identical or compatible hardware configurations (processor family must match for live migration support), at minimum two network adapters per node (one for cluster heartbeat, one for VM traffic), and shared storage accessible by all nodes.

Network requirements: a dedicated cluster network for heartbeat traffic, preferably on a separate subnet from VM traffic. Nodes must be able to reach each other by name via DNS and resolve each other’s IP addresses.

All nodes must be joined to the same Active Directory domain. The account used to create the cluster needs permissions to create computer objects in AD (the cluster will create a Cluster Name Object in AD).

Verify that all cluster nodes meet the requirements before proceeding:

Test-ComputerSecureChannel -Verbose

Installing Failover Clustering and Hyper-V

Install the Failover Clustering feature on all nodes. Run this on each server that will be a cluster member:

Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools -IncludeAllSubFeature

Install the Hyper-V role on all nodes as well:

Install-WindowsFeature -Name Hyper-V -IncludeManagementTools -IncludeAllSubFeature

A reboot is required after installing Hyper-V. Reboot each node:

Restart-Computer -Force

To install the features on all cluster nodes simultaneously using PowerShell remoting (faster for multi-node deployments):

$nodes = @("HV-NODE-01", "HV-NODE-02", "HV-NODE-03")
Invoke-Command -ComputerName $nodes -ScriptBlock {
    Install-WindowsFeature -Name Failover-Clustering, Hyper-V -IncludeManagementTools -IncludeAllSubFeature
    Restart-Computer -Force
}

After rebooting, verify the features are installed on all nodes:

Invoke-Command -ComputerName $nodes -ScriptBlock {
    Get-WindowsFeature Failover-Clustering, Hyper-V | Select-Object Name, InstallState
}

Running Cluster Validation with Test-Cluster

Always run cluster validation before creating the cluster. The Test-Cluster cmdlet checks hardware, networking, storage, and system configuration, and it is required by Microsoft to receive support for a cluster. Run validation against all intended cluster nodes:

Test-Cluster -Node "HV-NODE-01", "HV-NODE-02", "HV-NODE-03" `
    -ReportName "C:ClusterValidationValidationReport"

The validation generates an HTML report at the specified path. Open it to review all pass/fail/warning results. Common failures at this stage include:

• Mismatched driver versions for network adapters across nodes
• Storage not visible to all nodes (iSCSI not connected, FC zoning issues)
• Duplicate IP addresses or DNS resolution failures
• Time synchronization drift between nodes

Address all failures before proceeding. Warnings may be acceptable depending on your environment (some storage warnings are expected in certain configurations). To run only specific test categories if you want to re-validate a specific area after fixing an issue:

Test-Cluster -Node "HV-NODE-01", "HV-NODE-02" -Include "Storage", "Network"

Creating the Cluster with New-Cluster

Once validation passes, create the cluster. You need a cluster name and a static IP address that clients will use to manage the cluster:

New-Cluster -Name "HV-CLUSTER-01" `
    -Node "HV-NODE-01", "HV-NODE-02", "HV-NODE-03" `
    -StaticAddress "192.168.1.50" `
    -NoStorage

The -NoStorage parameter prevents the cluster from automatically claiming all available shared disks during creation. This gives you control over which disks are added to the cluster. The cluster IP address (192.168.1.50) becomes the Cluster Name Object (CNO) address used to connect to the cluster from Failover Cluster Manager.

Verify the cluster was created successfully:

Get-Cluster -Name "HV-CLUSTER-01" | Select-Object *

View all cluster nodes and their status:

Get-ClusterNode -Cluster "HV-CLUSTER-01"

Configuring Shared Storage

Hyper-V clusters require shared storage that all nodes can access. The main options are iSCSI, Fibre Channel, and Storage Spaces Direct (S2D/hyperconverged).

For iSCSI-based shared storage, connect all nodes to the iSCSI target before adding disks to the cluster. On each node:

New-IscsiTargetPortal -TargetPortalAddress "192.168.2.100"
Get-IscsiTarget | Connect-IscsiTarget -IsPersistent $true -IsMultipathEnabled $true

After all nodes are connected, bring the shared disk online on one node and initialize it:

Get-Disk | Where-Object { $_.OperationalStatus -eq 'Offline' } | Set-Disk -IsOffline $false
Get-Disk | Where-Object { $_.PartitionStyle -eq 'RAW' } | Initialize-Disk -PartitionStyle GPT

Add the shared disk to the cluster as a Cluster Shared Volume (CSV):

Add-ClusterDisk -Cluster "HV-CLUSTER-01" -Disk (Get-Disk -Number 1)
Add-ClusterSharedVolume -Name "Cluster Disk 1"

CSV volumes appear at C:ClusterStorageVolume1 and so on. All cluster nodes can read and write to CSV volumes simultaneously, which is necessary for live migration and VM high availability.

List current CSVs:

Get-ClusterSharedVolume -Cluster "HV-CLUSTER-01"

For Storage Spaces Direct (hyperconverged — no external shared storage required), enable S2D after creating the cluster:

Enable-ClusterStorageSpacesDirect -CacheMode Disabled -AutoConfig $true -SkipEligibilityChecks

Adding the Hyper-V Role to the Cluster

With the cluster created and storage configured, configure the Hyper-V virtual switches consistently across all nodes. Each node needs a matching external virtual switch name for live migration to work:

Invoke-Command -ComputerName "HV-NODE-01", "HV-NODE-02", "HV-NODE-03" -ScriptBlock {
    New-VMSwitch -Name "External Switch" -NetAdapterName "Ethernet0" -AllowManagementOS $true
}

Verify all nodes have the same switch name (critical for VM live migration):

Invoke-Command -ComputerName "HV-NODE-01", "HV-NODE-02", "HV-NODE-03" -ScriptBlock {
    Get-VMSwitch | Select-Object Name, SwitchType
}

Migrating VMs to the Cluster

To make existing VMs highly available in the cluster, first ensure they are stored on a CSV volume, then register them as clustered VMs using Add-ClusterVirtualMachineRole.

If the VM’s VHDX is not already on a CSV, move it first using storage migration (VM can stay running):

Move-VMStorage -VMName "WebServer01" -DestinationStoragePath "C:ClusterStorageVolume1WebServer01"

Register the VM as a cluster role:

Add-ClusterVirtualMachineRole -VMName "WebServer01" -Cluster "HV-CLUSTER-01"

Verify the VM is now a cluster resource:

Get-ClusterGroup -Cluster "HV-CLUSTER-01" | Where-Object { $_.GroupType -eq 'VirtualMachine' }

Register all VMs from a specific node in bulk:

Get-VM -ComputerName "HV-NODE-01" | ForEach-Object {
    Add-ClusterVirtualMachineRole -VMName $_.Name -Cluster "HV-CLUSTER-01"
    Write-Host "Clustered: $($_.Name)"
}

Move a clustered VM to a different node (live migration):

Move-ClusterVirtualMachineRole -Name "WebServer01" -MigrationType Live -Node "HV-NODE-02"

Configuring Cluster Quorum

Quorum determines how many nodes or votes are required for the cluster to remain online. Proper quorum configuration prevents split-brain scenarios where two isolated groups of nodes each believe they are the authoritative cluster.

Check the current quorum configuration:

Get-ClusterQuorum -Cluster "HV-CLUSTER-01"

For a two-node cluster, a disk witness or cloud witness is required. Configure a file share witness (suitable when you have a third server that is not a cluster node):

Set-ClusterQuorum -Cluster "HV-CLUSTER-01" -FileShareWitness "\FileServer01HV-CLUSTER-01-Witness"

Configure a cloud witness using Azure Blob Storage (recommended for clusters that span physical sites or when no on-premises witness is available):

Set-ClusterQuorum -Cluster "HV-CLUSTER-01" `
    -CloudWitness `
    -AccountName "yourstorageaccount" `
    -AccessKey "your-azure-storage-account-key"

For a three-node cluster with no storage witness, the default node majority quorum works without any witness. For four or more nodes, the cluster can tolerate losing up to half minus one nodes:

Set-ClusterQuorum -Cluster "HV-CLUSTER-01" -NodeMajority

Check quorum health and current vote counts:

Get-ClusterNode | Select-Object Name, NodeWeight, DynamicWeight
(Get-Cluster).QuorumType

Cluster-Aware Updating (CAU)

Cluster-Aware Updating automates the process of applying Windows Updates to cluster nodes while keeping VMs available. CAU live-migrates VMs off each node in turn, installs updates, reboots, and then moves to the next node.

Install the CAU feature if not already present:

Install-WindowsFeature -Name RSAT-Clustering-AutomatedUnattended -IncludeManagementTools

Preview what updates CAU would apply without actually installing them:

Invoke-CauScan -ClusterName "HV-CLUSTER-01" -CauPluginName "Microsoft.WindowsUpdatePlugin" -Verbose

Run a CAU update cycle immediately:

Invoke-CauRun -ClusterName "HV-CLUSTER-01" `
    -CauPluginName "Microsoft.WindowsUpdatePlugin" `
    -MaxRetriesPerNode 2 `
    -RequireAllNodesOnline `
    -EnableFirewallRules `
    -Force

Enable self-updating mode where CAU runs on a schedule automatically:

Add-CauClusterRole -ClusterName "HV-CLUSTER-01" `
    -DaysOfWeek Saturday `
    -IntervalWeeks 2 `
    -StartTime "02:00:00" `
    -MaxRetriesPerNode 2 `
    -RequireAllNodesOnline `
    -EnableFirewallRules `
    -Force

Check CAU status and last run results:

Get-CauReport -ClusterName "HV-CLUSTER-01" | Select-Object -First 5

Monitoring Cluster Health

Check overall cluster health status:

Get-ClusterNode -Cluster "HV-CLUSTER-01" | Select-Object Name, State, NodeWeight

View all cluster resources and their current state:

Get-ClusterResource -Cluster "HV-CLUSTER-01" | Select-Object Name, ResourceType, State, OwnerGroup, OwnerNode

Get cluster events for troubleshooting:

Get-ClusterLog -Cluster "HV-CLUSTER-01" -Destination "C:ClusterLogs" -TimeSpan 60

Simulate a node failure for testing (removes a node from the cluster without shutting it down):

Suspend-ClusterNode -Name "HV-NODE-02" -Cluster "HV-CLUSTER-01" -Drain

Return the node to service after maintenance:

Resume-ClusterNode -Name "HV-NODE-02" -Cluster "HV-CLUSTER-01" -Failback Immediate

Overview of SCVMM for Cluster Management

For large-scale Hyper-V cluster environments, System Center Virtual Machine Manager (SCVMM) provides a centralized management plane. SCVMM adds capabilities beyond what Failover Cluster Manager and PowerShell alone offer: logical networks with VM network abstraction, storage classification and placement policies, service templates for multi-tier application deployment, fabric management across multiple clusters, and integration with System Center Operations Manager for performance monitoring.

SCVMM is a separate licensed product (part of System Center suite) installed on a dedicated management server with its own SQL Server database. It communicates with Hyper-V hosts via WinRM and the VMM agent installed on each host. While not required for functional Hyper-V clustering, SCVMM becomes increasingly valuable as cluster size grows beyond five to ten nodes or when managing multiple clusters across different locations.