ACOMBA

Acomba ne peut pas écrire dans son fichier INI sous App-V

Erreur « Unable to write to … Acomba.ini » sous Microsoft App-V : confirmer le contexte virtuel, vérifier le paquet et appliquer une association RunVirtual ciblée si le diagnostic est confirmé.

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 paquetEmplacement de la règle
Globale sur la machineHKLM\SOFTWARE\Microsoft\AppV\Client\RunVirtual\Acomba.exe
Pour un utilisateurHKCU\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] :

ChampValeur à utiliser dans cet environnement
Nom de la valeurChemin complet de Acomba.exe relevé dans la cible du raccourci publié
TypeREG_SZ
DonnéePACKAGE_ID_VERSION_ID du paquet confirmé pendant le test
Valeur par défautNe 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