With the Windows Package Manager (winget) applications can be installed very easily on a Windows device. Winget offers a large repository that you can use, like Chocolatey, for example. The big advantage of winget is that this client is already integrated into the system in the new Windows versions and will be more integrated into the Endpoint Manager (Intune) in the future.
How to winget applications as win32 app (as a system) can be distributed with Intune, I will show you in this article.
If you want to create the apps completely automatically and upload them to your environment, you can do that with my tool dem "Intune Win32 Deployer".
Table of Contents
- What is winget or the Windows Package Manager?
- Distribute Windows Package Manager (App Installer) with Intune
- Deploy winget packages with Intune (win32)
- Explanation of the template (install.ps1)
- Update of winget apps
What is winget or the Windows Package Manager?
Like Chocolatey, the Windows Package Manager is a package repository or manager that can be used freely. With this you can easily install and update programs via command line.
So far I have always used Chocolatey for this, mainly because winget could only be used in the user context. But this has changed and prompted me to gradually adapt my installations.
The Windows Package Manager will continue to play an increasingly important role in the future, so it is scheduled to replace the current Windows Store for Business at the beginning of 2023.
You can find a great contribution to the replacement of the Windows Store for Business on Rudy Ooms' website: Microsoft Store for Business Deprecated! What to do now? (call4cloud.nl)
Distribute Windows Package Manager (App Installer) with Intune
The app installer is actually included in the current versions of Windows, but the command winget or winget.exe is not yet available. This can lead to problems, especially with rollouts with autopilot.
That's why I distribute the App Installer as a separate Win32 package, which I can then store as a dependency for the individual applications.
To install it, I download the current version of the app installer from "https://aka.ms/getwinget", put it in a temporary directory and install it from there. Finally, I delete the directory again.
I package the whole thing together with an uninstallation routine and a validation file (check.ps1) in an intunewin / win32 app and upload it to Intune.
To upload, in Endpoint Manager navigate to "Apps > Windows" +Add (Windows app (win32)).
Here you upload the file "install.intunewin" from my template.

You also give the app a name, a description and fill in the publisher:

On the next page, add the following two commands:
install command | %SystemRoot%\sysnative\WindowsPowerShell\v1.0\powershell.exe -windowstyle hidden -executionpolicy bypass -command .\install.ps1 |
uninstall command | %SystemRoot%\sysnative\WindowsPowerShell\v1.0\powershell.exe -windowstyle hidden -executionpolicy bypass -command .\uninstall.ps1 |

In the detection rule you upload the script "check.ps1".

You do not have to define dependencies and a supersedence rule.
Finally, the app only has to be assigned.
Deploy winget packages with Intune (win32)
To distribute an application from the winget repository, I have put together a template that you can use. In this template, only the correct ID must be entered before packaging and uploading.
Find winget ID
You can find the ID either via CMD or PowerShell and the command "winget search" or even easier online at winget.run.

You can find the Docs article with further details on searching via "command line" here: searchCommand | Microsoft Docs
Adjust winget template and create intunewin
Once you have found the ID, all you have to do is insert it into my template.
You have to do this in all three files:
- install.ps1
- uninstall.ps1
- check.ps1
In all files you will find the note "WINGET PROGRAMID", which you replace with the desired ID.
Once you have adjusted the three files, you convert them into an intunewin.
I have described how to do this here: Create Win32 App / .intunewin
Detection rule
You have two options for the detection rule, either you use a script (more flexible) or a static detection rule based on a folder.
If you decide to go via script, until you're already done here. Because you have already prepared this in the point above by adapting the "check.ps1" file.
If you prefer to use a rule via folder detection (manually configured detection rule), you must select the appropriate folder with the correct version for each package. The easiest way to do this is to install the program on you or a test device and look for the folder under the following path:
C:\Program Files\WindowsApps |
If you do not have access to the folder, here are instructions on how to grant it to you as an admin: How to Access WindowsApps folder in Windows 10/8 - wintips.org - Windows Tips & How-tos
Once you have found the appropriate folder, copy the path. You will only need this again in the next step.

Build Win32 app in Intune
If you have adapted the template, created the intunewin and decided on a recognition rule, you can use the app in the Endpoint Manager under "Apps > Windows apps" create.

On the first page you store the app name, the description and a publisher.
On the second page, add the following two commands:
install command | %SystemRoot%\sysnative\WindowsPowerShell\v1.0\powershell.exe -windowstyle hidden -executionpolicy bypass -command .\install.ps1 |
uninstall command | %SystemRoot%\sysnative\WindowsPowerShell\v1.0\powershell.exe -windowstyle hidden -executionpolicy bypass -command .\uninstall.ps1 |
I also set the "Device restart behavior" to "No specific action" so that the installation does not force a restart if possible.
You don't have to define anything special in the requirements. (e.g. x64 and 2004)
In the detection rule, you now either upload the script or store the copied path.
In the dependencies, select the "Windows Package Manager":

You don't have to define a supersedence rule and only assign the app at the end.
FINISHED!
Explanation of the template (install.ps1)
In the first 6 lines the optional parameter "$param" is declared. This is only required if you have to add something to the installation (e.g. a license key).
You can then simply append these parameters to the installation command in the Win32 app in Intune.
In the line 8 the winget ID is declared, this is the ID according to the repository.
$ProgramName = "WINGETPROGRAMID"
Code language: PowerShell (powershell)
Then the path for a local log is specified in lines 9 and 10 and the transcript / log is started:
$Path_local = "$Env:Programfiles\_MEM"
Start-Transcript -Path "$Path_local\Log\$ProgramName-install.log" -Force
Code language: PowerShell (powershell)
Since the winget command is not directly known in the system context, we must first navigate to the correct directory and resolve the full path to "winget.exe".
I do that in the Line 13 to 16.
The EXE is then created using the variable $wingetexe
called.
$winget_exe = Resolve-Path "C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_*_x64__8wekyb3d8bbwe\winget.exe"
if ($winget_exe.count -gt 1){
$winget_exe = $winget_exe[-1].Path
}
Code language: PowerShell (powershell)
Afterward (line 19) comes the main process in which the program is installed via winget with the normal installation command and the parameters for the "silent" installation.
& $winget_exe install --exact --id $ProgramName --silent --accept-package-agreements --accept-source-agreements --scope=machine $param
Code language: PowerShell (powershell)
Finally, the transcript is ended again and the process is completed.
Stop-Transcript
Code language: PowerShell (powershell)
Update of winget apps
The quickest way to update winget applications is with the following two commands:
(The first for a specific application, the second for all.)
# Upgrade specific app (change Logitech.Options with the desired winget id)
winget upgrade Logitech.Options
# Upgrade all apps
winget upgrade --query --silent --force --accept-package-agreements --accept-source-agreements --all
Code language: PowerShell (powershell)
You can also distribute the "Upgrade all" command to your devices as a scheduled task to always keep all apps up-to-date. I have prepared a template (intunewin) for you here:
To distribute this package you can use the same parameters as described above for the "Windows Package Manager".
A disadvantage of this variant can be that all apps published on winget are included in the updater process. That is not always desired.
The tool offers a solution for this: Winget AutoUpdate: WAU daily updates apps as system and notify connected users. (Allowlist and Blocklist support) (github.com)
Hallo Florian - toll, deine winget-Lektüre !! Wie immer eine Inspiration !!
Ich würde gerne vor der Installation durch den winget-Befehl eine Überprüfung machen (mit dem Parameter 'upgrade'), ob eine Version des zu installierenden Pakets eventuell schon vorhanden ist (winget.exe upgrade -like "*$ProgramName*"). Wenn ja, dann soll winget nicht mit dem 'install' Parameter, sondern mit dem 'upgrade' Parameter weitermachen.
Aber ich vertue mich mit meiner weiteren "if-then" Anweisung anstelle deines ".\winget.exe ..." Befehls. Kann ich denn den Aufruf von winget auch als Variable definieren ??
Vielen Dank für deine Beiträge und vorab für deine Hilfe
Frank
Hallo Frank, vielen Dank für dein super Feedback!
Die Idee mit dem Upgrade ist super, das hatte ich mit den Chocolatey Paketen auch so gemacht.
Weil winget aber sämtliche auf dem Gerät installierte Programme mit dem öffentlichen Repository abgleicht, werden Apps automatisch "eingebunden". Das führt dazu, dass bei Installationen die Erkennungsregel bereits auf "installiert" switcht und das "install.ps1" nicht ausgeführt wird.
Ich löse diese in kleinen Umgebungen mit dem Scheduled Task, der alle winget apps updatet und in komplexeren mit dem Tool "Winget-autoupdate".
Beide Optionen habe ich im Beitrag ergänzt.
Wow - was für eine schnelle Reaktion. Danke !!
Nachdem ich bislang immer "große" intunewin-Pakete für die Softwareverteilung gebaut habe, möchte ich peu à peu auf eine Vorgehensweise mit winget umsteigen. Allerdings darf nicht generell jedes Programm upgedatet werden, sondern nur gezielte. Der Task über die Aufgabenplanung kann ja dann in den Parametern mit den gewünschten Programmen dediziert angepasst werden.
Aber bei der Installation würde ich gerne prüfen, ob schon eine "upgradebare" Version installiert ist und wenn ja, dann upgraden und wenn nicht, dann eine "normale" Installation. So kann ich verhindern, dass eine veraltete Version installiert bleibt und durch die Erkennungsregel rutscht.
Die Idee dabei ist folgende: Über den Parameter "upgrade" erstmal herausfinden, welche durch winget upgradbaren Installationen vorhanden sind:
$ProgramName = "WINGETPROGRAMID"
if ('winget.exe upgrade' -like "*$ProgramName*"){
winget.exe upgrade $ProgramName --silent --accept-package-agreements --accept-source-agreements $param
}
else{
winget.exe install --exact --id $ProgramName --silent --accept-package-agreements --accept-source-agreements $param
}
Aber der Aufruf einfach nur von "winget.exe" funktioniert ja nicht im System-Kontext. Oder könnte ich das in einer Variablen platzieren ??
Ah, jetzt vershee ich.
Ja, das könntest du so machen:
$Path_WingetAll = Resolve-Path "C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_*_x64__8wekyb3d8bbwe"
if($Path_WingetAll){$Path_Winget = $Path_WingetAll[-1].Path}
cd $Path_Winget
if($(.\winget upgrade) -like "*$ProgramName*"){...}
ach du meine Güte - was für ein Anfängerfehler von mir --> $(.\winget upgrade)
Funzt !! 1000 Dank !
Hi,
Ich hätte eine kurze Frage zu deinem Script.
Ich habe dieses angewendet und auch die Überprüfung ist erfolgreich, der App Installer ist auch unter den Programme zu finden.
Problem was ich habe ist das "Winget" nicht per CMD zur Verfügung steht.
Wenn der Client dann eine Zeitlang läuft scheint er sich die benötigten Daten per aus dem MS Store zu "ziehen"
Problem dabei ist das die Software die in der OOB / ESP bzw. direkt nach der User Anmeldung installiert werden soll natürlich nicht installiert werden kann da Winget nicht zur Verfügung steht.
Wie hast du dieses Problem gelöst oder mache ich etwas falsch?
Gruß
Flo 🙂
Hast du den Windows Package Manager auch als Abhängigkeit zu deinem winget App hinzugefügt?
Das sollte genau dieser Problematik entgegenwirken.
Hi Flo,
vielen Dank für deine schnelle Rückmeldung.
Ich denke ich habe den Fehler gefunden, es werden scheinbar noch Daten aus dem Microsoft Store heruntergeladen, es gibt aber scheinbar derzeit einen Bug / Problem mit dem MS Store (0x80131500)
Nachdem ich einen Client eingerichtet und Windows Updates gemacht habe funktionierte der MS Store wieder und dann auch Winget.
Anschließend habe ich einen AutoPiot Reset vom Gerät gemacht, in der OOBE hatte das Gerät dann kein Winget, nach der ESP hatte es dann dank deinem Script umgehend Winget.
Es besteht also scheinbar eine Abhängigkeit zu irgendwelchen Daten aus dem Store die Nachgeladen werden.
Merci für dein Troubleshooting, hoffen wir das Problem mit dem Store ist bald behoben.
Hi Florian
Hänge ebenfalls im OOBE fest, dass dort das Winget Win32 Paket nicht installiert wird.
Habe das Script auch für eine offline installaton des msixbundles angepasst, jedoch klappt auch dies nicht.
Hast du eine gute Idee, um gewisse Anwendungen erst nach OOBE/ESP zu installieren?
habe das hier mal versucht, aber bin nicht so richtig happy:
https://call4cloud.nl/2022/08/autopilot-is-mine-all-others-pay-time/
Gruss Angelo
Hi Angelo
Wenn du Apps erst nach der ESP-Phase installieren möchtest, wähle in den ESP-Einstellungen nur die Apps an, die Initial installier werden sollen. Alle anderen werden dann erst nach dem ersten Login angestossen.
Hi there. Thanks for the efforts here - really appreciate the springboard it has given me to start using winget for package installation. However, I seem to have hit a snag - can it be used to install Microsoft Store applications in the device/system context? I want to be able to deploy Power Apps to a device that will be used with a kiosk profile
Hi Ashley, unfortunately this is at least currently not possible.
Thanks for this awesome how to about Winget. Im stubling on a problem right now, on 2 devices i can install perfectly apps through Intune and on another device nothing is happening and I don't have any clue where to start looking. In CMD or powershell i can use the command Winget put no installs are happening through the company portal.
I hope you are able to guide me in the right direction.
Are the apps in a "waiting for download" loop?
Then maybe the device is missing the Intune Agent for MSI installations. This is the case if they are only registered/joined, but not Intune managed.
Hello,
First of all thank you for the amazing tutorial, unfortunatelly the uninstall, upgrade and check are not working for nonlocal admin users.
If anyone has a solution for this, I am all ears!
Kr,
Gustavo
Hi Gustavo,
That's correct. The way shown in this tutorial works only for deployments in the system context.
If you want to install apps in the user context (non admin) you don't habe to resolve the path to the exe, you can use just the term "winget" in your script.
Florian,
I want to deploy in the system context, but the update, check and uninstall are not working for users that are not local admin of their machines.
Hallo Florian,
vielleicht hast du noch einen Tipp für mich.
Ich wende dein Script zur Installation von Winget und auch das von "call4cloud.nl" an.
Egal welches der Scripte ich nutze, Winget / Winget.exe steht nach der Ausführung des Scriptes nicht unmittelbar bereit, erst wenn der Client in der Lage gewesen ist eine Verbindung zum MS Store aufzubauen und "die aktuellste" Version herunterzuladen stehen die Befehle zur Verfügung.
Bin ich der einzige mit diesem Problem?
Durch den oben beschriebenen Umstand ist es nicht möglich in der OOBE / ESP erfolgreich Programme mit Winget zu installieren was leider mehr als schade ist 🙂
Gruß
Florian
Hi Florian, ja leider leider ist es so, dass es winget noch/wieder etwas zu lange braucht, bis es bereit ist.
Ich bin dabei einige tests zu machen und hoffe eine Lösung zu finden. In der Zwischenzeit habe ich es auch so gehandhabt, dass die winget Apps nicht während der ESP-Phase installiert werden.
Gruss Florian 😉
Hi Florian, quick question, would you say Winget is preferred over chocolatey for deployment with Intune?
For me, the main advantage is that it is and will be more integrated in Windows, so you didn't have another third-party involved.
For now, not alle features are as evolved as in chocolatey, but I'm sure that therere soon on a similar level.
Thank you, I agree with that, for now I will keep deploying with Chocolatey, but will keep an eye on winget with views to migrate later.
Hallo! Wow tolle Anleitung.
Bei Windows 11 ist der "App Installer" schon vorinstalliert. Wie kann man mit der vorinstallierten Version damit arbeiten? (bzw. bei Windows 10 mit der MS Store Version)
LG Thomas
Hallo Thomas, da ist das Verhalten dasselbe. Oft dauert es aber etwas, bis der App Installer ready ist, weshalb die Installatonen bei neunen Geräten in den ersten 30min fehlschlagen können.
Hi Florian, Thank you for taking the time to put all of this together.
Thank you for this guide. I have tried to implement, and everything seems to work... except that the applications do not appear after they install. I tested with GIMP.
At first I thought there was something wrong because both of my test computers were stuck on "Download pending" for hours. Then out of the blue they both installed the app.
...Except that they didn't. Company Portal reports that the app is installed. Intune reports that the app is installed (it even shows up on the "Discovered Apps" list). But the app is not on the computer. Even after an Administrator search of C:\, there's nothing.
The installation log does not report anything amiss. I copy-pasted below:
**********************
Windows PowerShell transcript start
Start time: 20221110151006
Username: MYDOMAIN\SYSTEM
RunAs User: MYDOMAIN\SYSTEM
Configuration Name:
Machine: MYCOMPUTER (Microsoft Windows NT 10.0.19044.0)
Host Application: C:\windows\sysnative\WindowsPowerShell\v1.0\powershell.exe -windowstyle hidden -executionpolicy bypass -command .\install.ps1
Process ID: 9244
PSVersion: 5.1.19041.1682
PSEdition: Desktop
PSCompatibleVersions: 1.0, 2.0, 3.0, 4.0, 5.0, 5.1.19041.1682
BuildVersion: 10.0.19041.1682
CLRVersion: 4.0.30319.42000
WSManStackVersion: 3.0
PSRemotingProtocolVersion: 2.3
SerializationVersion: 1.1.0.1
**********************
Transcript started, output file is C:\Program Files\_MEM\Log\GIMP.GIMP-install.log
Failed in attempting to update the source: winget
The `msstore` source requires that you view the following agreements before using.
Terms of Transaction: https://aka.ms/microsoft-store-terms-of-transaction
The source requires the current machine's 2-letter geographic region to be sent to the backend service to function prope
rly (ex. "US").
Found GIMP [GIMP.GIMP] Version 2.10.32
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Downloading https://download.gimp.org/pub/gimp/v2.10/windows/gimp-2.10.32-setup-1.exe
██████████████████████████████ 252 MB / 252 MB
Successfully verified installer hash
Starting package install...
Successfully installed
**********************
Windows PowerShell transcript end
End time: 20221110151335
**********************
Gould you check two things for me?
1. I've got a new commit for the install template, maybe this helps.
2. Could you test another application? (I've had similar problem with GIMP a couple of weeks ago. )
Thank you! FWIW, GIMP worked if I adjusted your templates to use local user Winget, and set Intune to install under User context (which is fine with me).
I tried Kdenlive with your updated commit.
This time it had a more conventional error.
**********************
Windows PowerShell transcript start
Start time: 20221117161757
Username: CASEIL\SYSTEM
RunAs User: CASEIL\SYSTEM
Configuration Name:
Machine: CASE-001577 (Microsoft Windows NT 10.0.19044.0)
Host Application: C:\windows\sysnative\WindowsPowerShell\v1.0\powershell.exe -windowstyle hidden -executionpolicy bypass -command .\install.ps1
Process ID: 6384
PSVersion: 5.1.19041.1682
PSEdition: Desktop
PSCompatibleVersions: 1.0, 2.0, 3.0, 4.0, 5.0, 5.1.19041.1682
BuildVersion: 10.0.19041.1682
CLRVersion: 4.0.30319.42000
WSManStackVersion: 3.0
PSRemotingProtocolVersion: 2.3
SerializationVersion: 1.1.0.1
**********************
Transcript started, output file is C:\Program Files\_MEM\Log\KDE.Kdenlive-install.log
No applicable installer found; see logs for more details.
**********************
Windows PowerShell transcript end
End time: 20221117161758
**********************
Going to try with some others as well.
Thanks for the great work!
On Windows 11, we ran into some timeouts and also had trouble chasing winget.exe throughout the process.
Here's a PR that addresses these issues (and includes additional improvements): https://github.com/FlorianSLZ/scloud/pull/7
Thanks a lot for your contribution!
Just tested it and it works perfectly with the change.
Looks like that the ZIP file for the "Windows Package Manager" template, doesn't have the latest check.ps1 file. I replaced the file in the zip with the file in the repository and now it's working.
Thanks for the hint 🙂 It's updatet now.
Hallo,
eins vorweg: Super Seite und super Beitrag. Respekt dafür!
Generell verstehe ich den Artikel, es funktioniert soweit auch sofern winget auf er Maschine installiert ist. Jedoch scheitere ich bereits beim Verteilen des winget als Win32 App. Ich habe dabei deine Vorlage verwendet und deployed. Beim Client wird dies registriert und versucht auszuführe, jedoch schlägt die installation vom Windows Package Manager fehl. Leider sind die Fehler nicht gerade aussagekräftig. Ich habe versucht das install.ps1 direkt "auseinander" zu nehmen und am Client direkt auszuführen, leider keine Chance. Was mache ich falsch?
Es scheint als wenn der Download nicht ausgeführt wird und daher die App nicht installiert werden kann. Der Download selbst funktioniert manuell ohne Probleme.
Verzeichnis: C:\Program Files\_MEM\Data
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 24.11.2022 14:46 WindowsPackageManager
PS>TerminatingError(Add-AppxProvisionedPackage): "Element nicht gefunden.
"
C:\WINDOWS\IMECache\e8729d48-dba8-493f-9363-3c5f47e2629f_1\install.ps1 : Failed to install WindowsPackageManager!
In Zeile:1 Zeichen:1
Eine Idee? Danke für den Input! Grüsse Jan
Hallo Jan, vielen Dank 🙂
Leider habe ich aktuell dasselbe Problem. Wies aussieht ändert gerade nochmals etwas im Hintergrund.
Gestern wurde gerade eine neue Ankündigung zur weiteren Integration von Intune/Winget/Store veröffentlicht. Vielleicht ist dann der Package manager bald komplett integriert: https://youtu.be/QtftJQn9WYQ
Incredible, i am completely transformed now from choco to winget and it simple works!
Hello, could you please explain the difference between
%SystemRoot%\sysnative\WindowsPowerShell\v1.0\powershell.exe -windowstyle hidden -executionpolicy bypass -command .\install.ps1
and
Powershell.exe -executionpolicy bypass -file "install.ps1"
Without the %SystemRoot%\... the package runs in 32bit with that in 64.