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

Résumé opérationnel

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.

Symptôme, contexte et périmètre de l’incident

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.

• Windows 10/11 encore supporté par le scénario
• packages.appx,.appxbundle,.msix et.msixbundle
• applications LOB et packages remis par un wrapper Win32

Questions à résoudre et méthode de diagnostic

Pour Troubleshooting AppX, UWP et MSIX, l’enquête suit le parcours Intune → Delivery → AppX engine → Registration. L’étape utile n’est pas celle qui affiche le dernier message: c’est la première dont le résultat ne correspond plus au fonctionnement attendu.

Les premiers contrôles portent sur PackageFamilyName et PackageFullName, Publisher et certificat et version et architecture. Ils permettent de dater le problème et de séparer un défaut de ciblage, de transport ou d’exécution avant d’envisager une correction.

Les symptômes « 0x80073CF3, 0x800B0109 et 0x80073D02 » peuvent se ressembler à l’écran tout en provenant de causes différentes. Chaque branche de diagnostic associe donc un signal, une preuve et une action de correction précise.

• localiser précisément la phase en échec
• interpréter les événements et HRESULT sans généralisation
• corriger le package ou son ciblage avec un rollback vérifiable

Cartographie du flux à diagnostiquer

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.

État initial et prérequis de collecte

L’état initial de Troubleshooting AppX, UWP et MSIX doit couvrir 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. Cette photographie est prise avant de relancer un traitement ou de modifier une affectation.

Les couches Intune, Delivery, AppX engine, Registration sont contrôlées séparément. Un prérequis absent devient alors une cause identifiable, au lieu d’être noyé dans les effets des essais suivants.

• 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

Collecte des preuves : journaux, registre et états

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

Investigation pas à pas

L’investigation suit l’ordre Intune → Delivery → AppX engine → Registration. La première divergence confirmée détermine la branche suivante et évite de multiplier les symptômes secondaires.

Pour Troubleshooting AppX, UWP et MSIX, les contrôles « Qualifier le type de remise », « Identifier exactement le package », « Reproduire de façon contrôlée » précisent à la fois l’emplacement, le résultat attendu et la vérification à effectuer.

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.

Commandes et scripts de diagnostic en lecture seule

Les exemples ci-dessous contrôlent PackageFamilyName et PackageFullName, Publisher et certificat, version et architecture, dépendances du manifeste. Leur sortie doit être rapprochée de l’heure de l’incident et du contexte d’exécution concerné.

Pour Troubleshooting AppX, UWP et MSIX, les données utiles se lisent dans les états locaux, les journaux et les rapports cités dans chaque exemple. Une valeur isolée ne remplace pas cette corrélation.

# Collecte de diagnostic
$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 }

$ErrorActionPreference = 'Stop'
try {
  Get-AppxPackage -AllUsers | Select-Object Name, PackageFullName, Status
  Get-AppxProvisionedPackage -Online | Select-Object DisplayName, PackageName
  Get-WinEvent -LogName 'Microsoft-Windows-AppXDeploymentServer/Operational' -MaxEvents 120 |
    Select-Object TimeCreated, Id, LevelDisplayName, Message
}
catch {
  Write-Error "Collecte impossible : $($_.Exception.Message)"
  exit 1
}

[13:20:01.440] AppX  ActivityId=<GUID> Package=<PACKAGE> Stage=Started
[13:20:02.104] AppX  ActivityId=<GUID> Dependency=<FRAMEWORK> State=Resolved
[13:20:04.711] AppX  ActivityId=<GUID> RegisterUser=<SID> State=Failed
[13:20:04.712] AppX  ActivityId=<GUID> HRESULT=0x80073CF3
[13:21:10.008] Check PackageRegistered=False Provisioned=True

Arbre de décision : symptômes, causes et corrections

La matrice couvre notamment 0x80073CF3, 0x800B0109, 0x80073D02, Installé pour admin seulement. Ces symptômes servent de points d’entrée; la preuve indiquée dans la même ligne confirme ou écarte la cause.

Après correction, les contrôles identité et version attendues, signature approuvée et dépendances résolues sont rejoués dans les mêmes conditions pour vérifier que le problème n’a pas simplement changé de phase.

Validation de la correction et critères de clôture

La correction de Troubleshooting AppX, UWP et MSIX est validée avec les mêmes points de mesure que le diagnostic initial. Le résultat local et l’état remonté dans le service doivent raconter la même chronologie.

• 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

Retour arrière, escalade et points de vigilance

Le retour arrière de Troubleshooting AppX, UWP et MSIX restaure l’état connu décrit ci-dessous. Sa réussite se vérifie sur le poste et dans le service, pas seulement par la disparition d’une affectation.

Une escalade conserve les preuves correspondant à PackageFamilyName et PackageFullName, Publisher et certificat, version et architecture, dépendances du manifeste ainsi que les causes déjà écartées.