“Azure Site Recovery Migration: Troubleshooting Errors During Classic to Modern Transition”
Classic to Modern Azure Site Recovery Migration: Deployment Experience and Key Challenges
Migrating from Classic Azure Site Recovery (ASR) to the Modern ASR Appliance architecture introduces several operational differences. During a recent migration, we encountered practical deployment challenges that are worth documenting for others performing similar transitions.
OVF Deployment – Unexpected Boot Delay
The Modern ASR Appliance was downloaded as an OVF template and deployed into the VMware vCenter environment.
Deployment itself was straightforward:
• Import OVF
• Assign network configuration
• Complete virtual hardware mapping
However, an unexpected issue arose during the first power-on.
The virtual machine took approximately:
30 to 40 minutes to boot
This behaviour initially suggested:
• Resource bottleneck
• OVF corruption
• Guest OS issue
After reviewing multiple technical forums and blogs, a useful recommendation emerged:
Power on the appliance directly from the ESXi host instead of vCenter
When tested, the result was dramatic:
Boot time reduced to ~5 seconds
Why This Happens
This delay is commonly associated with:
• vCenter resource negotiation
• Storage latency during initial provisioning
• VM hardware compatibility checks
• Network dependency resolution
Direct ESXi power-on bypasses several orchestration layers, allowing faster initialization.
Initial Appliance Configuration
After successful boot, configuration was performed using the Appliance Configuration Manager (web interface).
Steps included:
1️⃣ Accessing the Web Interface
Using the appliance IP address:
https://<Appliance-IP>
Full administrative access was confirmed.
2️⃣ Pre-Check Validation
The appliance provides built-in validation checks for:
• Internet Connectivity
• Firewall Configuration
• Time Synchronization
• Process Server Status
• Component Versions
All checks were verified prior to proceeding.
This step is critical because most replication failures originate from:
• Network filtering
• TLS handshake failures
• Time drift
• Missing dependencies
3️⃣ PowerShell Access Permission
The appliance requested PowerShell execution permissions, which are necessary for:
• Agent push installation
• Machine discovery
• Credential validation
Appropriate permissions were granted.
4️⃣ Azure Authentication
The appliance was authenticated against Microsoft Azure by logging into:
Microsoft Azure Portal
During this step:
• Recovery Services Vault public key was validated
• Secure channel established
5️⃣ Recovery Vault Registration
Vault registration ensures:
• Appliance identity mapping
• Fabric creation
• Replication provider linking
6️⃣ VMware vCenter Integration
The following details were supplied:
• vCenter Server Address
• VMware Credentials
• Windows Server Administrator Credentials
This enables:
• Machine discovery
• Mobility Service deployment
• Replication orchestration
7️⃣ Host & Port Configuration
Key configuration items:
• VM Host Selection
• Communication Port → 9443
Port 9443 is mandatory for:
• Mobility Service communication
• Replication Provider channel
• Appliance ↔ Protected Machine interaction
Failure to allow this port results in common ASR errors:
• Mobility Service Installation Failure
• Replication Provider Errors
• Misleading Certificate Errors
Key Lessons Learned
✔ Boot delays after OVF deployment are not uncommon
✔ Direct ESXi power-on can eliminate long initialization times
✔ Pre-check validation prevents most replication issues
✔ Port 9443 is a critical dependency
✔ Modern ASR behaviour differs significantly from Classic ASR
Conclusion
Migrating to the Modern Azure Site Recovery Appliance improves scalability and reliability but introduces new operational considerations. Understanding deployment nuances and network dependencies significantly reduces troubleshooting time.
- 28143
- Recovery Services vault does not have permission to access storage account /subscriptions/XXXXXXXXXX-xxxx-ttttttt-b444-32344cb34fd6/resourcegroups/azuresiterecovery/providers/microsoft.storage/storageaccounts/XXXXXasrstorage.
- Required permissions are not configured on the storage account.
- 1. Go to your Storage account '/subscriptions/XXXXXX-xxxx-ttttt-b444-/resourcegroups/azuresiterecovery/providers/microsoft.storage/storageaccounts/XXXXXasrstorage' -> Access Control (IAM). 2. Add the below role-assignments (for ARM based storage account) to the Recovery services vault's MSI. a) "Contributor" And, b) "Storage Blob Data Contributor" for Standard storage or "Storage Blob Data Owner" for Premium storage Above permissions need to be added for System Assigned Managed Identity if only system MSI is present. If only user assigned managed identity is present or user assigned identity is present along with system assigned identity, add the above permissions to your storage account for user assigned identity. You can refer to https://aka.ms/asrGrantManagedIdentityToTheVault for more details. If you are not using any managed Identity for the vault, make sure to provide these permissions to the application 'Hyper-V Recovery Manager'.
- 2/19/2026, 4:12:54 PM
- click on the storage container and select IAM and Add Role Assignment we have contributor and Storage Blob Data Contributor click on the add select role like Contributor or Storage Blob and click and
- select the Recovery Service Vault Name and on preview and finish
- 539
- The requested action couldn't be performed by the Replication Provider.
- The Provider action failed. Check other errors for more information.
- Resolve the issue and retry the operation.
- 2/19/2026, 4:12:54 PM
- 90078
- Replication for ABCDEFLOCAL (10.8.0.73) (Disk0) hasn't progressed in the last 60 minutes.
- {78217} Process Server is not able to accept more data for the following disk(s). 1. Disk0, ObservationTime : 2026-Feb-19 11:04:49 UTC.
- Replication may not be progressing due to 1. Network connectivity issues between the process server and the log/target Azure storage account (or master target server if replicating back to an on-premises site) 2. The Azure subscription of the target storage account has been disabled.
- 1. Ensure that there is network connectivity between the process server and the log/target Azure storage account (or master-target server if replicating back to an on-premises site.) 2. If Identity is enabled on the Recovery Services Vault, please make sure the log/target Azure storage account has the necessary permissions to access the storage account. a) Go to your Storage account -> Access Control (IAM). b) Add the below role-assignments (for ARM based storage account) to the Recovery services vault. 1) "Contributor" and, 2) "Storage Blob Data Contributor" for Standard storage or "Storage Blob Data Owner" for Premium storage 3. Ensure that the "Microsoft Azure Recovery Services Agent", and "InMage Scout Vx Agent - Sentinel/Outpost" services are running on the process server machine. Try restarting these services on the process server. Refer to the article https://aka.ms/asr-v2a-replication-not-progressing , to learn how to troubleshoot replication issues. If the issue persists, contact support.
- 327504
- Process server is not able to accept more data for the following disk(s). 1. \\.\PHYSICALDRIVE0, ObservationTime : 2026-Feb-19 11:45:29 UTC.
- The Process server might not be in a healthy state.
- Go to the Process server and check for active health issues and recommendations. Refer to the article https://aka.ms/troubleshoot-process-server to learn how to monitor and troubleshoot Process server.
- 2/19/2026, 5:26:15 PM
- 78251
- The replication of the machine 'UMS' is currently not happening via the current Recovery Services vault.
- The migration to modernized experience is in progress.
- Replication will be critical in the classic Recovery Services vault while migration is in progress and post completion. The healthy replication would be happening via the modernized Recovery Services vault, and it is recommended to track the replication in that vault Learn more at https://go.microsoft.com/fwlink/?linkid=2189559.
- 2/19/2026, 4:19:40 PM
- 78172
- No heartbeat received from the mobility service on the source machine 'UMS' in the last 15 minutes.
- The mobility service is not running on the source machine or there is no network connectivity from the source machine to the configuration server.
- Ensure that 1) The "InMage Scout VX Agent - Sentinel/Outpost" service is running on the source machine 2) The source machine has network connectivity to the configuration server on the configuration server TCP port 443. Read more at https://aka.ms/asr-v2a-no-heartbeat.
- 2/19/2026, 4:47:07 PM
- 78143
- No crash consistent recovery point available for the VM in the last 60 minutes.
- 1. Replication is delayed due to network connectivity issues or low bandwidth availability. Upgrade to 9.28 or above to get network latency related errors. 2. Process Server is not able to achieve the required bandwidth. Check Process Server related alerts. Upgrade to 9.27 or above to get PS related errors. 3. The data change rate (write bytes/sec) for one or more disks of the source machine has exceeded ASR supported limits. Refer https://aka.ms/asr-v2a-target-limits.
- Ensure that: 1. Network connectivity exists between the source machine and the process server, between the source machine and the Configuration Server and also between the Process Server and Azure storage account. 2. There is sufficient network bandwidth available between the protected machine and the process server, and the process server and Azure. 3. Ensure that the target storage type (Standard or Premium) is provisioned as per the churn rate requirement at source. 4. Look for any associated events in the ASR events table and also any errors on the Site Recovery vault overview blade, and resolve them if any. 5. If the issue persists contact support.
- 2/19/2026, 5:23:50 PM
Comments
Post a Comment