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

Résumé opérationnel

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.

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

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.

• applications Win32.intunewin
• MSI et bootstrapper EXE
• installation en contexte système ou utilisateur

Questions à résoudre et méthode de diagnostic

Pour Troubleshooting MSI et EXE silencieux, l’enquête suit le parcours IME → Command line → Installer → Detection. 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 AppId et heure IME, commande exacte et contexte SYSTEM/utilisateur. 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 « 0x87D1041C, 1603 et 1618 » 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.

• retrouver la commande et le code réellement exécutés
• lire les journaux MSI/éditeur et IME dans une même chronologie
• distinguer échec d’installation et échec de détection

Cartographie du flux à diagnostiquer

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.

État initial et prérequis de collecte

L’état initial de Troubleshooting MSI et EXE silencieux doit couvrir source éditeur et hachage conservés, commande silencieuse officiellement documentée ou validée, journalisation locale prévue, installation et désinstallation testées. Cette photographie est prise avant de relancer un traitement ou de modifier une affectation.

Les couches IME, Command line, Installer, Detection 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.

• 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

Collecte des preuves : journaux, registre et états

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

Investigation pas à pas

L’investigation suit l’ordre IME → Command line → Installer → Detection. La première divergence confirmée détermine la branche suivante et évite de multiplier les symptômes secondaires.

Pour Troubleshooting MSI et EXE silencieux, les contrôles « Lire la tentative Intune », « Reproduire sous le bon contexte », « Trouver la première cause » précisent à la fois l’emplacement, le résultat attendu et la vérification à effectuer.

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.

Commandes et scripts de diagnostic en lecture seule

Les exemples ci-dessous contrôlent AppId et heure IME, commande exacte, contexte SYSTEM/utilisateur, code de sortie décimal et hexadécimal. Leur sortie doit être rapprochée de l’heure de l’incident et du contexte d’exécution concerné.

Pour Troubleshooting MSI et EXE silencieux, 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 {
    $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 }

$ErrorActionPreference = 'Stop'
try {
  $msiLog = 'C:\Windows\Temp\Application-install.log'
  if (Test-Path -LiteralPath $msiLog) {
    Select-String -LiteralPath $msiLog -Pattern 'Return value 3','error','failed' -Context 4,12
  }
  $imeLog = 'C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\AgentExecutor.log'
  if (Test-Path -LiteralPath $imeLog) {
    Select-String -LiteralPath $imeLog -Pattern 'exit code','exception','failed' -Context 2,6
  }
}
catch {
  Write-Error "Collecte impossible : $($_.Exception.Message)"
  exit 1
}

[11:05:21.007] AgentExecutor AppId=<GUID> Context=SYSTEM Command=msiexec.exe
[11:05:21.401] MSI           ProductCode=<GUID> Action=Install
[11:05:27.883] MSI           Action=InstallFiles ReturnValue=3
[11:05:27.884] MSI           Error=AccessDenied Path=C:\Program Files\Example
[11:05:28.102] AgentExecutor ExitCode=1603

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

La matrice couvre notamment 0x87D1041C, 1603, 1618, 1619. 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 commande silencieuse sans interaction, journal exploitable et code de sortie mappé 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 MSI et EXE silencieux 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.

• 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

Retour arrière, escalade et points de vigilance

Le retour arrière de Troubleshooting MSI et EXE silencieux 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 à AppId et heure IME, commande exacte, contexte SYSTEM/utilisateur, code de sortie décimal et hexadécimal ainsi que les causes déjà écartées.