Intune : diagnostiquer les échecs d’installation AppX, UWP et MSIX

Résumé

Le diagnostic AppX/MSIX comporte quatre plans : la publication et l’affectation dans Intune, la remise du contenu, la validation du package par Windows et l’enregistrement pour le bon utilisateur ou dans l’image du poste. Un succès dans un plan ne valide pas les suivants.

Les preuves les plus utiles sont le nom de famille du package, l’architecture, l’identité du signataire, les dépendances déclarées dans le manifeste et les événements AppXDeployment-Server et AppxPackaging. Je corrèle ces éléments à l’heure exacte de la tentative.

Je ne réenregistre pas toutes les applications Windows et je ne supprime pas globalement les caches AppX. Ces actions ont un impact large et détruisent souvent l’état nécessaire à l’analyse.

Le diagnostic AppX/MSIX comporte quatre plans : la publication et l’affectation dans Intune, la remise du contenu, la validation du package par Windows et l’enregistrement pour le bon utilisateur ou dans l’image du poste. Un succès dans un plan ne valide pas les suivants.

Contexte, objectif et périmètre

Les termes AppX, UWP et MSIX sont souvent mélangés. UWP décrit un modèle applicatif, tandis qu’AppX/MSIX désignent des formats et une infrastructure de package. Intune peut distribuer un package métier, une application Microsoft Store ou une application Win32 dont l’installeur manipule lui-même des packages.

Le même code HRESULT peut apparaître lors d’un test interactif et d’un déploiement géré, mais le contexte diffère. Une installation par utilisateur, un provisioning pour les futurs profils et une installation sous SYSTEM n’utilisent ni les mêmes droits ni exactement le même état utilisateur.

Je traite « Troubleshooting AppX, UWP et MSIX » comme une chaîne de preuves et non comme une succession de boutons à cliquer. Une action n’est considérée comme réussie que lorsque le résultat est visible au niveau attendu : configuration du service, état reçu par le poste, traitement local, puis remontée cohérente dans les outils d’administration. Cette séparation évite de confondre une affectation valide avec une exécution terminée.

Je conserve systématiquement les heures en UTC et en heure locale, l’identité de l’appareil, le contexte utilisateur ou système, la version de Windows et la version des composants concernés. Sans ces repères, deux événements semblables peuvent appartenir à des cycles différents. Les exemples de journaux sont anonymisés et les identifiants techniques doivent l’être avant tout partage.

Ma méthode part du symptôme observable, formule plusieurs hypothèses concurrentes, puis cherche la preuve capable d’en éliminer une. Je ne commence pas par vider un cache, supprimer une clé ou réinstaller un agent : ces actions modifient précisément l’état qui permettrait de comprendre l’incident. La collecte initiale reste donc en lecture seule.

Une correction n’est proposée qu’après localisation de la phase en échec. Je distingue toujours le contournement temporaire, la correction causale et la correction structurelle. Le retour arrière est préparé avant la modification, puis le résultat est contrôlé sur un pilote représentatif avant toute généralisation.

• Objectif : localiser précisément la phase en échec
• Objectif : interpréter les événements et HRESULT sans généralisation
• Objectif : corriger le package ou son ciblage avec un rollback vérifiable
• Périmètre : Windows 10/11 encore supporté par le scénario
• Périmètre : packages .appx, .appxbundle, .msix et .msixbundle
• Périmètre : applications LOB et packages remis par un wrapper Win32

Architecture et fonctionnement général

Intune décide si l’application est applicable et remet son contenu au poste. Selon le type d’application, l’IME peut participer à l’orchestration, mais l’installation du package reste finalement évaluée par l’infrastructure AppX de Windows.

Le manifeste fournit l’identité, la version, l’éditeur, les architectures, les dépendances et les capacités. Windows compare ces informations au certificat et à l’état existant. Une version plus ancienne, une architecture incompatible ou une dépendance absente bloque avant l’enregistrement.

L’étape finale dépend de la portée. Add-AppxPackage agit dans un profil utilisateur ; Add-AppxProvisionedPackage ajoute un package à l’image pour les futurs profils. Confondre ces deux résultats produit souvent un faux succès de validation.

Prérequis techniques et préparation

Avant toute mise en œuvre, je fige le périmètre de test et je capture l’état initial. Cette photographie comprend les versions, les affectations, les autorités de gestion, les dépendances et les exceptions connues. Elle sert autant à interpréter le résultat qu’à construire le retour arrière.

Je vérifie les prérequis sur un appareil réellement représentatif. Une console qui autorise la création d’un profil ne prouve ni l’éligibilité du poste, ni la disponibilité effective de la fonctionnalité dans le tenant. Les prérequis réseau, licence, identité et système doivent tous être confirmés.

• package signé et chaîne de confiance disponible
• Publisher du manifeste cohérent avec le certificat
• bundle contenant l’architecture visée
• dépendances et frameworks accessibles
• espace disque suffisant
• heure de tentative et utilisateur concernés connus
• poste pilote représentatif

Procédure de mise en œuvre

La procédure suivante est volontairement découpée en points de contrôle. Je ne poursuis pas lorsqu’un résultat attendu manque : continuer masquerait la première divergence et produirait des symptômes secondaires plus difficiles à interpréter.

Les noms de groupes, profils, applications et fichiers sont des exemples. Je les remplace par les conventions de l’organisation, je documente la population ciblée et je conserve une preuve avant/après pour chaque changement.

Signature, identité et confiance

La signature garantit l’intégrité et rattache le package à un éditeur. Le Publisher du manifeste doit correspondre au sujet du certificat utilisé. Je vérifie la chaîne, la date de validité et la présence de la racine dans le contexte machine lorsque le déploiement est système.

Un package resigné sans aligner le manifeste échoue même si le fichier semble correctement signé. Je vérifie aussi qu’aucune appliance réseau ou opération de copie n’a altéré le contenu après signature.

Pour un renouvellement de certificat, je teste la mise à niveau depuis la version déjà installée. Le scénario doit préserver l’identité attendue ou documenter explicitement la migration vers une nouvelle famille de package.

Dépendances, architectures et versions

Un package x64 n’est pas automatiquement compatible ARM64. Un bundle peut contenir plusieurs architectures, mais je vérifie son contenu réel et les frameworks déclarés. Les dépendances doivent être présentes dans une version compatible avec les contraintes du manifeste.

Les conflits de version comprennent le downgrade, une version déjà installée sous une autre identité ou un package en cours d’utilisation. Je relève les versions installées pour tous les utilisateurs lorsque le symptôme varie selon la session.

Je traite les packages inbox avec prudence. Réenregistrer ou supprimer une application système peut affecter le menu Démarrer, le Store ou des composants Windows sans corriger le package métier initial.

Provisioning machine et enregistrement utilisateur

Un package provisionné est disponible pour les nouveaux profils, mais il n’est pas automatiquement enregistré rétroactivement pour chaque utilisateur existant. À l’inverse, Get-AppxPackage sans -AllUsers ne décrit que la session courante.

Je compare l’état provisionné via Get-AppxProvisionedPackage -Online, l’état enregistré par utilisateur et l’utilisateur ciblé dans Intune. Cette triangulation explique de nombreux cas où le portail et un test administratif semblent se contredire.

Pendant Autopilot ou ESP, je distingue l’installation nécessaire au device de l’enregistrement qui ne peut terminer qu’à l’ouverture de session. Le critère de blocage doit correspondre au résultat techniquement disponible à cette phase.

Scripts, commandes et exemples de lecture

Les commandes présentées servent à observer ou illustrer le fonctionnement. Les scripts de diagnostic restent de niveau 1, avec arrêt sur erreur et gestion globale de l’exception. Ils ne modifient pas le poste. Une remédiation serait au minimum de niveau 2, avec mode de simulation, journalisation adaptée au test et comportement de rollback explicitement validé.

Je lis toujours la sortie avec le contexte d’exécution. Une commande lancée dans la session de l’utilisateur ne voit pas nécessairement les mêmes certificats, chemins, variables, applications ou ruches de registre qu’un processus exécuté par l’Intune Management Extension sous SYSTEM.

# Exemple pédagogique non testé — niveau 1
$ErrorActionPreference = 'Stop'
try {
    $pattern = '<NomOuFamilleDuPackage>'
    Get-AppxPackage -AllUsers | Where-Object { $_.Name -like "*$pattern*" -or $_.PackageFamilyName -like "*$pattern*" } |
        Select-Object Name, PackageFullName, PackageFamilyName, Publisher, Architecture, Version, Status
    Get-AppxProvisionedPackage -Online | Where-Object { $_.DisplayName -like "*$pattern*" } |
        Select-Object DisplayName, PackageName, Version, Architecture
    Get-WinEvent -LogName 'Microsoft-Windows-AppxDeploymentServer/Operational' -MaxEvents 150 |
        Where-Object { $_.Message -like "*$pattern*" } | Select-Object TimeCreated, Id, LevelDisplayName, Message
}
catch { Write-Error "Collecte AppX impossible : $($_.Exception.Message)"; exit 1 }

Validation et critères de contrôle

Je valide d’abord le résultat technique sur le poste, puis sa remontée dans le service. Le portail peut conserver un état ancien pendant un certain temps ; inversement, un état vert dans la console ne dispense pas de contrôler l’artefact local réellement attendu.

Le critère GO exige un résultat reproductible, une absence de régression sur les fonctions voisines, une documentation à jour et un retour arrière démontré. Le critère NO-GO s’applique dès qu’une dépendance n’est pas maîtrisée, qu’une partie du parc réagit différemment ou que l’état final ne peut pas être prouvé.

• identité et version attendues
• signature approuvée
• dépendances résolues
• enregistrement dans le bon contexte
• lancement fonctionnel
• état Intune remonté
• mise à niveau et désinstallation testées

Journaux, diagnostic et constitution des preuves

Je commence par Microsoft-Windows-AppxDeploymentServer/Operational, puis Microsoft-Windows-AppxPackaging/Operational lorsque l’intégrité ou la signature est en cause. Get-AppxLog permet de suivre l’ActivityId fourni par le moteur.

Pour App Installer, j’ajoute le dossier %LocalAppData%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir. Pour un wrapper Win32, je corrèle AppWorkload.log et AppActionProcessor.log au début de la séquence AppX.

• PackageFamilyName et PackageFullName
• Publisher et certificat
• version et architecture
• dépendances du manifeste
• ActivityId AppX
• AppxDeploymentServer/Operational
• AppxPackaging/Operational
• état provisionné et état par utilisateur

10:22:41 Intune assignment evaluated = applicable
10:22:48 Package downloaded = Fabrikam.Tools_4.2.0_x64.msix
10:22:49 AppX ActivityId = {REDACTED}
10:22:49 Dependency = Microsoft.VCLibs.140.00 Status = Missing
10:22:50 Deployment Result = 0x80073CF3
Conclusion = DELIVERY_OK_DEPENDENCY_FAILED

Dépannage : symptômes, preuves et corrections

Je pars de la colonne Symptôme, mais je ne choisis jamais une correction sur ce seul indice. La colonne Preuve indique l’élément qui doit confirmer la cause. Si cette preuve manque, l’hypothèse reste ouverte et l’action proposée ne doit pas être appliquée comme une recette automatique.

Après correction, je reproduis le scénario initial et je compare les mêmes points de mesure. Un changement de symptôme n’est pas toujours une résolution : il peut simplement indiquer que le traitement progresse jusqu’à une nouvelle phase. La chronologie complète reste donc la référence.

Retour arrière et points de vigilance

Le retour arrière ne consiste pas seulement à retirer une affectation. Je restaure l’autorité précédente, la configuration ou la version attendue, puis je vérifie que le poste a effectivement reçu et appliqué ce nouvel état. Les caches et délais de remontée sont documentés au lieu d’être interprétés comme une absence de rollback.

Je conserve les preuves du pilote, le motif de la décision et les écarts rencontrés. Si le service cloud ou une interface évolue, je réévalue les étapes avant une nouvelle vague. Aucun succès obtenu uniquement sur le poste de développement ne constitue une validation de production.

• Rollback : retirer uniquement la nouvelle affectation pilote
• Rollback : restaurer la version signée précédente
• Rollback : désinstaller le package pilote par son identité exacte
• Vigilance : ne pas réenregistrer toutes les applications Windows
• Vigilance : ne pas exposer de certificat privé
• Vigilance : ne pas confondre provisioning et enregistrement utilisateur
• Vigilance : revalider les codes sur l’événement complet