VMware → Azure Site Recovery : résoudre l’échec d’installation du Mobility Service (diagnostic pas à pas)

Vous tentez de répliquer une VM VMware vers Azure Site Recovery et l’installation du Mobility Service échoue, en automatique comme en manuel ? Voici un guide pas à pas, concret et exploitable, pour diagnostiquer et corriger rapidement la situation.

Sommaire

Vue d’ensemble du problème

Contexte : un administrateur souhaite protéger une machine virtuelle VMware avec Azure Site Recovery (ASR). L’installation automatique du Mobility Service échoue mais une installation manuelle sur la VM source échoue également. Les premières vérifications (WMI, etc.) n’ont pas permis de résoudre le blocage.

Dans l’échange d’origine, l’administrateur a été redirigé vers le forum Microsoft Q&A afin de solliciter des ingénieurs spécialisés ASR, sans diagnostic détaillé publié. L’objectif de cet article est de combler ce manque avec une méthode reproductible de bout en bout.

Comment fonctionne la protection VMware → Azure Site Recovery

Dans un scénario VMware, ASR s’appuie sur un Configuration Server (qui peut accueillir le rôle Process Server) pour orchestrer la réplication vers Azure. Pour chaque VM protégée :

La VM source doit exécuter le Mobility Service (agent invité) chargé de capturer les changements disque et de les envoyer au Process Server.
Les communications passent typiquement en 443 sortant vers Azure et en 9443 entrant vers le serveur de configuration/process.
L’agent s’enregistre auprès du serveur d’orchestration (IDRS) et expose des services locaux (ex. InMageVSSProvider) et une base embarquée (processus H2).

Lorsque l’installation de l’agent échoue, la chaîne de réplication ne peut pas démarrer.

Checklist de diagnostic rapide

Étape	Point de contrôle / action corrective
Prérequis réseau	Vérifier l’ouverture de 443/TCP sortant et 9443/TCP entrant vers le serveur de configuration depuis l’hôte VMware et la VM source.
Version du Mobility Service	Télécharger depuis le Portail Azure > Serveur de configuration > Installer l’agent Mobility la version strictement correspondante à votre déploiement ASR.
Comptes et droits	Utiliser un compte Administrateur local sur la VM source. En environnement domaine, vérifier la délégation des privilèges (accès administratifs, UAC).
Services Windows	S’assurer que les services WMI, Windows Installer et Windows Management Instrumentation sont démarrés et en Automatique.
Journalisation	Examiner : `%ProgramData%\ASR\Home\svsystems.log` (après tentative d’installation) `C:\Windows\Temp\SetupLogs\ASRMobilitySetup` (erreurs détaillées : code 1603, accès refusé, dépendances manquantes)
Synchronisation temporelle	Un décalage NTP > 5 minutes entre la VM et le serveur de configuration bloque l’enregistrement. Contrôler la source de temps de l’hyperviseur et de la VM.
Compatibilité OS	Confirmer via la documentation Prérequis Mobility Service que l’OS invité est pris en charge (certaines versions nécessitent des correctifs).
.NET / Visual C++	Des composants .NET ou Redistribuables C++ corrompus peuvent provoquer un échec silencieux. Réparer/réinstaller si besoin.
Mode silencieux	Essayer l’installation manuelle silencieuse : `MobilityServiceInstaller.exe /q /i /x <server-config-IP> /v (VM-UUID)` Puis vérifier le service InMageVSSProvider et le processus H2.
Support Microsoft	Si les logs pointent une défaillance interne (ex. enregistrement IDRS), ouvrir un ticket ou publier sur Microsoft Q&A avec le tag azure-site-recovery.

Arbre de décision : identifier la cause en <15 minutes

Lancement : l’installation échoue-t-elle immédiatement (erreur MSI) ou après quelques minutes (enregistrement/communication) ?
Si immédiat => regarder MSI/Journal Windows (codes 1603/0x80070643).
Si différé => suspecter réseau/temps/proxy/inspections SSL.
Version : confirmer que le binaire correspond au build ASR déployé. Tout décalage de version est bloquant.
Accès : exécuter l’installeur dans une console Élevée, avec un Administrateur local.
Réseau : tester 9443 vers le serveur de configuration et 443 sortant vers Azure depuis la VM.
Horloge : contrôler que l’écart de temps <= 5 minutes.
Services : WMI et Windows Installer opérationnels.
Rejouer : retenter en mode silencieux et collecter les logs si nouvel échec.

Procédure détaillée de dépannage

Vérifier réseau, DNS, proxy et inspection TLS

Ports : depuis la VM source, valider l’accès au serveur de configuration sur 9443/TCP et les sorties Internet nécessaires sur 443/TCP.
DNS : la résolution du serveur de configuration doit être cohérente (pas d’alias qui bascule d’IP).
Proxy : si un proxy système/WinHTTP est configuré, vérifier la prise en charge et les exceptions. Les proxys avec inspection SSL peuvent rompre la négociation TLS de l’agent.
Filtrage/EDR : certains EDR bloquent les installateurs MSI ou la création de services. Prévoir des exclusions temporaires ciblées (répertoire de l’installeur et processus d’installation) le temps du test.

Commandes utiles (Windows)

Test-NetConnection -ComputerName <ConfigServerIP> -Port 9443
Test-NetConnection -ComputerName <nom_ou_FQDN_cible> -Port 443
netsh winhttp show proxy
ipconfig /all

Confirmer la version exacte du Mobility Service

Le Mobility Service doit être installé avec la version fournie par votre serveur de configuration (Portail Azure > Serveur de configuration > Installer l’agent Mobility). Évitez les installeurs « génériques » plus anciens/nouveaux : un écart de build produit typiquement un échec d’enregistrement.

Vérifier les privilèges et l’exécution en console élevée

Ouvrir Invite de commandes ou PowerShell en Administrateur.
Si UAC est actif et que l’utilisateur est Administrateur de domaine mais pas Administrateur local, ajouter explicitement le compte au groupe Administrateurs de la machine.
Pour les push installs depuis le serveur de configuration, valider l’accès ADMIN$, WMI/RPC et l’authentification sur la cible.

Contrôler WMI et Windows Installer (MSI)

Les erreurs d’installation « Setup ended prematurely » ou 1603 sont souvent liées à MSI/WMI.

Vérifier WMI : winmgmt /verifyrepository sc query winmgmt services.msc (Windows Management Instrumentation = Automatique)
Vérifier MSI : sc query msiserver eventvwr.msc (Journaux Windows > Application > MsiInstaller)
Réparer l’image système (si suspicion de corruption) : DISM /Online /Cleanup-Image /RestoreHealth sfc /scannow

Synchronisation temporelle et identité de la machine

Temps : valider la source NTP (service de temps Windows, VMware Tools, appliance NTP). Écart maximal recommandé : 5 minutes.
UUID : le processus d’enregistrement utilise l’UUID machine. Vérifier et fournir la valeur correcte lors d’une installation silencieuse.

Obtenir l’UUID

OS	Commande
Windows (WMIC)	`wmic csproduct get UUID`
Windows (PowerShell)	`Get-CimInstance Win32_ComputerSystemProduct \| Select-Object -ExpandProperty UUID`
Linux	`sudo dmidecode -s system-uuid`

Installation manuelle silencieuse (Windows)

Depuis une console Administrateur, exécuter :

MobilityServiceInstaller.exe /q /i /x <server-config-IP> /v (VM-UUID)

Paramètres clés :

/q : silencieux
/i : installation
/x <server-config-IP> : adresse du serveur de configuration/Process
/v (VM-UUID) : UUID de la VM

Après exécution, contrôler :

Présence et état du service InMageVSSProvider (services.msc)
Processus H2 actif dans le Gestionnaire des tâches
Création des journaux dans %ProgramData%\ASR\Home

Analyse structurée des journaux

En cas d’échec persistant, se concentrer sur :

%ProgramData%\ASR\Home\svsystems.log : messages d’initialisation, erreurs d’enregistrement, certificats, IDRS.
C:\Windows\Temp\SetupLogs\ASRMobilitySetup : traces du programme d’installation (séquence MSI, codes retour, composants manquants).
Observateur d’événements > Application : événements MsiInstaller (codes 1603, 0x80070643), .NET Runtime si exception managée.

Interprétation rapide des codes fréquents

Code/Message	Cause probable	Action
1603 (Fatal error during installation)	Conflit MSI, droits insuffisants, verrouillage de fichier, chemin non accessible	Exécuter en Admin, purger `%TEMP%`, arrêter AV/EDR temporairement, relancer
0x80070643	Composant .NET/VC++ corrompu, mise à jour en attente	Redémarrer, réparer .NET, réinstaller Redistribuables C++
Accès refusé	UAC, token Admin limité, EDR	Lancer console élevée, confirmer appartenance aux Administrateurs, ajuster exclusions
Échec d’enregistrement IDRS	Réseau/temps/certificat, proxy/inspection SSL	Tester 9443, vérifier NTP, bypass proxy/SSL pour l’agent durant l’installation

Pré-requis logiciels : .NET et Visual C++

Le Mobility Service s’appuie sur des prérequis Windows. Symptômes typiques : l’installeur démarre, puis s’arrête sans message, ou les services ne se créent pas.

Vérifier les fonctionnalités .NET installées : Activer/Désactiver des fonctionnalités Windows.
Réparer .NET : DISM + SFC (cf. plus haut).
Réinstaller/mettre à jour les Redistribuables Visual C++ (x64/x86) requis par votre build ASR.

Compatibilité OS et composants VMware

Confirmer que la version de l’OS invité est supportée par la version ASR déployée.
Vérifier la présence/état de VMware Tools (pilotes de snapshot, date/heure).
Disque et RAM : s’assurer qu’il reste de l’espace libre suffisant sur C:\ et que la mémoire n’est pas sous forte pression lors de l’installation.

Cas Linux : points d’attention

Utiliser le paquet Mobility Service correspondant à la distribution/version.
Vérifier la présence de bibliothèques de base (glibc) et des en-têtes du noyau si demandés.
Ports/réseau identiques (443 sortant, 9443 vers le serveur de configuration).
Exécuter l’installeur en root et vérifier les journaux sous /var/log/ (recherche « asr », « mobility », « svagents »).

Vérifications de santé post-installation

Après une installation réussie, valider :

Le service InMageVSSProvider est en En cours d’exécution.
Le processus H2 apparaît dans la liste des processus.
La VM figure Protégée et la réplication démarre (initial seeding, puis delta).

Scénarios d’échec typiques et résolutions

Échec immédiat avec code 1603

Symptômes : l’assistant s’arrête vite, événements MsiInstaller 1603.

Actions :

Nettoyer %TEMP%, fermer applications concurrentes.
Désactiver temporairement les protections qui interceptent MSI.
Vérifier les permissions du répertoire d’installation (pas de redirection ou chemin UNC non disponible).
Lancer l’installeur en mode silencieux pour obtenir des logs plus verbeux.

Installation réussie mais enregistrement impossible

Symptômes : services crées, mais l’agent ne s’enregistre pas auprès du serveur de configuration.

Actions :

Tester 9443/TCP du client vers le serveur de configuration.
Comparer l’horloge VM/Serveur de configuration (<= 5 min d’écart).
Bypass proxy/inspection SSL jusqu’à la fin de l’enregistrement.
Examiner svsystems.log pour les erreurs de certificat/handshake.

Échec en push install depuis le serveur de configuration

Symptômes : déploiement initié depuis l’interface ASR, mais la copie/installation échoue.

Actions :

Vérifier l’accès ADMIN$ et la résolution du nom NetBIOS/FQDN.
Valider WMI/RPC et pare-feu Windows (règles de gestion à distance).
Tester une installation manuelle locale pour isoler le problème d’authentification réseau.

Exclusions Antivirus/EDR recommandées (approche prudente)

Pour éliminer un faux positif durant l’installation, envisager des exclusions temporaires sur :

Le binaire de l’installeur du Mobility Service.
Le répertoire d’extraction/l’empreinte du service une fois installé (%ProgramData%\ASR\).

Important : limiter la fenêtre d’exclusion au strict nécessaire, puis réactiver immédiatement les protections.

Script de vérification express (Windows)

Exécutez ces commandes pour capturer l’état avant réinstallation :

:: Ports
Test-NetConnection -ComputerName <ConfigServerIP> -Port 9443
Test-NetConnection -ComputerName <azure_endpoint> -Port 443

:: Temps
w32tm /query /status

:: Services clés
sc query winmgmt
sc query msiserver

:: UUID
Get-CimInstance Win32_ComputerSystemProduct ^| Select-Object -ExpandProperty UUID

:: Proxy WinHTTP
netsh winhttp show proxy

Procédure de remise à plat et réinstallation

Désinstaller toute trace du Mobility Service depuis Applications et fonctionnalités.
Redémarrer la VM.
Nettoyer les répertoires temporaires %TEMP% et les journaux résiduels.
Réparer l’image système (DISM/SFC) si des erreurs MSI/WMI ont été vues.
Installer la version exacte du Mobility Service fournie par votre serveur de configuration.
Confirmer les services et la connectivité (9443/443) puis lancer la protection dans le portail.

Bonnes pratiques pour éviter les rechutes

Standardiser un paquet d’installation validé (même build que le serveur de configuration).
Documenter les proxys, exceptions et flux réseau nécessaires.
Surveiller NTP côté hyperviseur et OS invités (écart <= 5 min).
Automatiser un test Test-NetConnection régulier vers le serveur de configuration.
Tenir à jour .NET et Redistribuables Visual C++ via votre solution de patching.

Quand et comment escalader au support

Si, après ces étapes, l’installation échoue toujours :

Compresser et joindre : %ProgramData%\ASR\Home\svsystems.log et le dossier C:\Windows\Temp\SetupLogs\ASRMobilitySetup.
Ajouter un export d’événements Windows (Application : MsiInstaller, .NET Runtime).
Préciser la version du Mobility Service, de l’OS invité et la topologie réseau (proxy/inspection).
Ouvrir un ticket de support Microsoft ou poster sur Microsoft Q&A avec le tag azure-site-recovery.

Exemples de messages à inclure dans votre ticket

Contexte : VMware -> ASR, installation Mobility Service échouée (auto & manuel)
OS invité : Windows Server <version>
Version Mobility : <build> (téléchargée depuis le serveur de configuration)
Horodatage : <UTC>
Proxy/Inspection SSL : Oui / Non (détails)
Erreurs MSI : 1603 / 0x80070643 (captures)
svsystems.log : extraits significatifs
Test-NetConnection : résultats 443/9443
NTP : écart mesuré <valeur> minutes

Résumé opérable

Problème : l’agent Mobility ne s’installe pas, bloquant la protection ASR.
Causes récurrentes : version non correspondante, MSI/WMI corrompus, restrictions proxy/inspection TLS, droits insuffisants, horloge désalignée.
Solution : appliquer la checklist (réseau/temps/droits/versions), installer en mode silencieux, analyser svsystems.log et les logs MSI. Escalader avec pièces jointes si persistance.

Annexe : matrice de risques et impacts

Risque	Impact sur la réplication	Détection	Mitigation
Version d’agent décalée	Échec d’enregistrement, réplication jamais amorcée	Logs d’installation, absence de service H2	Télécharger l’agent depuis le serveur de configuration
Proxy/Inspection SSL	Handshake TLS échoue, timeouts	svsystems.log, tests 443/9443	Bypass/exception durant enregistrement
Horloge désalignée	Rejet d’authentification/certificat	Comparaison NTP	Corriger source de temps (hyperviseur/VM)
MSI/WMI corrompus	Code 1603 / 0x80070643	Journaux Windows Application	DISM/SFC, réparer MSI/WMI
EDR/AV bloque l’installeur	Création de service échouée	Événements sécurité, absence de service InMageVSSProvider	Exclusions temporaires contrôlées

Foire aux questions

ASR supporte-t-il un mode « sans agent » pour VMware ?
Non. Le scénario VMware requiert le Mobility Service dans l’OS invité pour capturer le flux des changements.

Puis-je installer une version plus récente de l’agent ?
Évitez tout décalage de version. Utilisez l’installeur exposé par votre serveur de configuration.

Les snapshots VMware peuvent-ils gêner ?
Des snapshots ou quiescences problématiques peuvent impacter la performance. Assurez-vous que VMware Tools est sain et que l’environnement n’accumule pas de snapshots orphelins.

Dois-je désactiver l’antivirus ?
Uniquement de manière temporaire et contrôlée, le temps d’identifier un faux positif. Privilégiez des exclusions ciblées.

Conclusion

En appliquant méthodiquement les contrôles réseau (443/9443), la vérification de l’heure, la correspondance stricte des versions et les tests en mode silencieux, la majorité des échecs d’installation du Mobility Service se résolvent rapidement. En cas d’impasse, collectez les journaux cités et escaladez avec un dossier complet : vous gagnerez un temps précieux et obtiendrez une résolution priorisée.