Solución completa al error de instalación de Mobility Service al replicar VMware en Azure Site Recovery

Cuando se pretende proteger cargas de trabajo on‑premises en VMware mediante Azure Site Recovery (ASR), el paso crítico es instalar el Mobility Service dentro de cada máquina virtual origen. Si dicho agente no termina de desplegarse, la replicación nunca se inicia y el Recovery Services Vault mostrará el estado Protection Not Enabled. A continuación se presenta una guía exhaustiva de resolución para el error de instalación que Imran Shabir describió en los foros de Microsoft, junto con prácticas probadas de campo para retomar la replicación con éxito.

Índice

Contexto del problema

En entornos VMware, ASR utiliza un Process Server intermedio que recibe, comprime y reenvía los datos de disco hacia Azure. Durante la habilitación, el portal descarga e intenta instalar automáticamente el agente Mobility Service dentro de la VM seleccionada. Cuando ese paso falla —ya sea por tiempo de espera, código HRESULT genérico o mensaje “Failed to install agent”‑—, el asistente revierte la operación y obliga al administrador a diagnosticar manualmente.

Síntomas típicos de fallo en la instalación

Rollback inmediato durante la copia de archivos.
Mensaje “Unable to communicate with VM via WMI” en Windows o “SSH connection failed” en Linux.
En el Process Server, el archivo PushInstall.txt muestra Exit code 1603 o 0x80070422.
Carpeta C:\Program Data\ASR creada pero sin archivos ejecutables finales.

Requisitos previos indispensables

Elemento	Windows Server	Linux
Sistemas operativos admitidos	2008 SP2, 2008 R2, 2012, 2012 R2, 2016, 2019, 2022	Red Hat 6/7/8/9, CentOS 6/7/8‑Stream, Ubuntu 16.04/18.04/20.04/22.04, SLES 12/15
Espacio libre en la unidad de sistema	≥ 1 GB
Dependencias de software	.NET Framework 4.7.2 o superior	Python 2.7/3.x, openssl, gcc, make, perl
Puertos salientes mínimos	TCP 443 hacia `.servicebus.windows.net`, `.blob.core.windows.net`, `*.hypervrecoverymanager.windowsazure.com`

Validaciones de conectividad

La gran mayoría de fallos se relaciona con rutas bloqueadas o inspección TLS. Desde la VM origen ejecute:

Test-NetConnection -ComputerName "<yourvault>.servicebus.windows.net" -Port 443

En Linux utilice:

openssl s_client -connect <yourvault>.servicebus.windows.net:443 -servername <yourvault>.servicebus.windows.net -quiet

Deberá obtener el certificado raíz de Microsoft y un cierre limpio de la sesión (SSL‑session shutdown). Si la organización navega por un proxy TLS, registre la excepción para los dominios de Azure o configure variables de entorno httpproxy y httpsproxy antes de lanzar el instalador.

Procedimiento de instalación manual paso a paso

Descargue Microsoft-ASR_UA.exe desde el portal y copie el archivo RegistrationFile.xml en la misma carpeta.
Con sesión de Administrador local, abra un Command Prompt elevado y ejecute:
UnifiedSetup.exe /q /x RegistrationFile.xml /Platform VMware
Monitoree el directorio C:\ProgramData\ASR\home\svsystems\log. Durante la fase AgentInstall se crea SetupWizard.log. Busque códigos <0 para errores irreversibles. Un 0x80070643 indica permisos insuficientes; 0x80070002 apunta a rutas de acceso mal definidas.
En Linux, descomprima el paquete mobilityagent.tar.gz y ejecute:
sudo ./install -q -r RegistrationFile.xml -p VMware Los registros se almacenan en /var/log/azure.

Diagnóstico mediante registros

Cada intento genera cuatro archivos principales:

ASRSetup_<timestamp>.log: orquestación de UI.
AppServer.txt: salida de la instalación MSI.
PushInstall.txt: sólo cuando se empuja desde Process Server.
VxUpdate.txt: actualización de componentes tras la instalación inicial.

Abra los archivos con un visor que resalte colores (por ejemplo, cmder) y busque los tags [ERROR]. Si encuentra referencias a VERIFYFAILEDCERTIFICATE_TIME, la causa es un desfase horario.

Depuración de WMI y servicios esenciales (Windows)

WMI es el canal usado por el Process Server para crear el servicio InMageVSSProvider y copiar binarios. Compruebe:

sc query winmgmt
sc query rpcss
sc query plugplay

Todos deben estar en estado RUNNING. Para reparar el repositorio WMI:

winmgmt /salvagerepository
winmgmt /verifyrepository

Después reinicie la VM.

Sincronización de hora y DNS

ASR valida cada bloque de datos con firmas SHA‑256 cuya fecha y hora deben coincidir (deriva < 300 s). En Windows ejecute:

w32tm /query /status
w32tm /resync

Para Linux utilice timedatectl. A nivel DNS, verifique que la zona interna resuelva la IP del Process Server y los endpoints de Azure sin latencias inusuales.

Interferencias comunes de antivirus y EDR

Herramientas con inspección de procesos (CrowdStrike, SentinelOne, McAfee ENS) suelen bloquear la creación del servicio InMage VSS. Deshabilite la protección en tiempo real o agregue exclusiones para:

C:\Program Files\Microsoft Azure Site Recovery
C:\ProgramData\ASR
Hash SHA‑1 del archivo instalador.

Permisos y cuentas de servicio

Utilice un usuario del grupo Administrators local —evite cuentas de dominio con políticas de restricción. Para Linux, conecte como root vía SSH; los usuarios sudoers con requiretty deshabilitado también son válidos. En vCenter, la cuenta registrada en el Configuration Server necesita los privilegios Datastore Browse, Create Snapshot, Read All Storage y Network Assign.

Prueba de replicación y verificación

Una vez instalado el agente:

Desde el cofre de recuperación seleccione Replicar máquinas > VMware vSphere.
Elija la VM, la suscripción y la región de destino.
Revise que el estado del agente muestre Healthy. Si indica Update Available, realice la actualización in‑place para evitar incompatibilidades de versión con el Process Server.
Espere a que la columna Percentage synced llegue a 100 %. Para discos de 1 TB y enlace de 50 Mbps, el cálculo aproximado es de 5‑6 horas sin otras cargas.

Cuándo y cómo escalar a soporte de Microsoft

Si, tras repetir el procedimiento, el instalador continúa fallando:

Comprima la carpeta C:\ProgramData\ASR\home\svsystems\log o /var/log/azure.
Anote la versión de vCenter, la compilación de ESXi y el sistema operativo invitado.
Publique la pregunta en Microsoft Q&A con la etiqueta Azure Site Recovery. Allí los ingenieros de producto disponen de diagnósticos avanzados y pueden generar hotfixes del agente o reglas de firewall específicas.

Resumen y mejores prácticas

Realice las pruebas de puertos y hora antes de lanzar la instalación.
Cree un snapshot de la VM para volver atrás si fuera necesario.
Mantenga el Process Server actualizado; agentes recientes esperan versiones de backend compatibles.
Documente cada cambio en firewall o proxy para futuras auditorías.
Automatice la instalación del Mobility Service con Configuration Manager o Ansible cuando haya más de 10 VMs.

Siguiendo las recomendaciones anteriores, más del 90 % de los errores de instalación del Mobility Service se resuelven sin necesidad de escalado. Una vez completada la replicación inicial, ASR aplicará compresión y seguimiento de bloques para minimizar el ancho de banda, cumpliendo los objetivos de continuidad de negocio con RPO de minutos y RTO de horas.