Azure Site Recovery: Unable to Re-enable Protection for Clustered Hyper-V VM — Error 70153

Question

Azure Site Recovery: Unable to Re-enable Protection for Clustered Hyper-V VM — Error 70153

DBand-6808 0

Problem description

I am unable to enable protection for a Hyper-V virtual machine that is part of a cluster after it was previously protected and then removed. The protection setup fails with Error ID 70153, stating that the VM is part of a cluster but is not highly available. Despite verifying that the VM appears as a clustered role in Failover Cluster Manager, the error persists. I have already tried deleting and re-adding the VM, ensuring disks are on shared storage, and confirming the cluster's health.

Environment

Azure Site Recovery is used to replicate on-premises Hyper-V VMs to Azure. The affected VM belongs to a Hyper-V cluster with clustered storage, and the issue is limited to this VM. The environment involves a Hyper-V cluster with shared storage, and the region, vault configuration, and agent version details are not specified.

What I've already tried

I verified that the VM is highly available in the Hyper-V cluster, despite Azure Site Recovery reporting otherwise. I considered stale Azure Site Recovery metadata but proceeded to delete and recreate the VM and disks, then reattached them. I also checked for locks on Azure resources and confirmed the cluster's health and configuration. However, the protection still fails with Error 70153.

Current status

The protection setup continues to fail with Error 70153, indicating the VM is not recognized as highly available in the cluster, despite it appearing as such. I am seeking guidance on how to resolve this inconsistency between the cluster's state and Azure Site Recovery's detection, and whether additional cluster configuration steps are necessary.

Aliva Mohanty 0 Reputation points Microsoft External Staff

2026-10-21T06:08:56.7866667+00:00
Hi @DBand-6808,

Thanks for reaching out to Microsoft Q&A.

You protected a Hyper-V VM in a failover cluster with Azure Site Recovery, removed protection, and now can't enable it again. Site Recovery fails with error 70153, saying the VM is part of a cluster but isn't highly available. Failover Cluster Manager shows the VM as a clustered role on shared storage, the cluster is healthy, and deleting and re-adding the VM didn't help. You'd like to know why Site Recovery sees the VM differently from the cluster and how to fix it.

Why this happens

Site Recovery doesn't read the VM's state directly from Failover Cluster Manager. It uses what the Site Recovery Provider on the Hyper-V hosts (or System Center VMM, if you use it) last reported to the vault. Earlier protection can leave old replication settings on the host or old data in the vault. Recreating the VM can also leave the cluster role pointing to the old VM configuration. Either way, Site Recovery may still see the VM as not highly available.

Microsoft documents a fix for the closely related error 70094 ("virtual machine is not highly available"): restart the VMM service, then remove the VM from the cluster and add it again. The steps below follow that approach and also clean up anything left over.

Reference: https://learn.microsoft.com/en-us/azure/site-recovery/hyper-v-azure-troubleshoot

Step 1: Remove leftover replication settings from the host

On the cluster node that currently owns the VM, run in an elevated PowerShell window:

Get-VMReplication -VMName "<VMName>"

If it returns anything, remove it:

Remove-VMReplication -VMName "<VMName>"

In the Recovery Services vault, open Replicated items and make sure the VM isn't listed there in any state.

Step 2: Check the VM's cluster status

Run on the owner node:

Get-VM -Name "<VMName>" | Select-Object Name, VMId, IsClustered

IsClustered should be True.

The VM should appear as a Virtual Machine resource that is Online.

Because you recreated the VM, check that the cluster role points to the current VM (the same VMId) and not the old one.

Step 3: Remove the VM from the cluster and add it back

In Failover Cluster Manager, right-click the VM role and select Remove. This removes the VM from the cluster only. It doesn't delete the VM or its disks.

Add it back: Roles > Configure Role > Virtual Machine, then select the VM.

Or use PowerShell:

Add-ClusterVirtualMachineRole -VMName "<VMName>"

If you use System Center VMM, restart the System Center Virtual Machine Manager service and refresh the VM in VMM.

Step 4: Refresh Site Recovery

Check that every node in the cluster is registered in the vault and shows as Connected, under Site Recovery infrastructure > Hyper-V hosts (or VMM servers).

Make sure all nodes run the same, current version of the Site Recovery Provider and Recovery Services agent.

Restart these services on each node: Microsoft Azure Site Recovery Service, Microsoft Azure Recovery Services Agent, and Hyper-V Virtual Machine Management.

In the vault, select the Hyper-V site or VMM server and click Refresh Server.

Wait about 15 minutes, then try to enable replication again.

Reference: https://learn.microsoft.com/en-us/azure/site-recovery/hyper-v-azure-tutorial

Step 5: If it still fails

Check these event logs on the owner node:

Applications and Services Logs > Microsoft > Azure Site Recovery > Provider > Operational

Applications and Services Logs > MicrosoftAzureRecoveryServices > Replication

Applications and Services Logs > Microsoft > Windows > Hyper-V-VMMS > Admin

Then open an Azure support request for Azure Site Recovery, and include the error details, the job ID from the vault, and these logs.

Reference: https://learn.microsoft.com/en-us/azure/azure-portal/supportability/how-to-create-azure-support-request

Kindly answer the question below:
Do you use System Center VMM, or are the Hyper-V hosts registered directly in the vault?

Are all cluster nodes registered in the vault, connected, and on the same Provider version?

What does Get-VMReplication show for the VM?

Did the VM get a new VMId when they recreated it, and does the cluster role point to the current VM?

What is the full error message for 70153, and what is the job ID?
Kindly let us know if the above helps or you need further assistance on this issue.

Please "upvote" if the information helped you. This will help us and others in the community as well.

1 answer

Your answer

Answer 1

Azure Site Recovery (ASR) is detecting the VM as not highly available, even though it appears as a clustered role in Failover Cluster Manager. Error 70153 typically indicates a mismatch between the VM's cluster state and the metadata ASR uses to validate clustered Hyper‑V workloads

Recommendations:

Verify the VM is listed as a Cluster Role and is owned by the cluster, not running as a standalone Hyper‑V VM.
Confirm all VM files (VHDX, configuration, checkpoints) reside on cluster shared storage (CSV).
Ensure the Azure Site Recovery Provider/Agent is healthy and up to date on all cluster nodes.
Refresh cluster registration by moving the VM role between nodes and revalidating cluster health.

Also check for Stale ASR metadata:

Disable protection (if partially configured).
Remove any stale replicated items from the Recovery Services Vault.
Re-discover and re-enable protection.
Verify the VM has a unique ID and that no remnants of a previous protected instance remain in ASR.

Collect ASR Provider logs and escalate to the Azure Site Recovery support team if the VM is confirmed as a healthy clustered role and protection still fails after metadata cleanup and rediscovery.