Pendant des années, déployer une application Win32 avec Intune et PowerShell voulait dire une chose assez simple : embarquer un script .ps1 dans le package .intunewin, puis appeler ce script depuis la ligne de commande d’installation.
Typiquement :
powershell.exe -ExecutionPolicy Bypass -NoProfile -File .\Install.ps1
Ça fonctionnait.
Mais ce n’était pas très propre.
À chaque modification du script, même mineure, il fallait souvent recréer le package, le recharger dans Intune, attendre le traitement côté service, puis relancer les tests.
Microsoft vient de corriger ce point avec une évolution intéressante : les applications Win32 Intune peuvent maintenant utiliser un script PowerShell comme type d’installateur natif, à la place de la ligne de commande classique. Microsoft documente désormais ce mode dans la gestion des Win32 apps Intune : lors de l’ajout d’une application, il est possible de téléverser un script PowerShell qui sert directement d’installateur. Le script est empaqueté avec le contenu de l’application et exécuté dans le même contexte que l’installateur.
Ce n’est pas une révolution spectaculaire.
Mais pour ceux qui packagent des applications Intune au quotidien, c’est une vraie amélioration.
Avant : PowerShell était seulement appelé par la ligne de commande
Jusqu’ici, PowerShell n’était pas vraiment un type d’installation dans Intune.
On préparait un dossier avec les sources, l’installateur, éventuellement un script d’installation, un script de désinstallation, puis on générait le package .intunewin.
Ensuite, dans Intune, on utilisait une commande du type :
%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy Bypass -NoProfile -File Install.ps1
Le script faisait le vrai travail.
Mais pour Intune, le programme d’installation restait une simple ligne de commande.
La logique PowerShell était donc cachée dans le contenu du package. Si le script devait évoluer, le package devait souvent évoluer aussi.
Et c’est exactement là que ça devenait pénible.
Correction d’un paramètre silencieux, ajout d’un prérequis, suppression d’une ancienne version, modification d’une clé de registre, meilleur logging… autant de petits changements qui pouvaient imposer un nouveau packaging complet.
Maintenant : PowerShell devient le type d’installateur
Dans l’onglet Program d’une application Win32, Intune permet maintenant de choisir le type d’installateur :
- Command line ;
- PowerShell script.
Ce choix est disponible pour les Win32 apps, mais aussi pour les applications issues de l’Enterprise App Catalog. Une fois le mode PowerShell sélectionné, l’administrateur peut charger un script d’installation, un peu comme on le fait déjà pour une règle de détection ou d’applicabilité.
À quoi ça sert concrètement ?
Ce mode est utile dès qu’une installation nécessite un peu plus qu’une ligne silencieuse classique.
Par exemple :
- vérifier si une ancienne version est présente ;
- désinstaller proprement une version précédente ;
- créer un répertoire de logs ;
- modifier une clé de registre avant ou après installation ;
- tester un prérequis ;
- adapter l’installation selon l’architecture, la langue ou l’état du poste ;
- lancer un MSI ou un EXE avec des paramètres calculés ;
- contrôler le code retour ;
- ajouter une validation post-installation.
Microsoft cite explicitement les cas de vérification de prérequis, changements de configuration, actions post-installation et logique conditionnelle basée sur l’état du device.
Le scénario typique : vous avez une application dont l’installateur est stable, mais votre logique d’installation doit évoluer.
Avant, vous repartiez sur un nouveau package.
Maintenant, vous pouvez modifier le script dans la configuration de l’app.
C’est beaucoup plus propre.
Exemple simple
Imaginons une application installée via MSI, mais avec un besoin de nettoyage avant installation.
Le script peut ressembler à ceci :
$LogPath = "C:\ProgramData\Company\AppInstall"
$MsiPath = Join-Path $PSScriptRoot "Application.msi"
New-Item -Path $LogPath -ItemType Directory -Force | Out-Null
# Suppression d'une ancienne version si présente
$UninstallPaths = @(
"HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*",
"HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*"
)
$OldApp = Get-ItemProperty -Path $UninstallPaths -ErrorAction SilentlyContinue |
Where-Object { $_.DisplayName -eq "Old Application" } |
Select-Object -First 1
if ($OldApp -and $OldApp.UninstallString) {
$UninstallCommand = $OldApp.UninstallString
# Si l'ancien package est un MSI, on force la désinstallation propre
if ($UninstallCommand -match "msiexec") {
$UninstallCommand = $UninstallCommand -replace "/I", "/X"
$UninstallCommand = "$UninstallCommand /qn /norestart /l*v `"$LogPath\uninstall.log`""
}
else {
$UninstallCommand = "$UninstallCommand /quiet /norestart"
}
Start-Process "cmd.exe" -ArgumentList "/c $UninstallCommand" -Wait
}
# Installation de la nouvelle version
$Arguments = "/i `"$MsiPath`" /qn /norestart /l*v `"$LogPath\install.log`""
$Process = Start-Process "msiexec.exe" -ArgumentList $Arguments -Wait -PassThru
exit $Process.ExitCode
Rien de magique.
Mais ce type de logique est beaucoup plus lisible dans un script dédié que dans une ligne de commande interminable.
Les limites à connaître
La fonctionnalité est pratique, mais elle n’enlève pas les règles de base des Win32 apps.
Le script doit rester silencieux. Intune ne supporte pas les installations interactives : pas de fenêtre à valider, pas de prompt utilisateur, pas de bricolage avec ServiceUI.exe pour forcer une interaction. Microsoft rappelle que les installations Intune doivent être silencieuses et ne pas nécessiter d’action utilisateur.
Le script est aussi limité à 50 KB. Il s’exécute dans le même contexte que l’installateur, donc en contexte système ou utilisateur selon la configuration de l’application. Les codes retour du script déterminent le succès ou l’échec remonté dans Intune.
Donc oui, PowerShell devient plus simple à utiliser.
Mais non, ce n’est pas une invitation à écrire un script de 800 lignes qui fait tout et n’importe quoi.
Si le script devient trop gros, c’est souvent le signe qu’il faut mieux structurer le packaging.
Attention à Multi-Admin Approval
Autre point à surveiller : Multi-Admin Approval, ou MAA.
Microsoft indique que si MAA est activé sur le tenant, il n’est pas possible d’uploader les scripts PowerShell pendant la création initiale de l’application. Il faut d’abord créer l’application, puis ajouter ou modifier les scripts ensuite. Microsoft précise aussi que certains paramètres de script, comme enforceSignatureCheck ou runAs32Bit, pourront à terme nécessiter une approbation MAA.
C’est un détail qui peut surprendre en environnement sécurisé.
Et c’est logique : modifier un script d’installation, c’est modifier du code exécuté sur les postes. Ce n’est pas un simple champ descriptif.
Enterprise App Catalog : le cas le plus intéressant
Le support dans les Win32 apps est déjà utile.
Mais le support dans l’Enterprise App Catalog est peut-être encore plus intéressant.
L’Enterprise App Catalog fournit des applications prépackagées, maintenues et simplifiées côté déploiement. Le problème, c’est que dans certains cas, on a besoin d’un petit ajustement spécifique à l’entreprise : une clé de registre, une suppression d’ancienne version, un paramètre complémentaire, une configuration post-install.
Avant, si l’application du catalogue ne correspondait pas exactement au besoin, on pouvait être tenté de refaire son propre package.
Avec le script PowerShell natif, on peut garder les bénéfices du catalogue tout en ajoutant une logique d’installation ou de désinstallation adaptée. Mike Meier souligne justement que c’est l’un des intérêts majeurs : apporter de petites modifications sans recréer un package complet, tout en conservant les bénéfices d’une application prépackagée.
C’est probablement là que la fonctionnalité prend le plus de valeur.
Ce que ça ne remplace pas
Il ne faut pas confondre ce nouveau mode avec les scripts PowerShell Intune classiques.
Un script PowerShell Intune déployé depuis Devices > Scripts and remediations est une action de gestion device. Il s’exécute selon sa propre logique, avec son propre cycle, et n’est pas directement lié au cycle d’installation d’une application.
Le PowerShell script installer, lui, fait partie de l’application Win32.
Il est exécuté comme installateur ou désinstallateur de l’application.
Il participe donc au cycle normal de l’app : assignment, téléchargement du contenu, installation, détection, reporting, retry, désinstallation.
Ce n’est pas le même usage, pour une configuration ponctuelle du poste, un script Intune ou une remediation peut suffire.
Pour une logique directement liée à l’installation d’une application, le nouveau mode est plus propre.
Ma lecture
Cette évolution ne va pas changer la vie de tout le monde.
Si vous déployez uniquement des MSI très simples avec une ligne silencieuse stable, vous pouvez continuer comme avant.
Mais dès que vous gérez des applications un peu pénibles, des anciennes versions à nettoyer, des prérequis à contrôler, des paramètres qui changent souvent, ou des apps Enterprise App Catalog à adapter légèrement, c’est une amélioration nette.
Conclusion
Le support natif des scripts PowerShell comme installateur Win32 dans Intune est une petite évolution, mais une bonne évolution.
PowerShell n’est plus seulement appelé depuis une ligne de commande. Il devient un type d’installateur à part entière, configurable directement dans l’application.
Cela permet d’ajouter de la logique, de mieux gérer les prérequis, de nettoyer les anciennes versions, de personnaliser les installations Enterprise App Catalog, et de modifier certains comportements sans reconstruire systématiquement le package .intunewin.
Il faut rester raisonnable : scripts courts, silencieux, testés, avec des codes retour propres et du logging.
Mais bien utilisé, ce nouveau mode va clairement simplifier la vie des équipes qui maintiennent des applications Win32 dans Intune.
Ce n’est pas une révolution mais juste le genre de petite amélioration qui rend Intune un peu plus agréable à exploiter au quotidien.