App-V vers MSIX : les quatre choses qui cassent à chaque fois

Convertir des packages App-V en MSIX est surtout mécanique, jusqu'à ce que ça ne le soit plus. Quatre éléments expliquent l'écrasante majorité des signalements du type « la conversion s'est bien passée et maintenant ça se comporte bizarrement », et ce sont les quatre mêmes à chaque fois.

Ils méritent d'être connus avant de commencer, car chacun est peu coûteux à traiter délibérément et coûteux à découvrir dans un anneau de test.

La raison de fond est la même dans les quatre cas : App-V virtualisait des choses qu'App-V contrôlait, et MSIX les encapsule différemment. Tout ce que l'application comptait sur App-V pour faire à sa place a besoin d'une nouvelle réponse. Rien de tout cela n'est un défaut de MSIX. Les deux formats tracent la frontière entre package et environnement à des endroits différents, et une conversion ne transporte pas ce qui tombe en dehors.

Ouvrez le package avant de le convertir

Un package App-V 5 n'est pas opaque. Le fichier .appv est un conteneur OPC, en pratique un fichier zip avec un manifeste à l'intérieur, donc tout ce dont vous avez besoin est lisible avant qu'un outil de conversion n'y touche.

Trois fichiers portent le comportement :

• AppxManifest.xml, à l'intérieur du .appv, contient les valeurs par défaut produites lors du séquencement de l'application.
• <PackageName>_DeploymentConfig.xml porte les paramètres au niveau machine et les scripts en contexte machine.
• <PackageName>_UserConfig.xml porte les paramètres par utilisateur et les scripts en contexte utilisateur.

La priorité va d'UserConfig sur DeploymentConfig sur le manifeste, si bien qu'un paramètre peut apparaître dans les trois avec trois valeurs différentes et un seul est actif. Ne lisez que le manifeste et vous manquerez les personnalisations ajoutées plus tard pour faire fonctionner l'application, celles qui sont justement les plus susceptibles d'être porteuses.

Les extraire prend quelques secondes :

Copy-Item .\LineOfBusinessApp.appv .\LineOfBusinessApp.zip
Expand-Archive .\LineOfBusinessApp.zip -DestinationPath .\LineOfBusinessApp
Select-Xml -Path .\LineOfBusinessApp\AppxManifest.xml -XPath '//*[local-name()="EnvironmentVariables" or local-name()="Shortcut" or local-name()="FileTypeAssociation"]' | ForEach-Object { $_.Node.OuterXml }

Lisez d'abord les trois sources de configuration, puis orientez chaque trouvaille vers l'endroit où elle appartient désormais.

1. Les variables d'environnement

App-V vous permettait de définir des variables d'environnement dans le package, et l'application les voyait à l'intérieur de son environnement virtuel. Elles résident dans un sous-système <EnvironmentVariables>, et l'un ou l'autre fichier de configuration peut en ajouter ou les supprimer à nouveau :

<EnvironmentVariables Enabled="true">
  <Include>
    <Variable Name="LOBAPP_DATA" Value="%UserProfile%\LineOfBusinessApp" />
  </Include>
</EnvironmentVariables>

MSIX gère cela différemment, et les variables que vous aviez déclarées dans App-V n'arrivent pas automatiquement. Une application qui lit une variable pour trouver un chemin de données, un nom de serveur ou un emplacement de licence démarre puis se comporte comme si elle n'avait jamais été configurée. Elle fonctionne, elle ne sait simplement rien.

Que faire : énumérez les variables déclarées par le package avant de convertir. C'est l'étape que les gens sautent, car les variables ne sont pas visibles dans la configuration propre à l'application. Décidez ensuite pour chacune si elle devient une variable de niveau machine ou utilisateur posée par votre outillage de déploiement, une valeur dans un fichier de configuration que l'application lit, ou quelque chose qu'un script de lancement définit avant le démarrage de l'exécutable.

La signature d'échec est une application qui se lance proprement puis se plaint d'un serveur ou d'un chemin manquant. Surveillez la variante plus discrète, où elle bascule sur une valeur par défaut intégrée au lieu de renvoyer une erreur, car celle-là fait surface des semaines plus tard avec les données au mauvais endroit.

2. Les raccourcis

Les packages App-V portaient leurs définitions de raccourcis en entier. L'élément <Shortcut> nomme le .lnk à créer, sa <Target>, son <Icon>, ses <Arguments>, son <WorkingDirectory> et sa <Description>, si bien qu'un package séquencé reproduisait ce que l'installateur avait mis dans le menu Démarrer.

MSIX génère son entrée à partir du manifeste du package à la place, et le résultat n'est pas toujours celui qu'App-V produisait. Les plaintes habituelles : le raccourci atterrit ailleurs, l'icône est erronée ou absente, ou les arguments de ligne de commande ont disparu.

Ce dernier point est le dangereux. Si le raccourci App-V passait un argument qui plaçait l'application dans un mode particulier et que l'entrée MSIX ne le fait pas, les utilisateurs obtiennent une application qui s'ouvre dans le mauvais état plutôt qu'une application qui échoue visiblement. Les parcs qui publient deux fois la même application, en « Finance » et en « Lecture seule », la différence tenant entièrement dans un commutateur, sont plus courants que vous ne le souhaiteriez.

Que faire : capturez la définition complète du raccourci, arguments et répertoire de travail compris, et reproduisez-la délibérément. Lorsqu'un argument distingue réellement deux façons d'exécuter l'application, cela devient généralement deux entrées d'application dans le manifeste plutôt qu'une.

Vérifiez le répertoire de travail en particulier. Si rien ne le définit, Windows utilise le répertoire System32 comme répertoire de travail d'une application packagée, ce qui explique pourquoi « elle ne trouve pas ses propres fichiers » est un premier symptôme si courant. Le Package Support Framework le définit explicitement avec une valeur workingDirectory dans config.json, et c'est le correctif le plus fréquemment appliqué après une conversion. Quel correctif PSF me faut-il cartographie le reste.

3. Les scripts

C'est la plus grande différence à elle seule et celle qui fait dérailler les migrations.

App-V prenait en charge des scripts à huit points du cycle de vie, ce qui explique la quantité de logique qu'un parc accumule sans que personne ne la suive :

Les parcs qui exploitent App-V depuis des années ont souvent de la vraie logique dans ces scripts : mapper un lecteur, récupérer une configuration, nettoyer un emplacement temporaire, enregistrer quelque chose. Plusieurs scripts peuvent se rattacher à un même déclencheur via ScriptRunner.exe, si bien qu'une seule entrée AddPackage peut exécuter quatre choses à la suite avec leurs propres délais d'expiration et leur propre comportement de retour arrière.

MSIX n'offre pas les mêmes points d'accroche de scripts de cycle de vie. L'équivalent le plus proche est le Package Support Framework, qui exécute un script PowerShell avant un exécutable packagé et un autre après sa sortie, définis par exécutable comme startScript et endScript dans config.json.

Cela couvre StartProcess et ExitProcess. Cela ne couvre pas les six autres. Tout ce qui s'exécutait à l'ajout, à la publication, à la dépublication ou au retrait passe dans votre outillage de déploiement, car c'est désormais la seule chose qui sache quand un package arrive ou part.

Que faire : trouvez les scripts avant de convertir, et lisez-les. Certains deviennent un comportement d'installation ou de désinstallation dans Intune ou Configuration Manager. Certains deviennent un script de démarrage dans le package. Certains deviennent de la logique dans la configuration propre à l'application. Certains s'avèrent faire doublon avec ce que la plateforme moderne fait nativement, et peuvent être supprimés avec soulagement.

Deux notes pratiques si vous prenez cette route. L'exécution des scripts nécessite que la stratégie d'exécution PowerShell soit réglée sur RemoteSigned pour l'hôte 64 bits comme pour l'hôte 32 bits. Et StartingScriptWrapper.ps1 doit se trouver dans le package à côté de l'exécutable, sinon rien ne s'exécute et rien ne l'explique.

La signature d'échec est ici la pire des quatre, car l'application fonctionne parfaitement pour la personne qui la teste, dont le lecteur était déjà mappé.

4. Les associations de types de fichiers

App-V enregistrait les associations dans son environnement virtuel avec un certain détail : l'extension, son ProgId, les noms conviviaux, et des commandes shell avec leurs propres lignes de commande, si bien qu'un verbe « Modifier » du clic droit pouvait lancer l'exécutable avec un commutateur différent de « Ouvrir ».

MSIX les déclare dans le manifeste sous forme d'extension, et la déclaration doit être juste :

<uap:Extension Category="windows.fileTypeAssociation">
  <uap:FileTypeAssociation Name="lobdoc">
    <uap:SupportedFileTypes>
      <uap:FileType>.lob</uap:FileType>
    </uap:SupportedFileTypes>
  </uap:FileTypeAssociation>
</uap:Extension>

Quatre choses tournent mal, à peu près dans cet ordre de fréquence.

L'association n'est pas déclarée du tout, donc double-cliquer sur un fichier ne fait rien d'utile.

Elle est déclarée mais Windows ne l'honore pas, car une autre application possède déjà cette extension et le choix de l'utilisateur prime. C'est la pénible : ça marche sur la machine de packaging et pas sur le poste d'un vrai utilisateur.

Le Name est incorrect. Il doit être en minuscules, et il devrait rester stable d'une mise à jour à l'autre, car c'est l'identifiant sous lequel Windows regroupe les types de fichiers.

L'extension est réservée. Windows conserve un ensemble d'extensions et de schémas d'URI pour les applications intégrées et le système d'exploitation, et un enregistrement portant sur l'un d'eux est ignoré plutôt que refusé, donc on dirait que la déclaration n'a simplement pas pris.

Les verbes personnalisés sont la partie que l'on oublie. Les commandes shell au-delà d'une simple ouverture ne survivent pas au voyage et doivent être reconstruites exprès.

Que faire : listez les extensions enregistrées par le package, avec leurs valeurs ProgId et toute commande shell, déclarez-les dans le manifeste, et testez sur un poste qui possède les applications d'un vrai utilisateur. Pas une machine virtuelle propre, qui par définition n'a aucune revendication concurrente.

À regarder pendant que vous y êtes. Les mêmes fichiers portent les protocoles d'URL, les AppPaths, les enregistrements de clients logiciels et les paramètres COM. Ils cassent moins souvent, mais si l'application est normalement lancée depuis un lien à l'intérieur d'un autre système, un gestionnaire lobapp:// qui a discrètement cessé d'exister est un ticket déroutant à recevoir.

L'ordre qui fait gagner du temps

Faites toute la découverte avant de convertir quoi que ce soit :

1. Extrayez les variables d'environnement déclarées par le package, depuis les trois sources.
2. Extrayez les définitions de raccourcis, arguments et répertoire de travail compris.
3. Extrayez et lisez les scripts, en notant à quel déclencheur chacun se rattache.
4. Listez les associations de types de fichiers, leurs valeurs ProgId et leurs commandes shell.
5. Notez les sous-systèmes restants : protocoles d'URL, AppPaths, clients logiciels, COM.

Consignez la décision à côté de chaque trouvaille, pas seulement la trouvaille. « Définit LOBAPP_DATA » est une note. « Définit LOBAPP_DATA, devient une variable utilisateur dans le déploiement Intune » est un plan, et la différence est de savoir si le prochain packager devra le redécouvrir.

C'est une heure par application au maximum, et cela transforme la conversion d'un exercice de découverte en un exercice de mise en œuvre. Sautez-la et vous trouverez chacun de ces points individuellement, dans un anneau de test, avec un utilisateur qui signale le symptôme plutôt que la cause.

Voici ce que cette heure vous achète. Une application financière se convertit proprement, puis deux choses apparaissent lors du pilote : elle ne trouve pas ses modèles, parce que le package définissait une variable pointant vers un partage et que plus rien ne la définit, et la moitié du groupe l'ouvre dans le mauvais mode, parce que le raccourci App-V passait un commutateur de lecture seule. Les deux se trouvaient dans le fichier _DeploymentConfig.xml avant que quiconque ne convertisse quoi que ce soit.

Convertissez ensuite, et testez en tant qu'utilisateur standard sur un poste qui ressemble à un vrai.

Où cela s'inscrit

Le chemin de migration plus large, y compris quels packages doivent devenir des MSIX, se trouve dans migration App-V vers MSIX. À lire en parallèle : App-V Server prend fin, App-V non, car le calendrier est moins urgent que ne le laissait entendre la plupart des articles et précipiter ces conversions est la façon dont les quatre problèmes ci-dessus atteignent la production.

Si l'application se comporte mal d'une façon que ces quatre points n'expliquent pas, conversion des applications héritées vers MSIX couvre les comportements de conteneur qui affectent les applications n'étant jamais passées par App-V.

La place d'EtherApps Forge

EtherApps Forge capture les applications depuis des environnements plus anciens et prépare la remédiation dans le cadre du packaging plutôt qu'en projet distinct ensuite, si bien que le correctif de répertoire de travail, la redirection de fichiers et le script de lancement sont décidés pendant la construction du package plutôt qu'après l'échec d'un pilote.

EtherApps Forge est une application de bureau Windows avec un essai gratuit de 7 jours, pas un service hébergé, donc la capture et la sortie restent toutes deux dans votre environnement. La route applications héritées couvre la découverte et la remédiation, packaging et déploiement MSIX couvre la signature, la validation et la livraison, et modernisation et migration applicative couvre la décision de savoir quelles applications empruntent cette route.

Découvrez la modernisation des applications héritées

Répondez aux quatre questions avant de convertir, et la conversion cesse de produire des surprises.