How to Set Up a Scale-Out File Server (SoFS) on Windows Server 2025

How to Set Up a Scale-Out File Server (SoFS) on Windows Server 2025

A Scale-Out File Server (SoFS) is a Windows Server Failover Cluster role that delivers continuously available SMB 3.0 file shares for demanding workloads — particularly Hyper-V virtual machine storage and SQL Server data and log files. Unlike traditional clustered file servers that serve shares from a single active node at a time, a SoFS makes every cluster node simultaneously active for all shares, distributing I/O across all nodes and all network paths simultaneously. Windows Server 2025 builds on the SMB 3.0 foundation with enhanced SMB over QUIC capabilities and improved multichannel performance, making SoFS an even more compelling storage option for scale-out compute environments. This tutorial covers prerequisites, creating the SoFS role using PowerShell and Failover Cluster Manager, creating SMB shares on Cluster Shared Volumes, configuring SMB Multichannel, connecting Hyper-V and SQL Server as storage clients, testing high availability through node failover, and monitoring share access with built-in cmdlets.

Prerequisites

• Windows Server 2025 Datacenter edition installed on all cluster nodes (SoFS requires Datacenter for unlimited Hyper-V guest support when used as VM storage)
• Windows Server Failover Clustering (WSFC) feature installed and a cluster already created (New-Cluster)
• At least one Cluster Shared Volume (CSV) provisioned from shared storage (SAS JBOD, iSCSI, Fibre Channel, or Storage Spaces with shared SAS)
• All cluster nodes joined to the same Active Directory domain
• Multiple network adapters per node for SMB Multichannel (10GbE or faster recommended; RDMA NICs for maximum performance)
• A cluster network dedicated to CSV traffic, separate from the management network
• PowerShell 5.1 or later with FailoverClusters module, running as Domain Admin

Step 1 — Verify the Failover Cluster and CSV

Before creating the SoFS role, confirm that the cluster is healthy and that at least one CSV is online and available. All cluster validation errors must be resolved before proceeding.

# Check cluster health
Get-Cluster | Select-Object Name, QuorumType
Get-ClusterNode | Select-Object Name, State

# List all Cluster Shared Volumes and their health
Get-ClusterSharedVolume | Select-Object Name, State, SharedVolumeInfo

# If you need to add a new disk as a CSV:
# First add the disk to the cluster, then convert it to CSV
Add-ClusterDisk -InputObject (Get-Disk -Number 2)
Add-ClusterSharedVolume -Name "Cluster Disk 2"

# Verify the CSV is mounted and accessible
Get-ClusterSharedVolume | Format-List Name, State, @{
    Name="Path"; Expression={$_.SharedVolumeInfo.FriendlyVolumeName}
}

CSV volumes are mounted under C:ClusterStorage on the node currently acting as the CSV coordinator. Every cluster node can read and write to the CSV simultaneously through the CSV file system (CSVFS), which coordinates writes across nodes using the SMB protocol internally.

Step 2 — Create the Scale-Out File Server Role

The SoFS role is added to the cluster using Add-ClusterScaleOutFileServerRole. This creates a clustered service with a dedicated cluster network name (CNO) and IP address that clients use to access the file shares.

# Create the Scale-Out File Server role
Add-ClusterScaleOutFileServerRole -Name "SOFSSERVER01"

# Verify the role was created and is online
Get-ClusterGroup -Name "SOFSSERVER01" | Select-Object Name, State, OwnerNode

# Check the cluster network name and IP address assigned to the SoFS role
Get-ClusterResource | Where-Object OwnerGroup -eq "SOFSSERVER01" |
    Select-Object Name, ResourceType, State

Unlike a standard clustered file server, the SoFS role does not have a preferred owner node — it is designed to run on all nodes simultaneously. The cluster network name (SOFSSERVER01 in this example) is registered in DNS with the IP addresses of all cluster nodes, and Windows SMB clients use SMB Multichannel to connect to multiple nodes at once.

Step 3 — Create SMB Shares on the CSV Volume

File shares for Hyper-V VM storage, SQL Server data files, and general file storage are created under the CSV mount path. Use New-SmbShare to create shares with appropriate permissions.

# Create a directory on the CSV for Hyper-V VM storage
New-Item -Path "C:ClusterStorageVolume1HyperV-VMs" -ItemType Directory

# Create the SMB share for Hyper-V
New-SmbShare `
    -Name "HyperV-VMs" `
    -Path "C:ClusterStorageVolume1HyperV-VMs" `
    -FullAccess "CORPHyper-V-Servers$","CORPDomain Admins" `
    -Description "Hyper-V virtual machine storage" `
    -ScopeName "SOFSSERVER01" `
    -ContinuouslyAvailable $true `
    -EncryptData $true

# Create a share for SQL Server data files
New-Item -Path "C:ClusterStorageVolume1SQLData" -ItemType Directory

New-SmbShare `
    -Name "SQLData" `
    -Path "C:ClusterStorageVolume1SQLData" `
    -FullAccess "CORPSQL-Servers$","CORPDomain Admins" `
    -Description "SQL Server data and log files" `
    -ScopeName "SOFSSERVER01" `
    -ContinuouslyAvailable $true `
    -EncryptData $true

# Verify shares are created and continuously available
Get-SmbShare -ScopeName "SOFSSERVER01" |
    Select-Object Name, Path, ContinuouslyAvailable, EncryptData

The -ContinuouslyAvailable $true flag enables SMB 3.0 Persistent Handles, which allow clients to transparently survive node failures without losing their file handles. The -ScopeName "SOFSSERVER01" parameter associates the share with the SoFS cluster network name rather than a specific node name.

Step 4 — Configure and Verify SMB Multichannel

SMB Multichannel automatically uses multiple network paths between the client and the SoFS server when multiple NICs are available. No manual configuration is required when NICs are RSS-capable or RDMA-capable, but you can verify and optimize the configuration.

# On the SoFS server — verify SMB Multichannel is enabled
Get-SmbServerConfiguration | Select-Object EnableMultiChannel, Smb2CreditsMin, Smb2CreditsMax

# On a client accessing the SoFS share — check active multichannel connections
Get-SmbMultichannelConnection -ServerName "SOFSSERVER01" |
    Select-Object ServerName, ClientNetworkInterface, ServerNetworkInterface,
                  ClientIpAddress, ServerIpAddress, Throughput

# View the NIC capabilities influencing multichannel
Get-SmbMultichannelConstraint
Get-NetAdapterRdma | Select-Object Name, Enabled, InterfaceDescription

# If using RDMA (RoCE or iWARP), verify RDMA is active on the connection
Get-SmbMultichannelConnection -ServerName "SOFSSERVER01" |
    Select-Object ClientNetworkInterface, ServerNetworkInterface, RdmaCapable, Selected

For maximum throughput with RDMA (SMB Direct), ensure that your network adapters support RoCE v2 (for Data Center Bridging networks) or iWARP (for standard TCP networks). RDMA bypasses the CPU for data transfer, significantly reducing latency for VHDX and SQL I/O operations.

Step 5 — Connect Hyper-V to SoFS Storage

Once the SoFS share is available, configure Hyper-V hosts to use it for virtual machine storage. Store VHDX files and VM configuration files directly on the SMB 3.0 share.

# On the Hyper-V host — create a new VM with VHDX on the SoFS share
New-VM `
    -Name "TestVM01" `
    -Path "\SOFSSERVER01HyperV-VMs" `
    -MemoryStartupBytes 4GB `
    -Generation 2

# Create a VHDX disk on the SoFS share
New-VHD `
    -Path "\SOFSSERVER01HyperV-VMsTestVM01TestVM01-OS.vhdx" `
    -SizeBytes 100GB `
    -Dynamic

# Attach the VHDX to the VM
Add-VMHardDiskDrive `
    -VMName "TestVM01" `
    -Path "\SOFSSERVER01HyperV-VMsTestVM01TestVM01-OS.vhdx"

# Verify the VM is using the SoFS share
Get-VMHardDiskDrive -VMName "TestVM01" | Select-Object VMName, Path

Hyper-V communicates with SoFS using SMB 3.0 over the CSV network, and live migration of VMs between cluster nodes requires no data movement when both source and destination nodes access the same SoFS share — the VHDX file stays in place and only the VM state is transferred.

Step 6 — Connect SQL Server to SoFS Storage

SQL Server 2019 and later fully support storing data files (.mdf), log files (.ldf), and TempDB on SMB 3.0 shares. The SQL Server service account must have full NTFS permissions and SMB share permissions on the target path.

# Grant the SQL Server service account access to the SQL share
Grant-SmbShareAccess `
    -Name "SQLData" `
    -ScopeName "SOFSSERVER01" `
    -AccountName "CORPSQLServiceAccount" `
    -AccessRight Full `
    -Force

# Verify share permissions
Get-SmbShareAccess -Name "SQLData" -ScopeName "SOFSSERVER01" |
    Select-Object Name, AccountName, AccessRight

# On the SQL Server — move a database to the SoFS share (T-SQL example via Invoke-Sqlcmd)
Invoke-Sqlcmd -ServerInstance "SQLSERVER01" -Query @"
ALTER DATABASE [MyDatabase] SET OFFLINE;
ALTER DATABASE [MyDatabase]
    MODIFY FILE (NAME = MyDatabase, FILENAME = '\SOFSSERVER01SQLDataMyDatabase.mdf');
ALTER DATABASE [MyDatabase]
    MODIFY FILE (NAME = MyDatabase_log, FILENAME = '\SOFSSERVER01SQLDataMyDatabase_log.ldf');
ALTER DATABASE [MyDatabase] SET ONLINE;
"@

Step 7 — Test High Availability with Node Failover

The defining characteristic of SoFS is its ability to survive node failures without interrupting client I/O. Test this by writing continuously to a file while failing a cluster node.

# On a test client — start a continuous write loop to a file on the SoFS share
$testFile = "\SOFSSERVER01HyperV-VMsha-test.txt"
$job = Start-Job -ScriptBlock {
    param($path)
    $i = 0
    while ($true) {
        Add-Content -Path $path -Value "Write $i at $(Get-Date -Format 'HH:mm:ss.fff')"
        $i++
        Start-Sleep -Milliseconds 100
    }
} -ArgumentList $testFile

# On the SoFS cluster — simulate a node failure by stopping the cluster service
# Run this on the node that is the current CSV coordinator
Stop-ClusterNode -Name "SoFSNode01" -Wait

# Wait a few seconds, then check the client is still writing (no errors)
Receive-Job $job -Keep | Select-Object -Last 10

# Bring the node back online
Start-ClusterNode -Name "SoFSNode01"

# Monitor share access statistics
Get-SmbShareAccess -Name "HyperV-VMs" -ScopeName "SOFSSERVER01"
Get-SmbOpenFile -ScopeName "SOFSSERVER01" | Select-Object ClientComputerName, Path, SessionId

With properly configured Persistent Handles and SMB Multichannel, client connections seamlessly reconnect to the surviving node within the SMB failover timeout (typically less than 60 seconds for Hyper-V workloads) without surfacing an error to the application layer.

Conclusion

Scale-Out File Server on Windows Server 2025 provides a flexible, continuously available storage platform for the most demanding enterprise workloads. By combining Windows Server Failover Clustering with Cluster Shared Volumes, SMB 3.0 Persistent Handles, and SMB Multichannel — optionally accelerated with RDMA NICs — SoFS delivers storage throughput that scales linearly with the number of cluster nodes while maintaining full transparency to Hyper-V and SQL Server clients during hardware failures or planned maintenance. The PowerShell tooling available through the FailoverClusters and SmbShare modules gives you precise control over share creation, permission management, and monitoring, ensuring you can maintain and troubleshoot your SoFS deployment entirely from the command line if needed.