How to Configure Windows Server Storage Replica using PowerShell

The Need for Block-Level Replication

In an enterprise environment, Disaster Recovery (DR) is critical. If your primary data center in New York loses power due to a massive storm, your Hyper-V virtual machines must instantly spin up in your secondary data center in London. However, spinning up the VMs is useless if the London data center doesn’t have an exact, up-to-the-second copy of the underlying hard drives.

Historically, replicating block-level data across data centers required incredibly expensive, proprietary SAN hardware (like EMC SRDF). Microsoft democratized this with Windows Server 2016 by introducing Storage Replica. This feature operates entirely in software at the Windows block level. Every time a block of data is written to the D: drive in New York, Windows intercepts it and replicates it perfectly across the WAN to the D: drive in London.

Storage Replica supports both Synchronous replication (for zero data loss on low-latency LANs) and Asynchronous replication (for high-latency intercontinental WANs). Deploying this architecture requires strict PowerShell configuration.

Step 1: Installing the Storage Replica Role

You must install the Storage Replica feature on both the source server (NYC-SRV-01) and the destination server (LON-SRV-01).

Open an elevated PowerShell session on both servers and execute:

Install-WindowsFeature -Name Storage-Replica, FS-FileServer -IncludeManagementTools -Restart

Step 2: Preparing the Volumes

Storage Replica has strict hardware requirements. Both servers must have two identically sized, GPT-formatted volumes:

1. Data Volume: This holds your actual files (e.g., the D: drive, 2TB).
2. Log Volume: This is a dedicated, high-speed (preferably NVMe) drive used exclusively to cache the replication logs before they are sent over the network (e.g., the L: drive, 50GB).

Step 3: Testing the Topology

Before you force Windows to begin replicating 2TB of data, you must run a cryptographic topology test to ensure your network bandwidth and latency can actually handle the load.

Execute the following on the source server (New York):

Test-SRTopology -SourceComputerName "NYC-SRV-01" -SourceVolumeName "D:" -SourceLogVolumeName "L:" -DestinationComputerName "LON-SRV-01" -DestinationVolumeName "D:" -DestinationLogVolumeName "L:" -DurationInMinutes 10 -ResultPath "C:\SR_Report"

This command will simulate a massive I/O load for 10 minutes and generate a detailed HTML report in the C:\SR_Report folder. Review this report carefully to ensure your network links are not saturated.

Step 4: Establishing the Replication Partnership

If the topology test passes, you can officially bind the two servers together.

Because London is thousands of miles away and the network latency is high, we must use Asynchronous replication (to prevent the New York server from stalling while waiting for an acknowledgement from London).

Execute this command on the New York server to form the partnership:

New-SRPartnership -SourceComputerName "NYC-SRV-01" -SourceRGName "NYC-Group" -SourceVolumeName "D:" -SourceLogVolumeName "L:" -DestinationComputerName "LON-SRV-01" -DestinationRGName "LON-Group" -DestinationVolumeName "D:" -DestinationLogVolumeName "L:" -ReplicationMode Asynchronous

Step 5: Monitoring the Initial Sync

The moment you press Enter, Windows Server locks the D: drive in London (it becomes completely inaccessible to prevent data corruption) and begins the massive initial block copy of the 2TB drive over the WAN.

You can monitor the exact progress of this initial sync by querying the WMI replication metrics:

Get-SRGroup | Select-Object ReplicationStatus

Once the status transitions from InitialBlockCopy to ContinuouslyReplicating, your Disaster Recovery architecture is fully operational. If the New York server explodes, you can use the Set-SRPartnership cmdlet to instantly promote the London server, instantly mounting the fully replicated D: drive and bringing your applications back online.