Introduction to Scale-Out File Server on Windows Server 2022

Scale-Out File Server (SoFS) is a clustered file server role in Windows Server 2022 that provides continuously available SMB file shares for highly available workloads such as Hyper-V virtual machine storage and SQL Server databases. Unlike the traditional clustered file server (which uses active-passive failover and requires clients to reconnect after a failover), SoFS delivers an active-active architecture where all cluster nodes simultaneously serve file requests. This means there is no failover pause, no client reconnection, and no disruption to running virtual machines when a node fails or is taken offline for maintenance.

SoFS is built on top of Windows Server Failover Clustering (WSFC) and uses Cluster Shared Volumes (CSVs) as the backing storage. It leverages SMB 3.0 features including Transparent Failover, Multichannel, and Direct (RDMA) to deliver the performance and resilience required for Tier 1 workloads.

SoFS Architecture and How It Differs from Regular Clustered File Server

The regular Clustered File Server (also called File Server for general use) is an active-passive resource. Only one node owns the file server resource at a time. If that node fails, the resource fails over to another node and SMB clients re-establish their sessions. This introduces a brief outage (typically a few seconds to a minute depending on cluster health) that is acceptable for general-purpose file shares but not for Hyper-V storage.

The Scale-Out File Server role uses SMB 3.0 Transparent Failover. All cluster nodes simultaneously own and serve the SoFS shares. SMB 3.0 clients (Windows 8/Server 2012 and later) maintain a persistent SMB session that automatically and transparently shifts to another cluster node when the previously serving node becomes unavailable — with zero client-visible disruption. Running Hyper-V VMs and SQL Server databases continue operating without any I/O errors during the failover.

SoFS shares must reside on Cluster Shared Volumes (CSVs), which provide simultaneous read/write access from all cluster nodes. The backing storage for CSVs can be Storage Spaces Direct (S2D) on the same cluster (a hyper-converged or converged configuration) or a shared SAN/iSCSI target.

Infrastructure Requirements

Before deploying SoFS, ensure the following prerequisites are met. All servers must run Windows Server 2022 Standard or Datacenter edition. All nodes must be members of the same Active Directory domain. Windows Server Failover Clustering feature must be installed on all nodes. The Failover Clustering validation wizard must complete without critical errors.

For network requirements, a dedicated storage network (separate from management and VM traffic) is strongly recommended. For best performance, use RDMA-capable network adapters (iWARP or RoCE) with SMB Direct enabled. Each node should have at least two 10 GbE or higher network adapters for SMB Multichannel redundancy.

Storage requirements depend on the backing storage type. For S2D-backed SoFS, all drives must be directly attached (not behind a RAID controller in RAID mode — set controllers to HBA mode or use NVMe directly). For SAN-backed SoFS, LUNs must be properly zoned and presented to all cluster nodes simultaneously.

Creating the Failover Cluster

Install the Failover Clustering feature on all intended nodes:

Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools -ComputerName HV01, HV02, HV03

Run the cluster validation test. Do not skip this — it identifies hardware and configuration issues that will cause problems at runtime:

Test-Cluster -Node "HV01", "HV02", "HV03" -Include "Storage", "Network", "System Configuration", "Inventory"

Review the HTML report generated at the end of validation. Address any warnings or failures before proceeding. Create the cluster:

New-Cluster -Name "SoFS-Cluster01" -Node "HV01", "HV02", "HV03" -StaticAddress "10.0.0.50" -NoStorage

The -NoStorage parameter prevents the cluster from automatically taking ownership of storage during creation when using S2D. Configure a cluster quorum witness. For clusters with an even number of nodes or for additional resilience, use a cloud witness (Azure Blob Storage) or a file share witness:

Set-ClusterQuorum -Cluster "SoFS-Cluster01" -CloudWitness -AccountName "mystorageaccount" -AccessKey "base64accesskeyhere"

Enabling Storage Spaces Direct (S2D)

For hyper-converged or converged SoFS using local storage, enable S2D on the cluster:

Enable-ClusterStorageSpacesDirect -CimSession "SoFS-Cluster01" -Verbose

S2D will automatically discover, claim, and pool all eligible drives across all cluster nodes. Verify the storage pool was created:

Get-StoragePool -CimSession "SoFS-Cluster01" | Where-Object { $_.IsPrimordial -eq $false }

Create a Cluster Shared Volume on the S2D pool for the SoFS shares. For a three-way mirror (required for three or more nodes):

New-Volume -CimSession "SoFS-Cluster01" -FriendlyName "CSV-SoFS-VMs" -FileSystem CSVFS_ReFS -StoragePoolFriendlyName "S2D on SoFS-Cluster01" -Size 5TB -ResiliencySettingName Mirror

Verify the CSV is available and online:

Get-ClusterSharedVolume -Cluster "SoFS-Cluster01"

Adding the Scale-Out File Server Role

With the cluster and CSV in place, add the Scale-Out File Server clustered role. This creates a highly available virtual file server name that clients connect to:

Add-ClusterScaleOutFileServerRole -Cluster "SoFS-Cluster01" -Name "SoFS-FileServer01"

The -Name parameter specifies the NetBIOS name clients use to connect to the file server. This name gets a virtual IP address registered in DNS and Active Directory. Verify the role is online:

Get-ClusterGroup -Cluster "SoFS-Cluster01" | Where-Object { $_.GroupType -eq "ScaleoutFileServer" }

The role should show State as Online and OwnerNode as one of the cluster nodes (for administrative purposes; all nodes actively serve the shares).

Creating SoFS SMB Shares

SoFS shares must be created on a CSV path. The CSV mount points are located at C:ClusterStorageVolumeX on each node. Create a directory on the CSV and then create the SMB share pointing to it:

# Create the share directory on the CSV
$sharePath = "C:ClusterStorageVolume1HyperV-VMs"
New-Item -Path $sharePath -ItemType Directory -Force

# Create the SoFS SMB share
New-SmbShare -Name "HyperV-VMs" -Path $sharePath -FullAccess "CORPHyperV-Servers$", "CORPDomain Admins" -ContinuouslyAvailable $true -EncryptData $true -FolderEnumerationMode AccessBased

The critical parameter here is -ContinuouslyAvailable $true. This enables SMB 3.0 Persistent Handles, which is what allows Hyper-V and SQL Server to maintain open file handles across a cluster failover without experiencing I/O errors. Always set this for Hyper-V storage shares.

-EncryptData $true enables SMB encryption for this share, protecting data in transit without requiring IPsec. Note that SMB encryption does add CPU overhead; in very high-throughput environments, consider using RDMA with SMB Direct instead, as SMB Direct bypasses the software encryption path.

To verify the share was created with the correct properties:

Get-SmbShare -Name "HyperV-VMs" | Select-Object Name, Path, ContinuouslyAvailable, EncryptData, ShareType

SMB 3.0 Features in SoFS

Transparent Failover is enabled by the combination of SoFS, CSV, and SMB 3.0 Persistent Handles. When a cluster node fails, the SMB client (Hyper-V on the connecting host) detects the disconnection and automatically reconnects to another node that owns a replica of the CSV data, with no I/O error visible to the guest VM.

SMB Multichannel allows a single SMB session to use multiple network connections simultaneously, increasing throughput and providing network fault tolerance. It is enabled by default when multiple network paths exist between client and server. To verify Multichannel is active:

Get-SmbMultichannelConnection -ServerName "SoFS-FileServer01"

SMB Direct (RDMA) allows SMB data transfers to bypass the CPU and OS network stack, using RDMA hardware to transfer data directly between memory regions. This dramatically reduces latency and CPU overhead. For SMB Direct to work, both client and server must have RDMA-capable NICs (iWARP or RoCE). Verify SMB Direct capability:

Get-SmbClientNetworkInterface | Select-Object InterfaceIndex, IpAddresses, RdmaCapable, SpeedGbps
Get-SmbServerNetworkInterface | Select-Object ServerName, InterfaceIndex, IpAddresses, RdmaCapable

Configuring Hyper-V to Use SoFS Storage

On the Hyper-V hosts that will store virtual machines on SoFS, configure the default VM store path to the SoFS share:

Set-VMHost -ComputerName "HV-Host01" -VirtualHardDiskPath "\SoFS-FileServer01HyperV-VMs" -VirtualMachinePath "\SoFS-FileServer01HyperV-VMs"

When creating a new VM on the Hyper-V host, specify the UNC path to the SoFS share:

New-VM -Name "WebServer01" -ComputerName "HV-Host01" -Path "\SoFS-FileServer01HyperV-VMs" -NewVHDPath "\SoFS-FileServer01HyperV-VMsWebServer01disk.vhdx" -NewVHDSizeBytes 100GB -MemoryStartupBytes 4GB -Generation 2

To test that live migration works correctly with SoFS storage (VMs stored on SoFS can be live migrated between any Hyper-V hosts that have access to the SoFS share):

Move-VM -ComputerName "HV-Host01" -Name "WebServer01" -DestinationHost "HV-Host02" -Verbose

Monitoring SoFS Performance

Monitor SoFS performance using Performance Monitor counters and PowerShell. Key counters to watch include SMB throughput, IOPS, and latency on the server side, and cluster shared volume performance on the storage side.

# Get SMB server session information
Get-SmbSession | Select-Object ClientComputerName, ClientUserName, NumOpens, SmbInstance

# Get open SMB files on the share
Get-SmbOpenFile | Where-Object { $_.ShareRelativePath -like "HyperV-VMs*" } | Select-Object ClientComputerName, Path, SessionId

# Get CSV performance data
Get-ClusterSharedVolumeState -Cluster "SoFS-Cluster01" | Format-Table Name, Node, StateInfo, FileSystemRedirectedIOReason

The FileSystemRedirectedIOReason column is important — a value of NotRedirected means I/O is going directly to the local disk (optimal). If it shows FileSystemNotAvailable or StorageSpaceNotAttached, the CSV is redirecting I/O over the network to another node’s disk, which significantly degrades performance.

To view overall SoFS health and share availability from the Failover Cluster Manager perspective:

Get-ClusterGroup -Cluster "SoFS-Cluster01" | Format-Table Name, State, OwnerNode, GroupType

To verify that continuous availability is working correctly, use the Cluster Validation report and check the SoFS-specific tests, or use the SoFS diagnostic test:

Test-Cluster -Cluster "SoFS-Cluster01" -Include "Scale-Out File Server"

Troubleshooting Common SoFS Issues

If VMs experience I/O pauses after a node failure, check whether SMB Transparent Failover is working by examining the CSV owner and redirection state. Also check that SMB 3.0 Persistent Handles are enabled on the share (the ContinuouslyAvailable property must be True).

If SoFS performance is lower than expected with RDMA hardware, verify that SMB Direct is enabled on the server:

Get-SmbServerConfiguration | Select-Object EnableSMBDirect

If it is disabled, re-enable it:

Set-SmbServerConfiguration -EnableSMBDirect $true -Confirm:$false

For access permission issues, verify the computer accounts of the Hyper-V hosts have Full Control on the SoFS share. Hyper-V uses the machine account (DOMAINHostname$) to access SoFS shares, not a user account:

Grant-SmbShareAccess -Name "HyperV-VMs" -AccountName "CORPHV-Host01$" -AccessRight Full -Confirm:$false

Scale-Out File Server on Windows Server 2022 delivers enterprise-grade continuously available file storage that eliminates scheduled maintenance windows and unplanned downtime for Hyper-V and SQL Server workloads, making it an essential component of any Windows-based private cloud infrastructure.