Share via

Unable to replicate vm to azure

noufal nazar 1 Reputation point
2026-03-01T07:12:24.5933333+00:00

Error ID

539

Error Message

The requested action couldn't be performed by the Replication Provider.

Possible causes

The Provider action failed. Check other errors for more information.

Recommendation

Resolve the issue and retry the operation.

First Seen At

3/1/2026, 10:03:39 AM

Error ID

320016

Error Message

Azure Site Recovery
Azure Site Recovery

An Azure native disaster recovery service. Previously known as Microsoft Azure Hyper-V Recovery Manager.


2 answers

Sort by: Most helpful
  1. Bharath Y P 7,240 Reputation points Microsoft External Staff Moderator
    2026-03-03T04:24:05.02+00:00

    Hello noufal nazar, it looks like you’re seeing two errors when trying to replicate your VM:

    • Error ID 539 – “The requested action couldn't be performed by the Replication Provider.”

    • Error ID 320016 – “A provider action failed. Check other errors for more information.”

    Error 539 is generally a catch-all that means something deeper failed first, so we need to dig into the root cause. Here’s a set of steps you can try, plus some follow-up questions if you need to gather more details:

    1. Verify the VM’s provisioning state – Open Azure Portal → All Services → Resource Explorer. – Navigate to Subscriptions → your sub → ResourceGroups → your RG → Resources → your VM. – Confirm that provisioningState is Succeeded. • If it’s Failed, we’ll need to troubleshoot that first (contact support with the failure details). • If it’s Updating, wait for any extensions or updates to finish before retrying replication.
    2. Check for resource locks or stale Site Recovery config – In the Portal, go to your VM and VM resource group → Locks, and remove any locks you see. – If this VM had replication enabled previously (or its vault/RG was deleted without disabling replication), a stale ASR config can block new attempts. – Run the Cleanup-stale-asr-config-Azure-VM.ps1 script to remove old links:
      1. Download from https://github.com/AsrOneSdk/published-scripts/blob/master/Cleanup-Stale-ASR-Config-Azure-VM.ps1
      2. Run it with parameters: SubscriptionID, VMResourceGroupName, VMName.
      3. Confirm it completes without errors.
    3. Disable and re-enable replication – In your Recovery Services vault → Replicated Items → select the VM → Disable replication. – Wait a few minutes, then choose Enable replication again. – This clears any transient provider issues.
    4. Validate network mapping (Azure-to-Azure only) – If your source VM is in a vNet, make sure that network isn’t already mapped to a target vNet in the vault’s Site Recovery Infrastructure → Network Mappings. – If you disabled replication previously, delete the old mapping and recreate it.
    5. Review quotas and NSG rules – Ensure you have sufficient compute/storage quota in the target region. – Verify any NSG or Firewall rules allow the required outbound traffic for Azure Site Recovery (see “Azure-to-Azure replication network requirements”).
    6. Retry the replication job – Once you’ve addressed provisioning, stale configs, locks, networking, and quotas, kick off the replication again and watch the job history for any new errors.

    Follow-up questions

    • Are you doing an Azure-to-Azure (A2A) replication, or is this coming from on-prem Hyper-V/VMware?

    • Did this VM ever have ASR protection enabled in a vault that was later deleted?

    • Can you share the exact region and resource group names you’re using?

    • Are there any other related errors in the vault job history or the VM’s activity log?

    • Have you checked that no resource locks remain on the VM or its RG?

    References

    1. Clean up stale A2A configuration
    2. Troubleshoot Azure-to-Azure VM replication errors

    Hope this helps! Let me know if you need further assistance. Thanks

    0 comments No comments

  2. Q&A Assist
    2026-03-01T07:12:40.7033333+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    Error ID 539 with the message “The requested action couldn't be performed by the Replication Provider” indicates that the Azure Site Recovery replication provider failed to perform the requested action and that additional, more specific errors must be checked to identify the root cause.

    Troubleshooting steps:

    1. Check for additional error details
      • In the Azure portal, open the Recovery Services vault.
      • Go to Replicated items and select the affected VM.
      • Review the Health/Error details or recent job history for this VM to find any other error IDs/messages that occurred with or before 539. Those secondary errors usually indicate the real cause (for example, connectivity, configuration, or VM state issues).
    2. Verify VM can be selected and protected
      • If protection is failing at the “select VM” or “enable protection” stage, verify that the VM does not have any failed or unresponsive extensions:
        • Go to Virtual machines > select the VM > Settings > Extensions.
        • If any extension is in a failed state, uninstall it and then retry enabling replication.
    3. Check for stale Site Recovery configuration (if VM was previously protected)
      • If the VM was protected before and replication was disabled, stale Site Recovery resource links on the VM can block re-protection and cause provider failures.
      • If the VM or its resource group has a resource lock, remove the lock.
      • Run the cleanup script described in the documentation to remove stale ASR configuration from the VM, then retry enabling replication.
    4. Validate disks and disk configuration
      • If the error appears when adding or protecting disks:
        • Ensure all newly attached data disks are initialized inside the guest OS.
        • For Azure-to-Azure replication, uninitialized or mismatched LUN reporting can cause disk-related errors that surface as provider failures.
        • After initializing disks, retry the operation.
    5. Check outbound connectivity and proxy/NSG configuration
      • If there are network restrictions (NSGs, firewalls, or proxies) on the VM or subnet, the provider may fail to reach Azure Site Recovery endpoints:
        • Ensure outbound connectivity is configured using supported service tags for Azure Site Recovery; IP allowlists are no longer supported for Azure-to-Azure replication.
        • If using a proxy for outbound traffic from Mobility service agents:
          • Confirm the proxy settings are valid and detectable (Internet Explorer on Windows, /etc/environment on Linux), or configure ProxyInfo.conf in the ASR config directory.
          • Ensure the proxy is unauthenticated, as authenticated proxies are not supported.
    6. Retry the operation after remediation
      • After fixing any identified issues (extensions, stale configuration, disk initialization, or network/proxy configuration), retry the failed action (enable protection, failover, or other replication operation).
      • If the issue persists and no additional error details are available beyond 539, open a support case with the full job details and error history for deeper investigation.

    References:

    0 comments No comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.