Convertir un EXE en MSIX est simple quand l'installateur se tient bien, et réellement difficile quand ce n'est pas le cas. La plupart des guides traitent du premier cas. Celui-ci couvre tout le chemin, y compris les endroits où cela dérape, car c'est là que le temps part réellement.
L'état final est un package MSIX signé qui s'installe proprement, se désinstalle proprement, et se déploie via Intune.
Avant de commencer : MSIX est-il la bonne cible ?
Cela vaut trente secondes, car cela fait gagner des jours.
MSIX convient aux applications de bureau ordinaires en mode utilisateur. Il ne convient pas à ce qui installe un pilote, enregistre un service système, doit écrire dans des emplacements au niveau machine que d'autres applications lisent, ou s'accroche profondément au système d'exploitation. Si votre EXE fait l'une de ces choses, packagez-le plutôt en MSI ou via le PowerShell App Deployment Toolkit et passez à autre chose. Le forcer dans MSIX produit un package qui existe techniquement et ne fonctionne jamais tout à fait.
Trois questions tranchent la plupart des cas avant même d'ouvrir le moindre outil :
- L'installateur a-t-il besoin de droits d'administration pour autre chose que l'écriture dans Program Files ? Écrire dans Program Files est normal. Installer un service, un pilote ou un point d'accroche à l'échelle du système est le signal d'arrêt.
- Quelque chose d'autre lit-il ce que cette application écrit ? MSIX redirige les écritures dans un conteneur par utilisateur, si bien que si une autre application, une tâche planifiée ou un agent de supervision lit un fichier ou une clé produits par celle-ci, la redirection rend ces données invisibles pour eux. Cela ressemble à un package qui fonctionne, sans en être un.
- L'éditeur livre-t-il déjà un MSIX ? Posez la question avant de capturer. Réempaqueter un installateur qui dispose d'un MSIX pris en charge est un travail que vous pouvez tout simplement ne pas faire.
En cas de doute, menez quand même la conversion mais limitez-la dans le temps. L'échec sera évident.
Six étapes, une boucle : un diagnostic manqué vous renvoie à l'instantané, pas en avant avec un package rafistolé.
Étape 1 : une machine réellement propre
C'est l'étape que l'on saute et que l'on paie ensuite.
La capture fonctionne en comparant la machine avant et après l'installation. Tout ce qui est déjà présent est invisible pour cette comparaison, une machine où les dépendances de l'application sont déjà installées produit donc un package qui fonctionne sur votre machine et nulle part ailleurs.
Utilisez une machine virtuelle neuve, correspondant à la build Windows cible, ne portant rien d'autre que le système d'exploitation. Prenez-en un instantané avant de commencer afin de pouvoir revenir à un état connu, car vous ferez cela plus d'une fois.
Deux détails font la différence entre une capture propre et une capture bruitée :
- Faites d'abord taire la machine. Windows Update, les définitions de sécurité et les mises à jour d'applications du store écrivent tous sur le disque pendant que votre capture s'exécute, et chacune de ces écritures devient une partie du package. Laissez la machine terminer ses mises à jour initiales, mettez-les en pause, puis prenez l'instantané.
- Faites correspondre la build, pas seulement la version. Capturer sur une build Windows plus récente que celle qu'exécute votre parc fige des redistribuables et des versions de framework présents là et absents sur la cible. Capturez sur la build la plus ancienne que vous prenez en charge.
Une tentative de capture sur une machine qui porte déjà une installation ratée ne vaut rien, revenez donc en arrière avant chaque nouvel essai.
Étape 2 : capturez l'installation
Prenez la référence, exécutez l'installateur exactement comme le ferait un utilisateur, puis terminez la capture.
Deux choses méritent d'être faites pendant l'installation :
Lancez l'application une fois avant de terminer la capture. Beaucoup d'applications effectuent une configuration de premier démarrage : création de la configuration, écriture de valeurs de registre par défaut, décompactage de ressources. Si vous capturez avant que cela n'arrive, vous packagez une application qui ne s'est jamais initialisée et elle fera son premier démarrage à l'intérieur du conteneur, où l'écriture peut ne pas persister.
Notez tout ce que l'installateur vous demande. Clés de licence, adresses de serveur, emplacements d'installation. Ces choix sont désormais figés dans le package, et s'ils étaient mauvais, vous repartez pour une reconstruction.
Vous définissez aussi l'identité du package ici, et elle est pénible à changer par la suite. Elle réside dans le manifeste et ressemble à ceci :
<Identity Name="Contoso.LineOfBusinessApp"
Publisher="CN=Contoso Ltd, O=Contoso Ltd, C=GB"
Version="1.0.0.0" />
Publisher est celui qui compte : il doit correspondre au sujet de votre certificat de signature caractère pour caractère, décidez-le donc maintenant plutôt que de découvrir un écart à l'étape quatre. Version est un numéro en quatre parties et le déploiement tient à ce qu'il augmente, adoptez donc une convention et notez-la.
S'il n'y a aucun installateur à exécuter, la capture n'est pas votre chemin. Réempaqueter sans l'installateur d'origine traite ce cas, et la même discipline de machine propre s'applique.
Étape 3 : attendez-vous à des écarts, et diagnostiquez correctement
Le package s'installera. Puis quelque chose clochera.
Ne commencez pas à appliquer des correctifs au hasard. Reproduisez le problème en tant qu'utilisateur standard, découvrez ce que l'application demande réellement, et associez le symptôme à une cause précise. Nous avons traité cette correspondance dans quel correctif PSF me faut-il, et en résumé : vérifiez le répertoire de travail avant de recourir à quoi que ce soit d'autre, car c'est la cause unique la plus fréquente.
Deux habitudes raccourcissent l'exercice. Reproduisez en tant qu'utilisateur standard, car une bonne part des casses MSIX signalées sont des hypothèses de permissions qui étaient depuis toujours dans l'application et que masquait le fait que tout le monde s'exécutait en administrateur local. Regardez ensuite où le conteneur a placé l'écriture : les données par utilisateur atterrissent sous %LOCALAPPDATA%\Packages\<PackageFamilyName>\LocalCache, et trouver le fichier là prouve que l'écriture a réussi et que l'application regarde à l'ancien endroit.
Appliquez une modification à la fois et retestez. Un package qui porte quatre correctifs alors qu'un seul était nécessaire est un package que personne ne maintiendra.
Si le troisième correctif n'a pas réglé l'affaire, reconsidérez la cible. Convertir une application héritée en MSIX traite de la décision plus large, et il n'y a aucune honte à livrer une application récalcitrante par une autre route pendant que le parc avance.
Étape 4 : signez-le
Un MSIX non signé ne s'installera pas sur un poste managé. Ce n'est pas facultatif et c'est là que beaucoup de premières tentatives s'arrêtent.
Il vous faut un certificat de signature de code dont le sujet correspond exactement à l'éditeur du manifeste du package. Pas approximativement. Exactement. Un écart ici produit un échec d'installation dont le message d'erreur ne mentionne pas du tout le certificat, et c'est pourquoi il coûte un après-midi. Comparez les deux directement avant de signer :
Get-ChildItem Cert:\CurrentUser\My -CodeSigningCert |
Select-Object Subject, Thumbprint, NotAfter
Ce qui remonte sous Subject doit figurer dans le Publisher du manifeste, y compris l'ordre des noms distinctifs relatifs et les espaces. Copiez-le plutôt que de le saisir.
Signez depuis le magasin de certificats par empreinte plutôt que de manipuler un fichier PFX, et utilisez un serveur d'horodatage RFC 3161. Sans horodatage, le package cesse d'être validé à l'expiration du certificat, alors même qu'il a été signé légitimement pendant que le certificat était valide.
signtool sign /sha1 <thumbprint> /fd SHA256 /tr <your RFC 3161 timestamp URL> /td SHA256 .\ContosoApp.msix
Un dernier point piège les certificats internes : le certificat doit être approuvé sur le poste qui installe le package. Une autorité publique chaîne déjà vers une racine à laquelle Windows fait confiance ; votre propre autorité interne ou un certificat de test auto-signé, non, il doit donc d'abord atteindre le magasin de confiance du poste. Déployez-le via votre gestion de certificats habituelle plutôt qu'à la main sur un seul poste de test, sinon votre validation réussit sur le seul poste où elle pouvait réussir.
Étape 5 : validez avant de livrer
Validez le package et traitez un code de sortie non nul comme un arrêt. Il coûte bien moins cher de trouver un manifeste malformé maintenant qu'après son arrivée sur un anneau de test.
Confirmez que la signature et l'horodatage sont bien en place, au même titre que le manifeste :
Get-AuthenticodeSignature .\ContosoApp.msix |
Format-List Status, SignerCertificate, TimeStamperCertificate
Status doit indiquer Valid et TimeStamperCertificate ne doit pas être vide. Un champ d'horodatage vide aujourd'hui, c'est un package qui cessera de s'installer à une date future sans raison visible.
Installez-le ensuite pour de vrai sur une machine propre, en tant qu'utilisateur standard, et vérifiez :
- Il se lance.
- Il conserve ses paramètres après un redémarrage.
- Il se désinstalle proprement et ne laisse rien derrière lui.
Add-AppxPackage .\ContosoApp.msix
Get-AppxPackage -Name Contoso.LineOfBusinessApp | Select-Object Name, Version, PackageFullName
Remove-AppxPackage -Package <PackageFullName>
Ce dernier point est tout l'intérêt de MSIX. Si la désinstallation laisse des débris, quelque chose s'écrit en dehors du conteneur et vous n'avez pas terminé.
Ajoutez une quatrième vérification si les utilisateurs gardent l'application ouverte toute la journée : installez-la, lancez-la, puis installez une version incrémentée par-dessus. Les mises à jour sont préparées pendant que l'application tourne et appliquées au démarrage suivant, un utilisateur qui ne la ferme jamais ne reçoit donc jamais la mise à jour. Ce n'est pas un bogue, mais c'est un appel au support si personne ne s'y attendait.
Étape 6 : déployez via Intune
Préparez le MSIX pour Intune et attribuez-le. Dans le centre d'administration Intune, c'est Apps, All apps, Add, puis le type d'application métier, qui accepte directement le fichier .msix. Attribuez-le en requis à un groupe pilote d'abord, puis en disponible au groupe plus large une fois que le pilote a tenu quelques jours.
Bon à savoir : un MSIX déployé de cette façon se met à jour par version, votre schéma de versionnage compte donc désormais. Trompez-vous une fois et les postes refusent la mise à jour parce que la version n'a pas augmenté. Surveillez l'état d'installation par poste plutôt que de faire confiance à l'attribution, et notez qu'un poste qui porte déjà une copie signée par un éditeur différent refusera celle qui est managée, car pour Windows ce sont deux applications différentes.
Où passe réellement le temps
Pas dans la conversion. La conversion prend quelques minutes. Le temps part dans la discipline de machine propre, le diagnostic quand l'application se comporte mal, et la configuration de la signature. Faire une application vous apprend le schéma. En faire quatre cents est un problème différent, et la raison pour laquelle le packaging d'applications reste un métier de spécialiste.
La différence ne tient pas à l'effort par application, elle tient à la cohérence : savoir si chaque package a été capturé sur la même build, signé de la même façon, et si ses décisions de correctifs ont été consignées ailleurs que dans la mémoire d'une seule personne. C'est un problème de workflow plutôt qu'un problème de packaging, et c'est pourquoi les parcs finissent avec un dossier de packages que personne n'ose reconstruire.
La place d'EtherApps Forge
EtherApps Forge est conçu pour le cas des quatre cents : capturer, orienter, préparer les correctifs, signer et valider en un seul flux plutôt qu'avec six outils et un runbook. Les décisions sont consignées avec le package au lieu d'être mémorisées, et c'est ce qui rend la deuxième passe sur un parc moins coûteuse que la première.
C'est une application de bureau Windows plutôt qu'un service hébergé, la capture et la signature restent donc dans votre environnement, et elle s'accompagne d'un essai gratuit de 7 jours. Si vous livrez vos propres builds plutôt que de capturer l'installateur d'un tiers, le chemin part d'un dossier de build à la place : packaging MSIX pour les développeurs et les ISV le couvre, et construire et signer un MSIX en CI/CD sans le Windows SDK montre la forme du pipeline. Pour la vue à l'échelle du parc, packaging et déploiement MSIX va de la capture à la livraison.
Découvrez le packaging et déploiement MSIX pour voir comment capture, remédiation, signature et livraison s'exécutent en un seul flux plutôt qu'en six.