How to Configure Azure Site Recovery for Windows Server 2025

How to Configure Azure Site Recovery for Windows Server 2025

Disaster recovery planning for physical and virtual Windows Server 2025 workloads has never been more accessible than it is with Azure Site Recovery (ASR). ASR provides a mature, enterprise-grade replication engine that continuously captures changes from your on-premises servers and replicates them to Azure, maintaining a recovery point that can be failed over within minutes of a declared disaster. Unlike traditional backup-and-restore DR approaches that involve hours of bare-metal restores, ASR keeps a live replicated copy of your server in Azure, ready to spin up at any moment. This guide walks through every step of configuring ASR for physical-to-Azure replication, from creating the Recovery Services Vault to executing your first test failover and verifying application health in the recovery environment.

Prerequisites

• Azure subscription with Contributor or Owner rights on the target resource group
• Windows Server 2025 physical server or VM (the protected workload) with outbound internet access
• Microsoft Azure Recovery Services (MARS) agent prerequisites: .NET Framework 4.6.2 or later on source server
• Supported Windows Server OS version confirmed in ASR support matrix
• Azure Virtual Network pre-created for failover target (production and test VNets recommended)
• Azure Storage Account (Standard LRS or GRS) in the same region as the Recovery Services Vault for cache
• Outbound connectivity from source server to *.hypervrecoverymanager.windowsazure.com and *.blob.core.windows.net
• Local administrator credentials on the source Windows Server 2025 machine

Step 1: Create the Recovery Services Vault in Azure

The Recovery Services Vault is the central management container for ASR. All replication configuration, failover plans, and recovery points are stored and managed within it. Create it in the Azure region geographically closest to your recovery target, not your source servers.

# Authenticate to Azure
Connect-AzAccount -TenantId "your-tenant-id"
Set-AzContext -SubscriptionId "your-subscription-id"

# Define variables
$resourceGroupName = "rg-dr-eastus"
$vaultName         = "rsv-contoso-dr"
$location          = "EastUS"

# Create resource group for DR infrastructure
New-AzResourceGroup -Name $resourceGroupName -Location $location

# Create Recovery Services Vault
$vault = New-AzRecoveryServicesVault `
    -Name $vaultName `
    -ResourceGroupName $resourceGroupName `
    -Location $location

# Set vault context for subsequent operations
Set-AzRecoveryServicesAsrVaultContext -Vault $vault

# Configure vault redundancy (GRS recommended for DR)
Set-AzRecoveryServicesBackupProperty -Vault $vault `
    -BackupStorageRedundancy GeoRedundant

# Verify vault creation
Get-AzRecoveryServicesVault -Name $vaultName -ResourceGroupName $resourceGroupName |
    Select-Object Name, Location, ResourceGroupName, SubscriptionId

Step 2: Configure Replication Infrastructure (Configuration Server or Agentless)

For physical-to-Azure replication of Windows Server 2025, you have two paths: deploying a Configuration Server (a Windows Server that acts as an on-premises replication gateway) or using the agentless approach via Azure Migrate for VMware-hosted VMs. Physical bare-metal servers require the Configuration Server path.

# Download the ASR Configuration Server installer from the vault
# (Do this through Azure Portal or via REST API - the installer is vault-specific)
# Navigate to: Recovery Services Vault > Site Recovery > Step 1: Prepare Infrastructure

# On the Configuration Server (a dedicated Windows Server 2025 VM on-premises):
# Verify prerequisites before running the installer

# Check .NET Framework version
$netRegPath = "HKLM:SOFTWAREMicrosoftNET Framework SetupNDPv4Full"
$netVersion = (Get-ItemProperty -Path $netRegPath).Release
if ($netVersion -ge 394802) {
    Write-Output ".NET 4.6.2 or later is installed. Release key: $netVersion"
} else {
    Write-Warning ".NET 4.6.2 or later is required. Current release key: $netVersion"
}

# Disable Windows Firewall temporarily during setup (re-enable after)
# Or create specific rules for ASR ports
$asrPorts = @(443, 9443, 9080)
foreach ($port in $asrPorts) {
    New-NetFirewallRule `
        -DisplayName "ASR Outbound Port $port" `
        -Direction Outbound `
        -Protocol TCP `
        -RemotePort $port `
        -Action Allow `
        -Profile Domain, Private
}

# Verify internet connectivity to required ASR endpoints
$endpoints = @(
    "*.hypervrecoverymanager.windowsazure.com",
    "*.blob.core.windows.net",
    "*.accesscontrol.windows.net",
    "login.microsoftonline.com"
)
foreach ($ep in $endpoints) {
    $test = Test-NetConnection -ComputerName ($ep -replace '*.', 'test.') -Port 443 -InformationLevel Quiet
    Write-Output "$ep port 443: $test"
}

Step 3: Install the Mobility Service on Windows Server 2025

The Mobility Service is the ASR agent installed on each protected Windows Server 2025 machine. It intercepts disk I/O at the volume level and streams changes to the Configuration Server, which forwards them to Azure. You can install it manually, via push from the Configuration Server, or silently via Group Policy or SCCM.

# Silent Mobility Service installation on the protected server
# Download the installer from the Configuration Server's push installation share
# \MSSQLDataMobility Service

$mobilityInstallerPath = "\config-server.contoso.localASRInstallMicrosoftAzureSiteRecoveryMobilityServiceInstaller.exe"
$configServerIP       = "10.0.1.10"
$passphraseFile       = "C:ASRpassphrase.txt"

# Install Mobility Service silently
$installArgs = @(
    "/q",
    "/x:C:ASRMobSvc",
    "/role:MS",
    "/instdir:C:Program Files (x86)Microsoft Azure Site Recovery",
    "/Platform:VmWare",
    "/Silent"
)

Start-Process -FilePath $mobilityInstallerPath -ArgumentList $installArgs -Wait -NoNewWindow

# Register the agent with the Configuration Server
$registrationArgs = @(
    "-i", $configServerIP,
    "-P", $passphraseFile,
    "-t", "MA"
)

$mobSvcInstall = "C:Program Files (x86)Microsoft Azure Site RecoveryhomesvsystemsbinUnifiedAgentConfigurator.exe"
Start-Process -FilePath $mobSvcInstall -ArgumentList $registrationArgs -Wait -NoNewWindow

# Verify Mobility Service is running
Get-Service -Name "InMage Scout Application Service" -ErrorAction SilentlyContinue
Get-Service -Name "svagents" -ErrorAction SilentlyContinue

Step 4: Configure Replication Policy and Enable Replication

The replication policy defines the recovery point objective (RPO) and retention settings. ASR for physical servers supports RPO targets as low as 15 minutes for crash-consistent points and up to every hour for application-consistent snapshots that use VSS.

# Create a replication policy via Azure PowerShell
$replicationPolicyParams = @{
    Name                              = "ReplicationPolicy-WS2025"
    ReplicationProvider               = "InMageAzureV2"
    RecoveryAzureStorageAccountId     = (Get-AzStorageAccount -ResourceGroupName $resourceGroupName `
                                            -Name "stcontosoasrcache").Id
    ReplicationFrequencyInSeconds     = 900   # 15-minute RPO (crash-consistent)
    RecoveryPointRetentionInHours     = 72    # 72-hour crash-consistent retention
    ApplicationConsistentSnapshotFrequencyInHours = 24  # 24-hour app-consistent
    Encryption                        = "Disable"
}

$fabricClient = Get-AzRecoveryServicesAsrFabric
$policy = New-AzRecoveryServicesAsrPolicy @replicationPolicyParams

# Enable replication for the protected server
$targetResourceGroup = Get-AzResourceGroup -Name "rg-dr-failover-eastus"
$targetVNet          = Get-AzVirtualNetwork -Name "vnet-dr-eastus" -ResourceGroupName $targetResourceGroup.ResourceGroupName

# Configure replication for the protected item (physical server)
$protectionContainerMapping = Get-AzRecoveryServicesAsrProtectionContainerMapping

$replicationParams = @{
    ReplicateVMwareToAzure = $true
    ProtectableItem        = Get-AzRecoveryServicesAsrProtectableItem -FriendlyName "ws2025-prod-01"
    Policy                 = $policy
    RecoveryAzureVmName    = "ws2025-prod-01-dr"
    RecoveryResourceGroupId = $targetResourceGroup.ResourceId
    RecoveryAzureNetworkId  = $targetVNet.Id
    RecoveryAzureSubnetName = "snet-dr-primary"
    RecoveryAzureStorageAccountId = (Get-AzStorageAccount -ResourceGroupName $resourceGroupName `
                                         -Name "stcontosoasr").Id
}

$replicationJob = New-AzRecoveryServicesAsrReplicationProtectedItem @replicationParams

# Monitor replication enablement job
Get-AzRecoveryServicesAsrJob -Job $replicationJob | Select-Object State, StartTime, EndTime

Step 5: Monitor Replication Health and RPO Compliance

After replication is enabled, the initial replication (IR) phase copies all data to Azure. This can take hours to days depending on data volume and network bandwidth. Once IR completes, ASR enters the continuous delta replication phase.

# Check replication status for all protected items
Get-AzRecoveryServicesAsrReplicationProtectedItem |
    Select-Object FriendlyName, ProtectionState, ReplicationHealth,
                  LastSuccessfulFailoverTime, RecoveryPointType |
    Format-Table -AutoSize

# Check detailed health for a specific item
$protectedItem = Get-AzRecoveryServicesAsrReplicationProtectedItem -FriendlyName "ws2025-prod-01"
$protectedItem | Select-Object *

# List available recovery points
$recoveryPoints = Get-AzRecoveryServicesAsrRecoveryPoint -ReplicationProtectedItem $protectedItem
$recoveryPoints | Select-Object FriendlyName, RecoveryPointType, RecoveryPointTime |
    Sort-Object RecoveryPointTime -Descending | Select-Object -First 10

# Check RPO compliance
$protectedItem.ProviderSpecificDetails | Select-Object RpoInSeconds, LastRpoCalculatedTime
$rpoMinutes = [math]::Round($protectedItem.ProviderSpecificDetails.RpoInSeconds / 60, 1)
Write-Output "Current RPO: $rpoMinutes minutes"
if ($rpoMinutes -gt 15) {
    Write-Warning "RPO exceeds 15-minute target! Investigate replication lag."
}

Step 6: Create and Execute a Test Failover

A test failover is the most critical validation step in any DR strategy. ASR allows you to fail over to an isolated Azure VNet without disrupting ongoing replication or the production workload, making it safe to run regularly as part of your DR testing calendar.

# Select the recovery point for test failover (latest app-consistent)
$appConsistentRP = $recoveryPoints |
    Where-Object { $_.RecoveryPointType -eq "AppConsistent" } |
    Sort-Object RecoveryPointTime -Descending |
    Select-Object -First 1

Write-Output "Using recovery point: $($appConsistentRP.RecoveryPointTime) [$($appConsistentRP.RecoveryPointType)]"

# Get the isolated test VNet (never use production VNet for test failover)
$testVNet = Get-AzVirtualNetwork -Name "vnet-asr-test-isolated" -ResourceGroupName $resourceGroupName

# Start test failover
$testFailoverParams = @{
    ReplicationProtectedItem = $protectedItem
    RecoveryPoint            = $appConsistentRP
    Direction                = "PrimaryToRecovery"
    AzureVMNetworkId         = $testVNet.Id
    AzureVMSubnet            = "snet-test"
    TestFailoverNetworkId    = $testVNet.Id
}

$testFailoverJob = Start-AzRecoveryServicesAsrTestFailoverJob @testFailoverParams

# Monitor test failover progress
do {
    $jobStatus = Get-AzRecoveryServicesAsrJob -Job $testFailoverJob
    Write-Output "Status: $($jobStatus.State) | $(Get-Date -Format 'HH:mm:ss')"
    Start-Sleep -Seconds 30
} until ($jobStatus.State -in @("Succeeded", "Failed", "Cancelled"))

Write-Output "Test failover completed with status: $($jobStatus.State)"

Step 7: Validate Application Health After Failover and Clean Up

After the test failover completes, the Azure VM is running in the isolated test VNet. Connect to it and verify that all critical services, databases, and application endpoints are healthy before marking the test as successful.

# Get the failed-over VM details
$testVM = Get-AzVM -ResourceGroupName $targetResourceGroup.ResourceGroupName `
    -Name "ws2025-prod-01-dr" -ErrorAction SilentlyContinue

if ($testVM) {
    Write-Output "Test VM Status: $(($testVM | Get-AzVM -Status).Statuses[1].DisplayStatus)"
    Write-Output "Test VM IP: $(($testVM | Get-AzNetworkInterface | Get-AzNetworkInterfaceIpConfig).PrivateIpAddress)"
}

# Validate services via PowerShell remoting to test VM (through Azure Bastion or VPN)
$testVmIp = "10.1.0.10"  # From the test VNet
$cred = Get-Credential -Message "Enter test VM credentials"

$validationResults = Invoke-Command -ComputerName $testVmIp -Credential $cred -ScriptBlock {
    @{
        IIS      = (Get-Service W3SVC -ErrorAction SilentlyContinue).Status
        SQL      = (Get-Service MSSQLSERVER -ErrorAction SilentlyContinue).Status
        AD       = (Test-ComputerSecureChannel -ErrorAction SilentlyContinue)
        DiskFree = (Get-PSDrive C | Select-Object -ExpandProperty Free) / 1GB
        Uptime   = (Get-Date) - (gcim Win32_OperatingSystem).LastBootUpTime
    }
}

$validationResults | Format-List

# After validation is complete, clean up the test failover
# This removes the test VM but keeps replication running
$cleanupJob = Start-AzRecoveryServicesAsrTestFailoverCleanupJob `
    -ReplicationProtectedItem $protectedItem `
    -Comment "Test failover validated on $(Get-Date -Format 'yyyy-MM-dd'). All services healthy."

Get-AzRecoveryServicesAsrJob -Job $cleanupJob | Select-Object State, DisplayName

Conclusion

Azure Site Recovery transforms disaster recovery from a periodic, disruptive project into a continuous background process with live recovery points that genuinely reflect your production environment. For Windows Server 2025 workloads, the combination of a 15-minute RPO for crash-consistent recovery points and 24-hour application-consistent snapshots means that even in the worst-case failover scenario, you lose at most 15 minutes of data while application state is preserved from the most recent VSS snapshot. The test failover capability — running the full recovery process against an isolated VNet without touching production replication — means you can validate your DR plan monthly without disruption or risk. Make test failovers a scheduled event in your operations calendar, document the RTO and RPO actuals each time, and use those measurements to continuously refine your replication settings and network bandwidth allocation between your on-premises site and Azure.