Comment packager une application PSADT v4 pour Intune

Le PowerShell App Deployment Toolkit et Intune forment un bon duo : PSADT gère les parties pénibles de l'installation d'une application Windows, et Intune se charge de l'acheminer jusqu'aux postes. C'est la chaîne entre les deux qui fait perdre du temps, car les deux n'ont pas le même avis sur l'arborescence des dossiers, les codes de sortie et ce qui compte comme une réussite.

Cet article traite spécifiquement de la v4. Si vous suivez un guide écrit pour la v3, la syntaxe des commandes a changé et vous obtiendrez des erreurs qui ressemblent à des problèmes de packaging sans en être.

En résumé : gardez l'arborescence du toolkit intacte, désignez son point d'entrée comme fichier d'installation quand vous générez le .intunewin, reflétez la commande d'installation dans la commande de désinstallation, choisissez une règle de détection capable de distinguer une version d'une autre, et mappez les codes de sortie de redémarrage et de nouvelle tentative. Le reste de cet article détaille ces cinq points.

Pourquoi s'embêter, alors que MSIX existe

Parce que beaucoup d'applications ne sont pas candidates à MSIX. Tout ce qui installe un pilote ou un service système, tout ce qui exige de véritables écritures au niveau machine, tout ce dont l'installateur tient à rester un installateur. MSIX est la bonne cible quand il convient, et PSADT est la bonne réponse quand ce n'est pas le cas.

PSADT vous apporte aussi des choses que MSIX n'offre pas : des invites utilisateur avant un redémarrage, la fermeture propre des applications en cours d'exécution, des reports, et une journalisation qu'un service d'assistance peut réellement lire.

La décision est généralement rapide si vous vérifiez dans cet ordre :

• Installe-t-elle un pilote en mode noyau, ou un service au niveau machine dont d'autres logiciels dépendent ? Utilisez PSADT.
• Une autre application lit-elle ce qu'elle écrit en dehors de son propre dossier ? La redirection du conteneur masque cette écriture.
• Doit-elle fermer un document ouvert ou proposer un report avant un redémarrage ? C'est le terrain de prédilection de PSADT, sans équivalent MSIX.
• Rien de tout cela, et l'installateur se comporte bien ? Essayez d'abord MSIX. Convertir un EXE en MSIX parcourt ce chemin de bout en bout.

Un dossier source PSADT devient un seul fichier intunewin, et quatre paramètres Intune décident si cela fonctionne.

Étape 1 : bien construire l'arborescence des dossiers

L'outil de packaging d'Intune prend un dossier source et produit un unique fichier .intunewin. Il empaquette tout ce que contient ce dossier, donc l'agencement compte.

Gardez la structure PSADT intacte. Le toolkit attend ses propres dossiers à des emplacements connus et ne trouvera pas ses ressources si vous les aplatissez ou les réorganisez. Placez l'installateur de l'application dans le dossier files du toolkit, ne touchez à rien d'autre, et pointez l'outil de packaging vers le sommet de cette structure.

En v4, l'agencement de travail ressemble à ceci, votre installateur étant la seule chose que vous ajoutez :

ContosoApp\
  Invoke-AppDeployToolkit.ps1
  Invoke-AppDeployToolkit.exe
  PSAppDeployToolkit\
  Config\
  Strings\
  Files\
    ContosoAppSetup.exe
  SupportFiles\

Générez ensuite le package avec le Microsoft Win32 Content Prep Tool :

IntuneWinAppUtil.exe -c C:\Packaging\ContosoApp -s Invoke-AppDeployToolkit.exe -o C:\Packaging\Output

Le fichier d'installation que vous désignez doit être le script de déploiement, pas l'installateur propre à l'application. C'est de loin l'erreur la plus courante. Désigner l'EXE de l'éditeur produit un package qui ignore entièrement votre enveloppe PSADT, ce qui est déroutant car il semble fonctionner.

Deux limites bonnes à connaître. Une application Win32 Intune est plafonnée à 8 Go, et l'outil chiffre le dossier en un unique fichier opaque, donc vous ne pouvez pas corriger une ligne du script de déploiement après coup. Gardez le dossier source sous gestion de versions et traitez le .intunewin comme un artefact de build.

Étape 2 : les commandes d'installation et de désinstallation

En v4, l'invocation a changé. Le script de déploiement et son exécutable d'enveloppe ont été renommés, et les noms de fonctions du toolkit ont changé avec eux, si bien qu'une ligne de commande v3 nomme un fichier qui n'existe plus. En copier une dans une application Intune produit un échec immédiat accompagné d'un message peu utile. Les commandes qu'il vous faut sont celles-ci :

Invoke-AppDeployToolkit.exe -DeploymentType Install -DeployMode Silent
Invoke-AppDeployToolkit.exe -DeploymentType Uninstall -DeployMode Silent

Deux points à bien traiter :

Exécutez en mode silencieux. Les invites interactives n'ont nulle part où s'afficher quand Intune exécute le package en contexte système, et l'installation se bloquera au lieu d'échouer proprement.

Faites correspondre la commande de désinstallation à la commande d'installation. Intune s'en servira, et une désinstallation qui ne fonctionne pas transforme un simple changement d'attribution d'application en visite manuelle sur le poste.

Préférez l'exécutable fourni à un appel de powershell.exe que vous feriez vous-même, car il gère pour vous l'architecture de l'hôte PowerShell. Si vous appelez PowerShell directement, rappelez-vous que l'Intune Management Extension est un processus 32 bits, donc %windir%\System32 est redirigé vers SysWOW64 à votre insu et il vous faut %windir%\Sysnative\WindowsPowerShell\v1.0\powershell.exe pour atteindre l'hôte 64 bits.

Testez les deux commandes localement, en contexte système, avant de packager quoi que ce soit. S'exécuter sous votre propre compte administrateur prouve moins que vous ne le pensez, car votre profil porte des variables d'environnement et une confiance de certificat que le compte SYSTEM n'a pas. Obtenez d'abord un shell en contexte système :

PsExec.exe -s -i cmd.exe

Exécutez la commande d'installation depuis ce shell, puis la désinstallation, et lisez les journaux avant d'approcher Intune. PSADT écrit dans C:\Windows\Logs\Software par défaut, et le côté Intune se trouve dans C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log. Ensemble, ces deux fichiers vous disent généralement en une minute si le problème venait du package ou de l'attribution.

Étape 3 : les règles de détection, là où ça dérape vraiment

Intune décide si l'application est installée à l'aide de la règle de détection, pas en interrogeant le package. Si vous vous trompez, l'une de deux choses se produit : Intune réinstalle l'application à chaque prise de contact, ou Intune croit qu'elle est installée alors qu'elle ne l'est pas.

Choisissez une méthode de détection spécifique à la version que vous déployez :

• Une vérification de version de fichier sur l'exécutable principal de l'application est généralement la plus fiable. Pointez vers le vrai chemin d'installation, choisissez la comparaison de version plutôt que l'existence, et comparez en supérieur ou égal à la version que vous livrez.
• Une vérification de registre sur la clé de désinstallation fonctionne bien quand l'éditeur écrit un DisplayVersion sensé. Pour une application 32 bits sur Windows 64 bits, cette clé se trouve sous WOW6432Node, et Intune dispose d'un commutateur dédié. L'oublier est une cause très courante d'une application qui s'installe parfaitement et se signale comme non installée.
• Un script de détection personnalisé quand l'état est réellement plus complexe qu'un fichier ou une valeur. Intune considère l'application comme détectée uniquement lorsque le script se termine par 0 et écrit quelque chose sur la sortie standard. Un script qui se termine par 0 en silence est signalé comme non détecté.
• Une simple vérification d'existence de fichier est un piège. Elle ne peut pas distinguer la version 1 de la version 2, donc les mises à niveau n'ont silencieusement jamais lieu.

La signature d'erreur à reconnaître est 0x87D00324, l'application n'étant pas détectée après une installation signalée comme réussie. Cela signifie rarement que l'installation a échoué. Cela signifie que la règle de détection cherche au mauvais endroit, dans la mauvaise architecture, ou la mauvaise chose.

Quel que soit votre choix, vérifiez-le sur une machine où l'application est réellement absente, et sur une autre où elle est réellement présente. Les deux cas, à chaque fois.

Étape 4 : les codes de sortie

PSADT renvoie des codes de sortie significatifs et Intune a ses propres idées sur ceux qui signifient une réussite.

Intune est livré avec un mappage par défaut qui couvre déjà l'essentiel de vos besoins : 0 et 1707 sont des réussites, 3010 est un redémarrage léger, 1641 un redémarrage forcé, et 1618 une nouvelle tentative. L'erreur ne vient pas des valeurs par défaut, elle vient du fait de les effacer quand vous ajoutez un code à vous. Ajoutez à la liste, ne la remplacez pas.

Le plus important est le code de redémarrage léger. Si un déploiement nécessite un redémarrage et qu'Intune ignore que ce code signifie une réussite en attente de redémarrage, l'application apparaît en échec et Intune la retente. Configurez les codes de retour pour qu'un résultat en attente de redémarrage soit traité comme une réussite exigeant un redémarrage.

Le second est le code de sortie 1618, une autre installation en cours. Traitez-le comme une nouvelle tentative plutôt qu'un échec : il est transitoire et courant sur les postes fraîchement provisionnés où plusieurs applications arrivent en même temps.

Deux autres à ajouter à la liste. PSADT réserve un bloc de codes dans la plage 60000 pour des résultats au niveau du toolkit, comme un utilisateur qui reporte au-delà de la fenêtre autorisée : ce ne sont pas des échecs applicatifs, et les mapper sur un échec produit un tableau de bord auquel personne ne se fie. Et 1603 est l'erreur fatale générique de Windows Installer, qui ne vous apprend rien en soi, donc lisez le journal PSADT plutôt que le rapport Intune.

Étape 5 : testez toute la chaîne

Sur un poste propre, dans le même contexte que celui qu'Intune utilisera :

1. Installez. Confirmez que cela réussit et que la règle de détection la signale présente.
2. Redémarrez, et confirmez que cela survit.
3. Désinstallez via Intune, et confirmez que la règle de détection la signale absente.
4. Réinstallez, par-dessus, pour vérifier le comportement de mise à niveau.

L'étape quatre est celle que tout le monde saute et celle qui génère des tickets de support six mois plus tard.

Deux ajouts une fois cette boucle validée. Quand vous livrez une version plus récente de quelque chose déjà déployé, utilisez la substitution plutôt qu'une seconde application : deux applications revendiquant le même exécutable se disputent la détection et le poste y perd. Et si l'application est attribuée comme requise pendant la configuration du poste, testez-la derrière l'Enrollment Status Page, où tout ce qui attend poliment bloque la première connexion d'un utilisateur.

Faire cela de façon répétée

Pour une application, c'est une heure. Pour un catalogue, c'est une chaîne de production, et la question intéressante cesse d'être comment packager une application pour devenir quelle route de packaging chaque application doit prendre. Certaines sont candidates à MSIX. Certaines relèvent de PSADT. Certaines devraient être laissées tranquilles.

Cette décision d'orientation est la partie qui ne se règle pas en recrutant. Prise application par application par celui qui est disponible cette semaine-là, elle produit un parc que personne ne sait expliquer. Prise selon des critères cohérents et consignée, elle devient un inventaire sur lequel vous pouvez planifier, ce qui est la base d'un travail de modernisation et migration applicative.

La place d'EtherApps Forge

EtherApps Forge prend cette décision d'orientation explicitement et produit des sorties MSIX, MSI, PSADT et prêtes pour Intune à partir de la même capture, si bien que le choix est consigné plutôt que rediscuté application par application. C'est une application de bureau Windows avec un essai gratuit de 7 jours, pas un service hébergé, donc les captures et le packaging restent dans votre propre environnement.

Les parties fastidieuses plutôt que difficiles de cet article sont celles qui méritent d'être automatisées : la même arborescence à chaque fois, des commandes d'installation et de désinstallation qui correspondent, et une trace de la raison pour laquelle une application a fini en PSADT plutôt qu'en MSIX. Lorsqu'une application se convertit proprement puis se comporte mal à l'intérieur du conteneur, quel correctif PSF me faut-il couvre le diagnostic, et moderniser les applications Windows héritées couvre l'évaluation qui le précède.

Si vous packagez vos propres builds plutôt que ceux de quelqu'un d'autre, la route développeurs et ISV est la bonne, et générer des MSIX en CI sans le Windows SDK couvre le volet pipeline.

Découvrez la modernisation et migration applicative

Packager une application correctement est une compétence ; packager quatre cents applications de façon cohérente est un registre de décisions, et c'est cette partie qui mérite d'être construite.