How to Configure Storage Spaces Direct (S2D) on Windows Server

Storage Spaces Direct (S2D) turns local disks in a group of servers into a single pool of shared, resilient storage without a traditional SAN. It’s the storage layer behind most hyperconverged infrastructure (HCI) deployments on Windows Server, and it’s a lot more approachable to set up than people expect once you understand the moving parts. This guide walks through a real S2D deployment from prerequisites to your first volume.

• S2D requires Windows Server 2016 Datacenter or later — it’s not available in Standard edition
• Minimum of 2 nodes for a basic cluster, but 4+ is recommended for production so you can tolerate a node failure without losing resiliency
• Each node needs at least one NVMe or SSD for caching, plus additional SSDs or HDDs for capacity
• A dedicated, low-latency network (RDMA if possible) between nodes is critical — S2D is very sensitive to network quality
• All disks used for S2D must be empty and unformatted before you start

Prerequisites and hardware checklist

Before touching PowerShell, validate your hardware against the official Storage Spaces Direct hardware requirements. The most common mistake is mixing drive firmware versions or using consumer-grade SSDs that don’t handle sustained write loads well — S2D will run on them, but performance and reliability suffer badly under load. If you’re buying hardware specifically for S2D, look for vendor-validated nodes; Microsoft publishes a list of certified configurations for exactly this reason.

Each node should also have at least two network adapters dedicated to cluster and storage traffic, separate from your management NIC. If you can get RDMA-capable adapters (iWARP or RoCE), use them — S2D performance without RDMA is noticeably worse under heavy I/O.

Step 1: Install the Failover Clustering feature

On every node that will participate in the cluster, install the Failover Clustering feature:

Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools

Step 2: Validate the cluster configuration

Run cluster validation before creating anything — this catches network misconfigurations and disk issues early, and Microsoft support will ask for this report if you ever open a ticket:

Test-Cluster -Node Node1,Node2,Node3,Node4 -Include "Storage Spaces Direct", "Inventory", "Network", "System Configuration"

Review the generated HTML report carefully. Pay particular attention to any warnings about disk latency, mismatched firmware, or network adapters not configured for RDMA — these are the issues that come back to bite you in production if ignored now.

Step 3: Create the cluster

Once validation passes cleanly, create the cluster itself:

New-Cluster -Name S2D-Cluster01 -Node Node1,Node2,Node3,Node4 -NoStorage

The -NoStorage switch is important — it stops the cluster wizard from automatically claiming your local disks for traditional clustered storage before S2D gets a chance to pool them properly.

Step 4: Enable Storage Spaces Direct

With the cluster formed, enable S2D itself. This single cmdlet pools all eligible disks across every node and configures caching automatically based on the drive types it detects:

Enable-ClusterStorageSpacesDirect -PoolFriendlyName "S2D-Pool01"

This step can take a while depending on the number and size of disks involved — don’t panic if it sits for several minutes on larger deployments.

Step 5: Create your first volume

Once the pool exists, create a volume with your chosen resiliency type. Three-way mirroring is the safest option for most workloads and tolerates two simultaneous drive failures:

New-Volume -StoragePoolFriendlyName "S2D-Pool01" -FriendlyName "Volume01" -FileSystem CSVFS_ReFS -Size 2TB -ResiliencySettingName Mirror

Common issues and how to avoid them

The vast majority of S2D problems trace back to one of three causes: inconsistent drive firmware across nodes, network adapters that aren’t actually configured for RDMA even though the hardware supports it, and undersized cache drives relative to capacity drives. If performance degrades over time rather than being bad from day one, check Get-StorageJob for background repair or resync operations — S2D silently repairs itself after a node reboot or transient failure, and that repair traffic competes with production I/O until it finishes.

Once your volumes are up and running, it’s worth reading through our guide on setting up Windows Server Failover Clustering if you haven’t already, since S2D builds directly on top of it.