Comment déployer des applications WinGet avec Intune : 4 méthodes qui fonctionnent

Lorsque vous souhaitez déployer des applications WinGet avec Intune, le processus devrait être simple et direct. Après tout, WinGet connaît déjà l’URL du programme d’installation, la version et les commutateurs silencieux de milliers d’applications Windows, donc vous devriez pouvoir indiquer le catalogue à Intune et déployer, n’est-ce pas ?

Eh bien, il y a un hic. Intune ne dispose d’aucun type d’application permettant un déploiement direct depuis le dépôt communautaire WinGet, uniquement des applications du Microsoft Store. Pour compliquer encore les choses, l’outil en ligne de commande WinGet n’est pas pris en charge lorsqu’un script s’exécute en tant que SYSTEM, le contexte qu’Intune utilise lorsque le comportement d’installation d’une application est défini sur System.

Dans cette optique, comment déployer WinGet avec Intune ? Nous avons identifié quatre méthodes qui peuvent faciliter le déploiement, alors voyons en quoi elles consistent, ce que chacune coûte, comment les configurer et comment résoudre les problèmes que vous pourriez rencontrer.

Intune peut-il déployer des applications WinGet nativement ?

En partie. Le type application Microsoft Store (nouveau) d’Intune utilise Windows Package Manager pour rechercher et installer des applications depuis le Microsoft Store. Il ne peut pas accéder au dépôt communautaire WinGet, le catalogue public utilisé par la plupart des guides WinGet, et aucun type d’application Intune ne permet de déployer depuis celui-ci. Pour déployer des applications du dépôt communautaire, vous avez besoin d’un script wrapper ou d’un package Win32.

Cet écart tient à la façon dont WinGet est organisé. Il récupère les applications depuis deux sources principales : le Microsoft Store (msstore) et le dépôt communautaire WinGet sur GitHub. L’intégration Store d’Intune, qui a remplacé le Microsoft Store for Business retiré, se connecte uniquement au premier.

Vous pouvez également voir le Catalogue d’applications d’entreprise de Microsoft mentionné dans les discussions sur Intune WinGet. Il s’agit d’une bibliothèque distincte d’applications Win32 que Microsoft prépare et héberge, et Microsoft indique qu’elle n’utilise pas WinGet. Cela nécessite également un abonnement au-delà d’Intune Plan 1 ou Plan 2.

Quatre façons d’utiliser WinGet avec Intune

Si vous souhaitez déployer des applications WinGet avec Intune, il existe encore des moyens de le faire. Voici les quatre façons les plus courantes d’utiliser WinGet avec Intune, notamment ce à quoi elles conviennent le mieux et leurs limites :

Voici comment fonctionne chaque méthode, étape par étape.

Méthode 1 : déployer des applications Microsoft Store avec le type d’application Microsoft Store (new)

La première façon de déployer des applications (et sans doute la plus simple) consiste à passer par l’application Microsoft Store. Vous pouvez le faire en quelques étapes rapides :

1. Dans le centre d’administration Intune, accédez à Apps → All Apps → Create, puis sélectionnez Microsoft Store app (new) sous Store app.

2. Sélectionnez « Rechercher dans l’application Microsoft Store » et recherchez l’application souhaitée par nom, éditeur ou ID d’application du Store. Les résultats indiqueront si chaque application est Win32 ou UWP.

3. Vérifiez les informations préremplies de l’application, définissez le comportement d’installation sur Système ou Utilisateur (notez que certaines applications n’en prennent en charge qu’un seul), et définissez les options du Company Portal (comme l’application mise en avant et la catégorie).

4. Attribuez l’application comme obligatoire, disponible pour les appareils inscrits ou à désinstaller, et définissez les notifications destinées aux utilisateurs finaux, le délai de grâce avant redémarrage et la date limite d’installation.

5. Vérifiez et créez. Intune maintient l’application à jour à mesure que de nouvelles versions apparaissent.

Cela dit, il existe certaines limites et conditions préalables à garder à l’esprit. Celles-ci peuvent compliquer le processus et signifier que vous devrez peut-être essayer une autre méthode :

1. Les appareils doivent disposer de l’Intune Management Extension, d’au moins deux cœurs de processeur et d’un accès réseau au Store ainsi qu’au contenu de l’éditeur.

2. Les applications Win32 dans le Store sont encore en préversion, et toutes les applications Win32 ne sont pas recherchables. De même, les applications payantes et les programmes d’installation ARM64 ne sont pas pris en charge.

3. Les applications Win32 du Store ne restent à jour que tant qu’elles restent attribuées dans Intune.

4. Les appareils enregistrés dans Entra doivent utiliser le comportement d’installation Système (donc Utilisateur n’est pas une option).

Méthode 2 : encapsuler une commande WinGet dans une application Win32

Si l’application Microsoft Store ne répond pas à vos besoins, vous pouvez déployer WinGet via Intune en encapsulant une commande WinGet dans une application Win32. Dans ces cas, une application Win32 est plus fiable qu’un simple script de plateforme, car elle inclut la détection d’état, les codes de retour et une commande de désinstallation, ce que les déploiements de scripts sur une seule ligne n’offrent pas.

Pourquoi WinGet échoue lorsque Intune s’exécute en tant que SYSTEM

Lorsque le comportement d’installation d’une application Win32 est défini sur System, Intune exécute sa commande d’installation en tant que SYSTEM, et c’est là que WinGet ne fonctionne plus. Le WinGet CLI n’est pas pris en charge dans le contexte SYSTEM car il est fourni dans App Installer, une application empaquetée (MSIX) enregistrée par utilisateur. Par conséquent, appeler WinGet par son nom dans un script SYSTEM échoue généralement, car SYSTEM ne peut pas le localiser.

Il existe quelques solutions de contournement. Les scripts de la communauté traitent généralement ce problème en résolvant winget.exe sous C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_*_x64__8wekyb3d8bbwe, mais il ne s’agit pas d’une méthode prise en charge par Microsoft. L’option prise en charge par Microsoft est le module PowerShell Microsoft.WinGet.Client, qui fonctionne dans le contexte système pour les applications installées à l’échelle de la machine.

Rédigez le script d’installation

Pour écrire le script d’installation, vous devez d’abord trouver l’ID du package, puis l’installer avec cet ID exact depuis le dépôt communautaire. Vous pouvez rechercher l’ID avec winget search <app name>, ou sans ligne de commande sur winstall, le navigateur gratuit du catalogue WinGet de Splashtop. Une fois que vous avez l’ID, la commande d’installation ressemble à ceci : winget install --id Git.Git -e --source winget --silent --accept-package-agreements --accept-source-agreements

Pour les installations SYSTEM, vous devrez inclure --scope machine. Gardez à l’esprit que Microsoft avertit que les installateurs EXE ne gèrent pas la portée de manière cohérente.

Pour Microsoft Intune, la commande d’installation peut être un script PowerShell allant jusqu’à 50 Ko. L’utilisation de powershell.exe dans le champ de commande lance la version 32 bits, tandis que l’utilisation du chemin Sysnative permet d’utiliser PowerShell en 64 bits.

Ajouter un script de détection

Veillez à ajouter un script pour détecter et confirmer que l’application est correctement installée. Intune considère l’application comme installée uniquement lorsque le script se termine avec le code 0 et écrit une sortie dans STDOUT ; toute sortie dans STDERR est interprétée comme non installée. Le script vérifie généralement le dossier d’installation de l’application, la version du fichier ou la clé de registre de désinstallation. Si vous vérifiez avec winget list, vous rencontrerez le même problème SYSTEM, il est donc préférable d’utiliser des vérifications de fichiers ou du registre.

Créez le package des scripts et chargez l’application Win32

Enfin, encapsulez les scripts avec le Microsoft Win32 Content Prep Tool pour produire le fichier .intunewin fichier. Vous pouvez ensuite ajouter ce fichier dans Apps → All apps → Add → Windows app (Win32), définir le comportement d’installation sur System, puis ajouter la commande de désinstallation, le script de détection et les exigences. Utilisez des chemins d’accès complets dans la commande de désinstallation, car Intune n’y développe pas les variables d’environnement.

Gardez à l’esprit que chaque application a besoin de son propre ensemble de scripts et de mises à jour, et que WinGet doit être présent et fonctionner sur chaque appareil où il est installé. Cette méthode peut donc demander plus de maintenance que les autres.

Méthode 3 : maintenir les applications WinGet à jour avec les remédiations Intune

Avec les remédiations Intune, vous pouvez associer un script de détection à un script de remédiation. Pour WinGet, votre script de détection vérifie si une application installée a une nouvelle version disponible ; si c’est le cas, le script de remédiation exécute winget upgrade pour cet ID de package. Cela fonctionne comme une méthode de mise à jour qui s’associe aux méthodes 2 et 4, mais ne gère pas l’installation initiale.

Les licences passent avant tout. Intune Remediations nécessite Windows Enterprise E3 ou E5 (inclus dans Microsoft 365 F3, E3 ou E5) ou Windows Education A3 ou A5, et les appareils doivent être gérés par Intune ou cogérés et exécuter Windows Enterprise, Professional ou Education.

Pour maintenir les applications à jour avec Intune Remediations, il suffit de suivre quelques étapes simples :

1. Dans le centre d’administration Intune, accédez à Devices → Manage devices → Scripts and remediations.

2. Créez un package de script avec un script de détection qui vérifie l’ID du package pour voir si une mise à niveau est disponible.

3. Ajoutez un script de correction qui exécute la mise à niveau pour cet ID avec --silent et les deux indicateurs --accept.

4. Affectez-la à un groupe d’appareils et définissez une planification pour vérifier les mises à jour.

Assurez-vous de cibler les ID de package spécifiques que vous souhaitez mettre à niveau. Bien que vous puissiez utiliser winget upgrade --all, cela mettra à jour toutes les applications que WinGet reconnaît, y compris celles que l’équipe IT n’a pas approuvées ou testées. Gardez également à l’esprit que WinGet installe la dernière version depuis le référentiel. Il peut donc déployer des mises à jour avant que l’équipe IT n’ait eu le temps de les tester. Si le script de remédiation s’exécute en tant que SYSTEM, il se heurte à la même limitation de WinGet que celle décrite dans la méthode 2.

Méthode 4 : empaqueter le programme d’installation comme une application Win32 native

Il est également possible de reconditionner le programme d’installation en tant qu’application Win32 native. Dans ce cas, WinGet sert de source d’informations sur l’application, plutôt que d’application elle-même. En utilisant le manifeste WinGet pour trouver le programme d’installation et ses commutateurs silencieux, vous pouvez déployer le programme d’installation comme une application Win32 standard.

Cela signifie que les appareils peuvent déployer l’application sans client WinGet fonctionnel, que le problème du contexte SYSTEM ne s’applique pas et que vous avez accès à toutes les fonctionnalités Win32 d’Intune.

Vous pouvez empaqueter le programme d’installation en tant qu’application Win32 en quelques étapes :

1. Trouvez l’ID du package avec winget search (ou recherchez-le sur winstall) et examinez son manifeste pour le type d’installateur, l’URL de téléchargement et les options d’installation silencieuse. (WinGet exige que chaque installateur répertorié prenne en charge l’installation silencieuse.)

2. Téléchargez le programme d’installation avec WinGet ou depuis le fournisseur.

3. Confirmez la commande d’installation silencieuse pour ce type d’installateur. Nos guides sur les installations silencieuses MSI et les installations silencieuses EXE présentent les commutateurs pour chaque type d’installateur.

4. Encapsulez le programme d’installation avec le Microsoft Win32 Content Prep Tool pour créer le fichier .intunewin fichier.

5. Ajoutez-la en tant qu’application Windows (Win32), y compris les commandes d’installation et de désinstallation, une règle de détection (par code produit MSI, fichier ou registre), les exigences et les codes de retour.

6. Testez la qualité de l’installation de l’application, sa capacité à détecter qu’une installation est terminée et sa désinstallation sur un appareil de test vierge avant de la déployer sur davantage d’appareils.

7. Chaque fois qu’une nouvelle version est publiée, vous devrez relancer la compilation et utiliser la supersédence pour remplacer l’ancienne application.

Cette option offre le plus de possibilités de personnalisation et de contrôle aux équipes IT, même si cela signifie aussi qu’elles doivent répéter le processus pour chaque application et chaque mise à jour. Par conséquent, les équipes disposant de vastes catalogues d’applications peuvent avoir du mal à suivre la charge de travail.

Alors, quelle méthode est la plus efficace ? Nous pouvons les examiner en détail et voir quand ce compromis en vaut la peine et quand d’autres méthodes sont préférables.

WinGet vs application Win32 dans Intune : quelle approche convient le mieux

Le choix principal consiste à déterminer si les appareils exécutent WinGet au moment de l’installation ou reçoivent une application Win32 que vous avez empaquetée à l’avance. Voici comment les deux se comparent :

En comparant les options, nous pouvons voir quelques détails importants. Pour une poignée d’utilitaires à faible risque, les scripts WinGet peuvent être rapides et demander moins d’efforts au départ. Pour les applications métier, les appareils soumis à des exigences réglementaires ou les grands catalogues, une application Win32 packagée est plus fiable, car elle offre des versions prévisibles et des tests avant le déploiement.

Si l’application est répertoriée dans le Microsoft Store, la méthode 1 est généralement l’option la plus légère.

Problèmes courants lors du déploiement d’applications WinGet avec Intune

Même avec la bonne méthode, le déploiement d’applications WinGet avec Intune présente des difficultés. Les équipes IT peuvent rencontrer des problèmes courants lors du déploiement d’applications, mais elles peuvent les identifier et les résoudre.

Les problèmes courants incluent :

1. WinGet n’est pas reconnu dans un script Intune

Si votre script indique que winget n’est pas reconnu, le script s’exécute très probablement en tant que SYSTEM, où l’interface en ligne de commande WinGet n’est pas prise en charge, car App Installer s’enregistre par utilisateur. Ce problème peut être résolu en localisant winget.exe via son chemin complet ou en utilisant le module PowerShell Microsoft.WinGet.Client, comme mentionné dans la méthode 2.

2. L’application s’installe pour le mauvais utilisateur ou au mauvais endroit

Si l’application s’installe au mauvais endroit ou pour le mauvais utilisateur, il s’agit d’une question de portée d’installation. Avec SYSTEM, la portée utilisateur correspond au propre profil de SYSTEM, tandis que les installateurs EXE gèrent de manière incohérente la portée utilisateur et la portée machine. Pour corriger cela, utilisez --scope machine pour les installations SYSTEM (assurez-vous de le tester d’abord avant de déployer l’application plus largement).

3. Le téléchargement échoue avec une erreur 403 Forbidden

Si le téléchargement renvoie une erreur 403 Forbidden, l’éditeur du logiciel bloque peut-être l’agent utilisateur de WinGet sur ses serveurs de téléchargement. Si le programme d’installation se télécharge correctement dans un navigateur, c’est probablement la cause. Dans ce cas, vous pouvez télécharger directement le programme d’installation et le déployer comme application Win32 packagée, comme indiqué dans la méthode 4.

4. Une application du Store n’apparaît pas dans la recherche Intune

Si une application du Store n’apparaît pas lorsque vous la recherchez, cela peut être dû à l’une des trois raisons suivantes : 1. Elle n’est pas disponible dans votre région, 2. C’est une application payante, ce qui signifie qu’elle n’est pas prise en charge, ou 3. Sa plateforme n’est pas prise en charge. Quelle qu’en soit la cause, commencez par confirmer la fiche de l’application, et si elle est inaccessible, utilisez la méthode 2 ou 4 pour l’installer.

5. Une application UWP Store affiche "non détectée après l’installation" (0x87D1041C)

Si vous recevez cette alerte, cela signifie qu’une application UWP est attribuée avec le comportement d’installation System à un appareil qui l’a déjà. Dans ce cas, ne vous inquiétez pas ; l’application est toujours correctement installée. Microsoft recommande également de ne pas mélanger les contextes utilisateur et système pour la même application.

6. Découvrez pourquoi une installation WinGet a échoué

Si une installation WinGet a échoué et que vous ne savez pas pourquoi, vous pouvez enquêter pour déterminer la cause et y remédier. L’ajout de --verbose-logs à la commande vous donne les journaux complets, et vous pouvez exécuter winget error <code> pour traduire un code de sortie en description. Notez que cela couvre les codes WinGet, MSIX et MSI, mais de nombreux programmes d’installation EXE peuvent utiliser des codes non standard. Notre guide d’installation silencieuse EXE explique comment les trouver.

Comment Splashtop Agentic Packr transforme les applications WinGet en packages Intune testés

Le déploiement d’applications WinGet avec Intune peut être compliqué, mais ce n’est pas une fatalité. Avec la bonne automatisation, les équipes peuvent packager les installateurs rapidement et efficacement sans mobiliser les ressources IT.

Cela nous amène à Splashtop Agentic Packr, un outil de packaging et de déploiement d’applications alimenté par l’IA pour les équipes IT modernes. Agentic Packr peut packager, valider et déployer des applications via Microsoft Intune, SCCM et plus encore, avec bien moins d’efforts manuels.

Splashtop Agentic Packr offre plusieurs fonctionnalités et avantages, notamment :

1. WinGet comme source, sans client WinGet sur les appareils

Splashtop Agentic Packr peut empaqueter des applications à partir d’un catalogue WinGet vérifié, via un ID de package WinGet ou Chocolatey, ou à partir de vos propres installateurs. Il crée une application Win32 native pour Intune, vous n’avez donc pas à vous soucier des problèmes de contexte WinGet et SYSTEM que les utilisateurs rencontrent souvent.

2. Règles de détection rédigées et testées avant tout déploiement

Lorsque l’agent alimenté par l’IA lit le programme d’installation, il rédige des règles de détection et teste la version sur une machine virtuelle propre. Ces tests vérifient que l’installation, la détection et la désinstallation fonctionnent, exécutent une analyse antimalware et génèrent une fiche d’évaluation QA ainsi que des journaux que les administrateurs IT peuvent examiner avant que l’application n’arrive dans Intune et ne soit déployée sur les appareils.

3. Publication et nouvelles versions sans reconstructions manuelles

Splashtop Agentic Packr élimine la nécessité de reconstruire manuellement les packages chaque fois qu’une nouvelle mise à jour est publiée. Grâce à sa connexion Express en un clic au locataire Intune et à ses mises à jour automatiques de version, Agentic Packr détecte les nouvelles mises à jour, les package, les teste et déploie le package mis à jour sans que les administrateurs aient à gérer manuellement chaque mise à jour.

4. Contrôle sur ce que les utilisateurs voient

Splashtop Agentic Packr permet à l’IT de contrôler la manière dont les installations et les mises à jour apparaissent aux utilisateurs. Les équipes peuvent personnaliser les notifications destinées aux utilisateurs finaux, les reports, les invites de redémarrage et les délais de grâce, afin que les installations et mises à jour obligatoires soient moins susceptibles d’interrompre les utilisateurs en plein travail.

Déployez des applications WinGet dans Intune sans maintenir de scripts

WinGet est une source solide d’informations sur les applications, et Intune est excellent pour déployer des applications, mais Intune ne peut pas déployer directement depuis le dépôt communautaire WinGet. La méthode la plus évolutive consiste à transformer les entrées WinGet en packages Win32 testés.

Avec Splashtop Agentic Packr, vous pouvez créer, tester et publier des packages d’applications avec beaucoup moins de travail manuel. Agentic Packr rend le packaging plus rapide et plus simple, en utilisant une console unique pour packager, déployer et mettre à jour les applications tout en gardant le contrôle aux administrateurs.

Vous voulez déployer des applications WinGet avec Intune sans les tracas ? Découvrez dès aujourd’hui comment Splashtop Agentic Packr peut vous aider.