Problema

En entornos híbridos donde Azure Site Recovery (ASR) protege máquinas virtuales VMware on‑premises, es frecuente encontrarse con máquinas que, tras un failover o planned failover, quedan en estados inconsistentes:

  • Protection couldn’t be enabled – la VM aparece como no protegida y la única acción disponible es Disable replication.
  • Healthy / Protected pero con opciones limitadas (solo Planned failover y Disable replication).

Estos síntomas impiden volver a la infraestructura local o iniciar un nuevo failover, obligando al equipo a decidir entre una migración completa a Azure o una restauración manual desde backups. El problema suele aparecer después de cambiar la configuración del ASR appliance, por ejemplo al activar o desactivar la encriptación, o al interrumpir una sesión de failover sin completar el proceso de failback.

Causa

Los estados de protección rotos provienen de desalineaciones entre los metadatos de replicación almacenados en Azure y los agentes que corren en el appliance y en los hosts VMware. Las causas más habituales son:

  1. Cambio de configuración del appliance (encriptación, versión del agente, certificados). Cuando el appliance modifica la forma en que cifra los discos replicados, Azure no puede validar los bloques existentes y marca la protección como fallida.
  2. Interrupción abrupta del failover/failback. Si la operación se cancela o la red se cae, el proceso de reconciliación de snapshots queda incompleto. Azure mantiene la VM en Protected pero bloquea acciones que requieran un estado coherente.
  3. Desincronización de la versión del Mobility Service. El agente instalado en los hosts VMware y el que corre dentro de la VM deben coincidir. Una actualización parcial deja la VM en un limbo donde Azure no reconoce la capacidad de volver a habilitar la replicación.
  4. Problemas de conectividad entre el appliance y el Recovery Services vault. Firewalls, cambios de ruta o certificados expirados pueden impedir que el appliance envíe confirmaciones de estado, provocando que Azure marque la protección como inválida.

En la práctica, el escenario más recurrente es la combinación de cambio de encriptación + cancelación de failover, que deja los discos replicados encriptados de forma diferente a la esperada por Azure.

Solución

La estrategia se basa en restaurar la coherencia entre los componentes y, si es necesario, forzar un nuevo ciclo de replicación. Los pasos pueden ejecutarse sin interrumpir otras VMs protegidas.

1. Verificar la versión del Mobility Service

  1. Conéctate al host VMware y revisa la versión del agente instalado en la VM (C:\Program Files\Microsoft Azure Site Recovery\mobilityservice.exe → –version).
  2. En el portal de Azure, abre la página de la VM protegida y comprueba la versión reportada.
  3. Si difieren, descarga la última versión del Mobility Service desde el vault y reinstálala en la VM (puedes usar la opción Update mobility service del portal o ejecutar el instalador manualmente).

2. Normalizar la configuración de encriptación

  1. Accede al ASR appliance (normalmente vía HTTPS en https://<appliance-ip>).
  2. En Settings → Encryption, verifica que la opción Enable encryption esté desactivada (o activada, según tu política).
  3. Si cambiaste el estado, guarda y permite que el appliance regenere los certificados internos (aprox. 5‑10 min).

Importante: después de cualquier cambio, ejecuta Refresh en el vault para que Azure recargue la configuración del appliance.

3. Forzar un Resync de la VM problemática

  1. En el portal, selecciona la VM con estado Protection couldn’t be enabled.
  2. Elige Disable replication → confirma. Esto elimina los metadatos de replicación sin borrar los discos en Azure.
  3. Vuelve a Enable replication:
    • Selecciona el mismo Recovery Services vault y Recovery point.
    • En la sección de Encryption verifica que coincida con la del appliance.
    • Inicia la replicación y espera a que el primer Initial replication alcance Healthy.

Este proceso crea un nuevo flujo de datos y alinea los bloques encriptados con la política actual.

4. Ejecutar un Planned failover controlado (opcional)

Si la VM ya está en Healthy pero solo permite Planned failover, úsala para validar la ruta de retorno:

# PowerShell (AzureRM) - iniciar planned failover
$rg = "MyResourceGroup"
$vault = "MyRecoveryVault"
$vmName = "sql01"
$replicationProtectedItem = Get-AzRecoveryServicesReplicationProtectedItem -ResourceGroupName $rg -VaultName $vault -Name $vmName
Start-AzRecoveryServicesFailoverJob -ReplicationProtectedItem $replicationProtectedItem -Direction PrimaryToRecovery -FailoverType Planned

Una vez completado, verifica que la VM en Azure esté operativa y que el Failback (Recovery to Primary) aparezca como opción. Si el Failback sigue bloqueado, repite el paso 3.

5. Revisar logs del appliance y del Mobility Service

  • En el appliance, los logs están en /var/log/azure_site_recovery/. Busca entradas con ERROR o ENCRYPTION.
  • Dentro de la VM, revisa C:\Program Files\Microsoft Azure Site Recovery\Logs\.
  • Correlaciona timestamps con la hora del failover para identificar interrupciones.

6. Validar conectividad y certificados

  • Asegúrate de que el appliance pueda resolver *.vault.azure.net y que los puertos 443 y 9443 estén abiertos.
  • Renueva los certificados del appliance si aparecen expirados (/etc/ssl/certs/).

Cuándo aplicar esta solución

Aplica cuando observes alguno de los siguientes síntomas:

  • Estado Protection couldn’t be enabled o Protected sin opciones de Failback.
  • Solo aparecen botones Planned failover y Disable replication.
  • Cambios recientes en la configuración del appliance (encriptación, actualización).
  • Fallos de replicación después de un failover manual.

No aplica si:

  • La VM nunca estuvo replicada (no hay objetos de replicación en el vault).
  • El problema se limita a errores de red temporales que se resuelven con un simple Refresh del portal.

En esos casos, una simple reconexión del appliance o la re‑creación del vault suele ser suficiente.

Código

# PowerShell: forzar deshabilitar y volver a habilitar replicación
$rg = "MyRG"
$vault = "MyASRVault"
$vm = "app01"

# Desactivar replicación
$rpItem = Get-AzRecoveryServicesReplicationProtectedItem -ResourceGroupName $rg -VaultName $vault -Name $vm
Disable-AzRecoveryServicesReplicationProtectedItem -ReplicationProtectedItem $rpItem -Force

# Esperar 2 minutos
Start-Sleep -Seconds 120

# Reactivar replicación (asume que la VM sigue en el mismo host)
Enable-AzRecoveryServicesReplicationProtectedItem -ResourceGroupName $rg -VaultName $vault -Name $vm -RecoveryPointId $rpItem.RecoveryPointId

Verificación

  1. Portal: la VM debe mostrar Protection status: Healthy y ofrecer tanto Failover como Failback.
  2. Azure Monitor: verifica que no haya alertas de tipo Replication health para la VM.
  3. Logs del appliance: busca la última entrada Replication enabled successfully.
  4. Prueba de conectividad: desde Azure, haz ping o RDP a la VM replicada y confirma que responde.
  5. Failback de prueba (opcional): ejecuta un Planned failback a un entorno de pruebas on‑prem y valida que la VM vuelve a estar operativa en VMware.

Notas adicionales

  • Backups externos: aunque Veeam cubra la capa de backup, siempre es buena práctica crear un Recovery Point en Azure antes de forzar un Disable replication.
  • Tiempo de replicación inicial: el primer ciclo después de volver a habilitar puede tardar varias horas según el tamaño de los discos y la velocidad de la red. Planifica una ventana de mantenimiento.
  • Política de encriptado: si tu organización requiere encriptación, habilita la opción en el appliance antes de iniciar la primera replicación. Cambiarla después obliga a recrear la replicación completa.
  • Versiones de Mobility Service: mantén un inventario de versiones instaladas en tus hosts VMware. Un script de PowerShell que consulte Get-ItemProperty en la ruta del agente ayuda a detectar desviaciones.
  • Documentación interna: registra cada cambio de configuración del appliance (fecha, responsable, motivo). Esto acelera la resolución cuando el estado de protección se vuelve inconsistente.