Tu vas tomber, en cherchant « MSIX App Attach », sur des dizaines de tutos qui te font croire que c’est trois clics dans un assistant. Tu lances MSIX Packaging Tool, tu cliques Next cinq fois, et hop, ton .msix est prêt.
Sauf que c’est faux. Enfin, à moitié.
L’assistant existe vraiment, et il fait bien le boulot. Le souci, c’est tout ce qu’il y a autour : le certificat de signature qui doit correspondre au pixel près au nom de l’éditeur, le 0x8bad0001 que crache msixmgr quand la chaîne de confiance n’est pas en place, le runtime Windows App SDK qui manque au moment de tester le package, et la source Microsoft Store de winget qui te claque un 0x8a15005e à la figure sur une VM Azure. Aucun de ces pièges n’est documenté côté à côté en français.
Je viens de me les manger tous, dans l’ordre, sur une VM de packaging Azure. Alors je te déroule le process complet : créer un package MSIX de A à Z avec Notepad++ comme cobaye, jusqu’au CIM prêt à attacher. Avec les pièges annoncés avant qu’ils ne tombent.
Une précision tout de suite : cet article s’arrête au package. L’attachement réel sur un host pool AVD (le storage Azure Files, les permissions SMB, la registration App Attach) mérite son propre guide, je le traiterai séparément. Ici, on fabrique l’artefact. C’est déjà bien assez pour un article.
Pourquoi Notepad++ et pas 7-Zip ou un truc plus lourd
Petit aparté de méthode, parce que le choix de l’app cobaye n’est pas anodin.
App Attach a une raison d’être précise : livrer une application sans la coller dans le golden image. Typiquement une app volumineuse, licenciée par département, ou mise à jour souvent. Sur le papier, n’importe quelle app fait l’affaire pour un lab. En pratique, certaines sont de mauvais cobayes.
7-Zip, par exemple, c’est tentant parce que c’est léger. Mais c’est un mauvais exemple pédagogique : gratuit, 5 Mo, utile à tout le monde. Personne ne mettrait jamais ça en App Attach dans la vraie vie, tu l’installes direct dans l’image en trente secondes.
Notepad++ est un bien meilleur choix, pour trois raisons :
- Il se capture proprement. Installeur MSI simple, pas de services Windows, pas de drivers exotiques.
- Il représente le cas réel « outil bureautique livré par groupe d’utilisateurs ».
- Depuis la v8.8.8, Notepad++ fournit un MSI x64 officiel pour le déploiement entreprise. Et un MSI se capture toujours plus proprement qu’un
.exeà assistant graphique.
Au moment où j’écris, la version stable est la 8.9.6.4. C’est celle qu’on va packager.
Le matériel : ce qu’il te faut avant de commencer
On part d’une VM de packaging propre. Le mot « propre » est important : pas de Notepad++ déjà installé dessus, idéalement un snapshot pris avant de commencer pour pouvoir revenir en arrière. MSIX Packaging Tool capture les changements du système pendant l’installation. Si l’app est déjà là, la capture est faussée.
Voici les prérequis, et où je me suis fait avoir sur chacun :
| Élément | Détail | Le piège |
|---|---|---|
| VM de packaging | Windows 10/11, hors domaine acceptée | Doit être propre, snapshot avant |
| MSIX Packaging Tool | via winget | La source msstore plante sur VM Azure |
| msixmgr.exe | https://aka.ms/msixmgr | Refuse de dépaqueter si le cert n’est pas trusté |
| Certificat de signature | auto-signé OK en lab | Le subject doit matcher le Publisher au caractère près |
| Windows App Runtime | dépendance du package | Manque au test local, à installer à part |
On y va dans l’ordre.
I. Installer MSIX Packaging Tool (et le piège msstore)
L’outil s’installe via winget. Première commande, premier mur :
[CODE : install_msixtool.ps1]
powershell
winget install Microsoft.MSIXPackagingToolEt là, sur ma VM Azure, je me prends ça :
Failed when searching source: msstore
0x8a15005e : The server certificate did not match any of the expected values.Le souci, c’est que winget interroge deux sources : winget et msstore. Sur une VM Azure, l’accès au Microsoft Store est souvent restreint ou cassé côté certificat, et c’est msstore qui fait planter la commande. Or le package est dispo sur la source winget, qui elle fonctionne.
La parade, c’est de forcer la source :
[CODE : install_msixtool_fix.ps1]
powershell
winget install Microsoft.MSIXPackagingTool --source wingetEt là ça passe, propre.
Note le message en fin d’install : l’outil te prévient que le MSIX Packaging Tool Driver doit être activé séparément dans les fonctionnalités Windows. Bonne nouvelle, l’outil sait l’activer tout seul à son premier lancement. Mauvaise nouvelle, il peut s’y reprendre à deux fois. On verra ça à l’étape III, pas la peine de s’en occuper maintenant.
II. Le certificat de signature : là où tout le monde se plante
Un package MSIX doit être signé. En production tu utilises ta PKI interne ou un certificat public. En lab, un certificat auto-signé suffit, à condition de respecter une règle d’or que je te donne tout de suite, parce que c’est elle qui m’a coûté le plus de temps.
Le subject du certificat doit correspondre exactement au Publisher name du package. Au caractère près. Si ton cert dit CN=Tazmen Lab, O=Tazmen, C=World, ton Publisher dans MSIX Packaging Tool doit dire exactement la même chose. La moindre virgule de travers, et la signature échoue.
On génère le certificat en PowerShell, en admin :
[CODE : new_cert.ps1]
powershell
# Crée le dossier de travail
New-Item -ItemType Directory -Path "C:\Tools" -Force
# Génère le certificat auto-signé
$cert = New-SelfSignedCertificate `
-Type CodeSigningCert `
-Subject "CN=Tazmen Lab, O=Tazmen, C=World" `
-KeyUsage DigitalSignature `
-FriendlyName "MSIX Lab Signing" `
-CertStoreLocation "Cert:\CurrentUser\My" `
-TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.3", "2.5.29.19={text}")
# Exporte le .pfx (pour signer) et le .cer (pour la confiance)
$pwd = ConvertTo-SecureString -String "TonMotDePasse123!" -Force -AsPlainText
Export-PfxCertificate -Cert $cert -FilePath "C:\Tools\MSIXLabCert.pfx" -Password $pwd
Export-Certificate -Cert $cert -FilePath "C:\Tools\MSIXLabCert.cer"Le .pfx contient la clé privée, il sert à signer. Le .cer ne contient que la partie publique, il sert à faire confiance au package sur les machines cibles.
Je te préviens sur deux pièges vécus :
Piège 1 : la variable $cert meurt avec la session. Si tu fermes PowerShell entre la création du cert et l’export, $cert est vide et l’export plante avec Cannot bind argument to parameter 'Cert' because it is null. Garde la même fenêtre PowerShell ouverte du début à la fin, ou regénère le cert dans la nouvelle session.
Piège 2 : le dossier de destination doit exister. Si C:\Tools n’existe pas, l’export te sort un Le chemin d'accès spécifié est introuvable. (0x80070003). D’où le New-Item en première ligne. Ça paraît évident écrit comme ça, mais sur le moment on cherche midi à quatorze heures.
III. La capture MSIX, écran par écran
Lance MSIX Packaging Tool depuis le menu Démarrer. Choisis Create package, puis Create your package on this computer.
Prepare computer
L’outil vérifie l’environnement. C’est ici qu’il installe le MSIX Packaging Tool Driver si besoin. Le « Checking… » peut traîner une minute ou deux, laisse-le faire.
Deux lignes à regarder sur cet écran. Windows Update is active : l’outil va le désactiver temporairement pendant la capture, c’est normal et voulu. Pending reboot : si ta VM a un redémarrage en attente, l’outil peut le réclamer. Le cas échéant, redémarre et relance.
Select installer
Trois champs à remplir :
- Installer : pointe vers ton MSI Notepad++. Tu le télécharges d’abord avec
Invoke-WebRequestdepuis la release GitHub officielle. - Installer arguments : mets
/quiet /norestartpour une install silencieuse. - Signing preference : choisis Sign with a certificate (.pfx) et sélectionne ton
MSIXLabCert.pfxavec son mot de passe.
[CODE : download_npp.ps1]
powershell
$url = "https://github.com/notepad-plus-plus/notepad-plus-plus/releases/download/v8.9.6.4/npp.8.9.6.4.Installer.x64.msi"
Invoke-WebRequest -Uri $url -OutFile "C:\Temp\npp8964.msi"
Package information
C’est l’écran sensible. Souviens-toi de la règle d’or : le Publisher name doit matcher le subject du certificat.
Quelques remarques sur les champs :
- Package name : pas de caractères spéciaux.
Notepad++(x64)est refusé (les+et les parenthèses ne passent pas). MetsNotepadPlusPlus. - Package display name : là tu peux mettre
Notepad++ (x64), c’est juste l’affichage. - Publisher name : exactement le subject du cert. L’outil affiche d’ailleurs « Subject of the certificate provided » à côté, pour te rappeler la contrainte.
- Version : attention, l’outil pré-remplit souvent une version tronquée du genre
8.9.6.0. La vraie version Notepad++ est8.9.6.4. Corrige le dernier champ. Petit aveu : je ne l’ai pas fait sur le coup, mon package est sorti en8.9.6.0. Ce n’est pas bloquant pour un lab, mais en prod tu veux que la version du package colle à la version réelle de l’app.
Accelerator
Cet écran sert aux templates de conversion pré-configurés. Tu n’en as pas besoin pour Notepad++. Next, sans rien renseigner.
Installation
L’installeur MSI tourne en arrière-plan, en mode capture. Tu ne verras pas forcément l’assistant graphique de Notepad++, c’est normal, le /quiet fait son office. L’écran te propose un Restart machine : ne clique pas dessus, Notepad++ n’a pas besoin de redémarrage. Next.
First launch tasks
L’outil a détecté notepad++.exe automatiquement, avec le bon chemin et l’icône. Clique sur Run pour lancer Notepad++. C’est l’étape de validation : l’app doit s’ouvrir normalement. Vérifie qu’elle démarre, puis ferme-la.
Une popup « Are you done? » apparaît. Tu as lancé l’app, c’est tout ce qu’il fallait capturer. Clique Yes, move on.
Package report
No services were detected : parfait pour Notepad++. Aucun service Windows à embarquer, le package reste propre. C’est exactement pour ça que Notepad++ est un bon cobaye. Next.
Create package
Dernière ligne droite. Change le Save location pour quelque chose de propre, par exemple C:\Temp\, plutôt que le Desktop par défaut. Puis Create.
Et voilà :
Package successfully created
C:\Temp\NotepadPlusPlus_8.9.6.0_x64__74sz6hfr72mwy.msixLe .msix signé est sur le disque. Première moitié du boulot faite.
IV. Du MSIX au CIM avec msixmgr (et le fameux 0x8bad0001)
Pour App Attach, le .msix ne suffit pas. Il faut le « dépaqueter » dans une image disque que les session hosts monteront dynamiquement. Deux formats existent : VHDX et CIM. Microsoft recommande CIM : montage plus rapide, moins de CPU et de RAM consommés, surtout sur Windows 11. On part là-dessus.
L’outil pour ça, c’est msixmgr, qu’on télécharge sur le lien court Microsoft :
[CODE : get_msixmgr.ps1]
powershell
Invoke-WebRequest -Uri "https://aka.ms/msixmgr" -OutFile "C:\Tools\msixmgr.zip"
Expand-Archive "C:\Tools\msixmgr.zip" -DestinationPath "C:\Tools\msixmgr" -ForcePuis on génère le CIM. Le dossier de destination doit exister, et il faut un sous-dossier dédié parce qu’un CIM est composé de plusieurs fichiers, pas d’un seul :
[CODE : create_cim.ps1]
powershell
New-Item -ItemType Directory -Path "C:\Temp\CIM\NotepadPlusPlus" -Force
C:\Tools\msixmgr\x64\msixmgr.exe `
-Unpack `
-packagePath "C:\Temp\NotepadPlusPlus_8.9.6.0_x64__74sz6hfr72mwy.msix" `
-destination "C:\Temp\CIM\NotepadPlusPlus\notepadplusplus.cim" `
-applyACLs `
-create `
-fileType CIM `
-rootDirectory AppsEt c’est là que j’ai buté un bon moment. Premier essai :
Successfully created the CIM file: ...notepadplusplus.cim
[WARNING] ... failed to get unpacked. Please try again:
Failed with HRESULT 0x8bad0001 when trying to unpack ...Le truc vicieux, c’est que le CIM est créé mais vide. Le message « Successfully created » te fait croire que c’est bon, alors que le contenu du package n’a pas été extrait. Si tu ne lis pas le warning juste en dessous, tu pars avec une coquille vide.
Le 0x8bad0001 veut dire que msixmgr ne fait pas confiance au certificat qui a signé le package. Logique : c’est un cert auto-signé, Windows ne le connaît pas. Il faut l’installer dans les bons magasins de certificats de la machine locale.
Première tentative, le magasin Trusted People :
[CODE : trust_cert_people.ps1]
powershell
Import-Certificate `
-FilePath "C:\Tools\MSIXLabCert.cer" `
-CertStoreLocation "Cert:\LocalMachine\TrustedPeople"J’ai relancé msixmgr. Toujours 0x8bad0001. Le hic, c’est qu’un certificat auto-signé est sa propre autorité racine : pour que la chaîne de confiance soit complète, il doit aussi être dans le magasin Trusted Root Certification Authorities.
[CODE : trust_cert_root.ps1]
powershell
Import-Certificate `
-FilePath "C:\Tools\MSIXLabCert.cer" `
-CertStoreLocation "Cert:\LocalMachine\Root"Windows t’affiche un avertissement de sécurité à l’import dans Root, confirme avec Oui. C’est normal, tu déclares faire confiance à une autorité que tu viens de créer toi-même.
Pour mettre toutes les chances de ton côté, active aussi le mode développeur qui lève les restrictions de signature MSIX en local :
[CODE : enable_devmode.ps1]
powershell
$regPath = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock"
if (-not (Test-Path $regPath)) { New-Item -Path $regPath -Force | Out-Null }
Set-ItemProperty -Path $regPath -Name "AllowDevelopmentWithoutDevLicense" -Value 1
Set-ItemProperty -Path $regPath -Name "AllowAllTrustedApps" -Value 1Je nettoie le CIM raté, je le regénère, et cette fois :
[Warning] The app ... depends on the following packages to run correctly:
Microsoft.WindowsAppRuntime.1.4
Successfully created the CIM file: C:\Temp\CIM\NotepadPlusPlus\notepadplusplus.cimPlus de 0x8bad0001. Le CIM est rempli pour de bon. Le nouveau warning sur Microsoft.WindowsAppRuntime.1.4 est juste informatif, on va le traiter à l’étape suivante.
En clair, pour qu’un CIM se génère vraiment : le cert doit être dans TrustedPeople ET Root sur la machine de packaging. Les deux. Note-le bien.
V. Tester le package en local (sans host pool)
Pas besoin d’un host pool AVD pour valider que ton package fonctionne. Tu peux l’installer directement sur la VM de packaging avec Add-AppxPackage. C’est même recommandé avant de partir sur le déploiement.
[CODE : install_local.ps1]
powershell
Add-AppxPackage -Path "C:\Temp\NotepadPlusPlus_8.9.6.0_x64__74sz6hfr72mwy.msix"Et là, dernier piège de la série :
Add-AppxPackage : Deployment failed with HRESULT: 0x80073CF3
... this package depends on a framework that could not be found.
Provide the framework "Microsoft.WindowsAppRuntime.1.4" ...C’est exactement le warning qu’on avait eu en générant le CIM. Notepad++ packagé en MSIX a besoin du Windows App Runtime 1.4, qui n’est pas présent sur la VM. Il faut l’installer à part.
Le réflexe Invoke-WebRequest sur aka.ms m’a donné un fichier corrompu (« The file or directory is corrupted and unreadable »), et le lien GitHub direct s’est fait couper par le réseau de la VM. Ce qui a marché du premier coup, c’est encore winget :
[CODE : install_runtime.ps1]
powershell
winget install Microsoft.WindowsAppRuntime.1.4 --source winget
60,6 Mo téléchargés, installé. Je relance l’install du package, et cette fois Notepad++ apparaît dans le menu Démarrer et se lance comme une app native.
Pour le désinstaller après ton test :
[CODE : uninstall_local.ps1]
powershell
Get-AppxPackage -Name "NotepadPlusPlus" | Remove-AppxPackageÀ retenir pour la suite : sur tes session hosts AVD, ce runtime devra aussi être présent, soit dans le golden image, soit poussé par Intune ou GPO avant l’attachement. Une dépendance manquante côté host, et ton app refusera de démarrer même parfaitement packagée.
Ce que je retiens
Le packaging MSIX en lui-même n’est pas compliqué. L’assistant fait le job. Ce qui coince, c’est la chaîne de confiance et les dépendances, et aucun de ces points n’est mis en avant dans les tutos « trois clics ».
Si tu ne devais retenir que quatre choses :
- Force
--source wingetsur les VMs Azure, la source msstore est cassée. - Le Publisher name = le subject du cert, au caractère près, sinon la signature saute.
- Le cert auto-signé va dans TrustedPeople ET Root, sinon
msixmgrsort un0x8bad0001et te génère un CIM vide en te faisant croire que tout va bien. - Le Windows App Runtime est une dépendance à installer séparément, sur la VM de test comme sur les session hosts.
À ce stade tu as un .msix signé, testé et validé, et un CIM prêt à être attaché. C’est tout ce dont tu as besoin pour la suite.
Et la suite, justement, c’est l’attachement réel : monter le CIM sur un Azure Files, gérer les permissions SMB quand tes session hosts sont hors domaine AD classique, et faire la registration App Attach côté host pool. Ça, ça mérite son propre guide, parce que c’est un autre niveau de pièges. Je le détaillerai dans un article séparé.
A bientôt Louis 🐇 🤜 🤛 🐰