Intune : analyser une installation silencieuse MSI ou EXE qui échoue

Résumé

Je sépare le moteur Intune du moteur d’installation. Intune prépare le contenu, évalue les exigences et lance la commande ; msiexec ou le bootstrapper éditeur réalise ensuite l’installation. Le journal de chaque couche est nécessaire.

Pour MSI, une journalisation verbose avec /L*v permet de retrouver la première erreur utile et la valeur de retour 3. Pour EXE, les commutateurs silencieux sont propres à l’éditeur : /quiet, /S ou /verysilent ne sont pas interchangeables.

Le code 0 ne suffit pas si la règle de détection ne retrouve pas l’état attendu. Inversement, 3010 signifie généralement succès avec redémarrage requis et doit être mappé conformément au comportement voulu.

Je sépare le moteur Intune du moteur d’installation. Intune prépare le contenu, évalue les exigences et lance la commande ; msiexec ou le bootstrapper éditeur réalise ensuite l’installation. Le journal de chaque couche est nécessaire.

Contexte, objectif et périmètre

Les échecs fréquents viennent d’une commande copiée depuis une documentation ancienne, d’un chemin relatif incorrect, d’un processus enfant non attendu, d’un prérequis absent ou d’une règle de détection déconnectée du résultat réel.

Un test dans une console administrateur ne reproduit pas SYSTEM. Le profil, les lecteurs réseau, HKCU, les certificats utilisateur, les proxys et les chemins temporaires changent. J’utilise un laboratoire pour reproduire ce contexte sans modifier un poste de production.

Je traite « Troubleshooting MSI et EXE silencieux » 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 : retrouver la commande et le code réellement exécutés
• Objectif : lire les journaux MSI/éditeur et IME dans une même chronologie
• Objectif : distinguer échec d’installation et échec de détection
• Périmètre : applications Win32 .intunewin
• Périmètre : MSI et bootstrapper EXE
• Périmètre : installation en contexte système ou utilisateur

Architecture et fonctionnement général

L’IME évalue applicabilité, dépendances, supersedence et détection avant de lancer l’installation. Le répertoire de contenu courant n’est pas une interface à coder en dur ; la commande doit utiliser les fichiers emballés avec des chemins relatifs maîtrisés.

Windows Installer trace les propriétés, actions standard et custom actions. Un EXE peut encapsuler plusieurs MSI, installer un service puis quitter avant son enfant, ou retourner son propre code. Je recherche donc le moteur réel derrière le bootstrapper.

Après exécution, l’IME applique la table de codes de retour puis rejoue la détection. C’est cette détection qui confirme la conformité applicative pour Intune.

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.

• source éditeur et hachage conservés
• commande silencieuse officiellement documentée ou validée
• journalisation locale prévue
• installation et désinstallation testées
• règle de détection indépendante et stable
• codes 0, 3010, 1641 et codes éditeur documentés
• pilote hors production

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.

Lire un journal MSI sans se perdre

Je lance msiexec avec /qn /norestart et /L*v vers un chemin accessible à SYSTEM. Je recherche d’abord le code final, puis Return value 3. La cause utile se trouve souvent quelques lignes avant, pas sur la dernière ligne du fichier.

Les propriétés MSI peuvent révéler une condition de lancement, un chemin, une version ou le contexte ALLUSERS. Les custom actions appartiennent à l’éditeur ; leur sortie doit être rapprochée des journaux secondaires qu’elles génèrent.

Les codes 1603, 1618 et 1619 sont des catégories, pas des diagnostics complets. 1603 exige le journal détaillé, 1618 signale une autre transaction MSI, et 1619 impose de vérifier l’accès et l’intégrité du package.

EXE : identifier le bootstrapper réel

Je consulte la documentation de l’éditeur et, si nécessaire, les propriétés du binaire. Un InstallShield, Inno Setup, NSIS ou WiX Burn n’accepte pas les mêmes options. Tester une suite de switches au hasard peut lancer une interface invisible ou accepter la commande sans installer.

Je vérifie si le processus attend ses enfants. Lorsque le bootstrapper quitte trop tôt, Intune peut lancer la détection alors qu’un MSI travaille encore. La correction appartient au wrapper ou à l’option d’attente, pas au GRS.

Les fichiers de réponse et transformations MST sont versionnés avec le package. Ils ne doivent pas contenir de secret et leur effet doit être décrit, notamment les services, redémarrages, pilotes et composants supprimés.

Détection, 32/64 bits et contexte

Une application peut s’installer correctement puis être déclarée en échec parce que la détection cherche le mauvais fichier, la mauvaise version ou la mauvaise vue du registre. Je compare l’artefact choisi au résultat réel de plusieurs versions.

Pour une détection utilisateur, je précise quel profil doit contenir la valeur. Pour une installation SYSTEM, je privilégie un marqueur machine stable fourni par l’application plutôt qu’un fichier temporaire du programme d’installation.

Une mise à jour automatique peut modifier la version immédiatement après installation. Une égalité stricte devient alors fragile ; je choisis une règle compatible avec le cycle réel et je teste l’upgrade, la réparation et la supersedence.

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 {
    $productName = '<NomApplication>'
    $uninstallRoots = @(
        'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall',
        'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall'
    )
    foreach ($root in $uninstallRoots) {
        Get-ChildItem -LiteralPath $root | ForEach-Object { Get-ItemProperty -LiteralPath $_.PSPath } |
            Where-Object DisplayName -Like "*$productName*" |
            Select-Object DisplayName, DisplayVersion, Publisher, InstallLocation, UninstallString
    }
    Get-Content -LiteralPath 'C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\AppWorkload.log' -Tail 400
}
catch { Write-Error "Collecte MSI/EXE 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é.

• commande silencieuse sans interaction
• journal exploitable
• code de sortie mappé
• artefact détecté dans la bonne vue
• installation répétable
• désinstallation testée
• aucun secret dans package ou log

Journaux, diagnostic et constitution des preuves

Les journaux IME répondent à qui, quand et avec quelle commande. Le journal MSI ou éditeur répond à quelle action interne a échoué. J’ajoute éventuellement Application, MsiInstaller et les journaux du service installé.

Je conserve la ligne de commande en masquant les valeurs sensibles. Un jeton ou mot de passe ne doit jamais être passé en clair dans la commande, le registre, le package ou les logs.

• AppId et heure IME
• commande exacte
• contexte SYSTEM/utilisateur
• code de sortie décimal et hexadécimal
• journal MSI verbose
• Return value 3
• processus enfants
• preuve utilisée par la détection

14:03:02 Command = setup.exe /quiet /norestart
14:05:19 ExitCode = 0 Mapped = Success
14:05:21 Detection registry view = 32-bit
14:05:21 Expected = HKLM\Software\Fabrikam\Agent Version 7.4
14:05:21 Actual = HKLM\Software\Fabrikam\Agent Version 7.5
14:05:22 Result = 0x87D1041C
Conclusion = INSTALL_OK_DETECTION_FALSE

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 : restaurer l’ancienne version et sa détection
• Rollback : désinstaller par la commande éditeur validée
• Rollback : restaurer dépendances seulement si leur retrait est supporté
• Vigilance : ne pas déduire la cause de 1603 seul
• Vigilance : ne pas utiliser de lecteur réseau sous SYSTEM
• Vigilance : ne pas tuer msiexec sans qualification
• Vigilance : ne pas corriger une détection par suppression GRS