Symptômes, diagnostic et correction du lancement
Cette fiche concerne Acomba distribué avec Microsoft App-V, sur un poste Windows ou un serveur de sessions. Elle décrit le cas où Acomba démarre hors de son environnement virtuel. Une association RunVirtual peut alors rétablir le lancement, à condition de confirmer ce diagnostic au préalable.
Symptômes caractéristiques
Acomba affiche « Unable to write to … Acomba.ini » au démarrage. Le chemin indiqué traverse généralement le dossier d’intégration App-V, par exemple :
RACINE_INTEGRATION\PACKAGE_ID\Root\…\Fortune\Acomba.ini
Le problème peut réapparaître après un redémarrage. Un script de réparation qui retire puis réinstalle le paquet peut rétablir temporairement le fonctionnement. Ces symptômes orientent le diagnostic, mais ne suffisent pas à identifier la cause.
Cause recherchée
Le lancement par le raccourci n’active plus le contexte virtuel du paquet. Acomba tente alors d’accéder à sa configuration dans le stockage protégé du paquet, sans bénéficier des redirections prévues par App-V.
Une référence PackageRoot devenue incohérente avec le volume réel peut accompagner cette défaillance. Elle constitue une piste à vérifier, pas une cause à supposer sur chaque machine. La correction RunVirtual sélectionne explicitement le paquet; elle ne répare pas l’origine d’une éventuelle incohérence de volume.
Si Acomba est installé sans App-V, ou si l’erreur persiste dans le contexte virtuel, examiner plutôt les permissions du chemin réel, les attributs du fichier, les verrous, l’espace disque et l’état du profil ou du paquet.
Vérifier le paquet et le raccourci
Dans la session concernée, relever la cible exacte du raccourci, ses arguments et son dossier de démarrage. Utiliser Windows PowerShell avec le module AppvClient disponible. Lister les paquets, puis identifier celui réellement utilisé :
Import-Module AppvClient
Get-AppvClientPackage |
Select-Object Name, PackageId, VersionId,
IsPublishedGlobally, IsPublishedToUser
Conserver le PackageId et le VersionId complets. Vérifier la publication pour l’utilisateur concerné, la disponibilité du contenu et l’état du client App-V. Ne pas choisir automatiquement le premier paquet si plusieurs versions d’Acomba sont présentes.
Confirmer que le lancement est en cause
1. Lancer Acomba par le raccourci habituel et reproduire l’erreur. Pendant que le processus existe, vérifier sa présence dans les processus virtuels :
Get-AppvVirtualProcess -Name 'Acomba' -ErrorAction SilentlyContinue
L’absence de résultat est un indice à recouper avec la session examinée et les droits de consultation. La présence des modules App-V dans le processus peut fournir une vérification complémentaire.
2. Fermer normalement cette instance, puis lancer le même exécutable en imposant le paquet. Remplacer les espaces réservés PACKAGE_ID, VERSION_ID et CHEMIN_A_REMPLACER par les valeurs relevées; conserver les arguments et le dossier de démarrage du raccourci :
$acombaPkg = Get-AppvClientPackage `
-PackageId 'PACKAGE_ID' -VersionId 'VERSION_ID'
Start-AppvVirtualProcess -AppvClientObject $acombaPkg `
-FilePath 'C:\CHEMIN_A_REMPLACER\Acomba.exe'
Si le raccourci utilise des paramètres, les transmettre avec -ArgumentList. Le paramètre -WorkingDirectory permet de conserver le dossier de démarrage. Autre méthode de lancement explicite : /appvve:PACKAGE_ID_VERSION_ID [1].
3. Retenir ce diagnostic si le lancement normal échoue alors que le même lancement dans App-V fonctionne et que le processus est bien reconnu comme virtuel. S’il échoue aussi, poursuivre l’analyse avant d’ajouter une règle RunVirtual.
Contrôle complémentaire du chemin de volume
Si le problème suit un redémarrage ou un changement de stockage, examiner en lecture seule la valeur PackageRoot du paquet sous :
HKLM\SOFTWARE\Microsoft\AppV\MAV\Configuration\Packages
Comparer son chemin natif avec la correspondance actuelle des volumes obtenue par fltmc volumes. Un chemin vers le mauvais volume doit être documenté. Ne jamais recopier le numéro HarddiskVolume d’une autre machine. Modifier cette seule valeur ne garantit pas le rétablissement du lancement automatique.
Choisir la portée du correctif
La ruche de registre doit correspondre au mode de publication du paquet [2]. Pour plusieurs utilisateurs, vérifier aussi que leurs raccourcis ciblent le même exécutable.
| Publication du paquet | Emplacement de la règle |
|---|---|
| Globale sur la machine | HKLM\SOFTWARE\Microsoft\AppV\Client\RunVirtual\Acomba.exe |
| Pour un utilisateur | HKCU\SOFTWARE\Microsoft\AppV\Client\RunVirtual\Acomba.exe, dans le profil de cet utilisateur |
HKLM désigne HKEY_LOCAL_MACHINE; HKCU désigne HKEY_CURRENT_USER. La publication par utilisateur nécessite App-V 5.0 SP3 ou ultérieur pour RunVirtual [2]. Une règle HKCU dans le compte administrateur ne corrige pas les autres comptes. Une règle HKLM ne publie pas à elle seule le paquet.
Appliquer une association RunVirtual ciblée
Après confirmation du diagnostic, fermer Acomba et sauvegarder l’état de la clé RunVirtual concernée. Utiliser des droits administratifs pour une règle HKLM. Dans la clé choisie, créer ou mettre à jour la valeur suivante [3] :
| Champ | Valeur à utiliser dans cet environnement |
|---|---|
| Nom de la valeur | Chemin complet de Acomba.exe relevé dans la cible du raccourci publié |
| Type | REG_SZ |
| Donnée | PACKAGE_ID_VERSION_ID du paquet confirmé pendant le test |
| Valeur par défaut | Ne pas la renseigner pour cette méthode ciblée par chemin |
La valeur nommée par le chemin complet limite la règle à cette copie de l’exécutable. Elle évite d’associer automatiquement une autre installation portant aussi le nom Acomba.exe. Examiner toute règle existante avant de la remplacer. Adapter également le nom de la sous-clé si l’exécutable porte un autre nom.
Valider le résultat
Ouvrir Acomba avec le raccourci normal, sans paramètre de diagnostic ni script de réinstallation. Confirmer la disparition de l’erreur, l’ouverture habituelle de l’application et sa reconnaissance par Get-AppvVirtualProcess.
Tester avec un compte utilisateur représentatif, puis dans les autres configurations de raccourcis concernées. Après fermeture normale des applications, effectuer un redémarrage planifié et refaire le test. Le succès dans une session administrateur ne remplace pas un essai dans une session utilisateur.
Si l’erreur persiste malgré un processus correctement virtualisé, rechercher une autre cause. Le message INI seul ne justifie pas d’élargir les droits du cache App-V, de supprimer les profils ou de réinstaller automatiquement le paquet à chaque démarrage.
Maintenir la correction
Lors d’une mise à jour ou d’un nouveau séquencement, le VersionId et parfois le PackageId changent. Actualiser l’association après la publication du nouveau paquet et vérifier à nouveau le chemin cible. Intégrer cette étape au mécanisme de déploiement évite de conserver une règle pointant vers une ancienne version [3].
Si la correction doit être annulée, restaurer uniquement l’état antérieur de la valeur modifiée, ou supprimer cette valeur si elle a été créée pour le test. Conserver les autres associations RunVirtual. Une modification distincte de PackageRoot nécessite son propre suivi et sa propre sauvegarde.
Références techniques
1 — Microsoft Learn : lancer un processus dans un environnement App-V
2 — Microsoft Learn : RunVirtual et portée de publication des paquets
3 — Gridmetric : RunVirtual avec un chemin précis et gestion des versions