Skip to content
Home » How to: winget & Intune

How to: winget & Intune

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?

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? (

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 "", 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.

Create win32 app

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
install command, win32 app, Intune

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

detection rule, script, Intune

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 search

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 - - Windows Tips & How-tos

Once you have found the appropriate folder, copy the path. You will only need this again in the next step.

Path of winget app

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.

Create win32 app

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.

Intune, App information
win32 app, install command

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.

script detection
Detection rule with script
File Detection
Detection rule with path

In the dependencies, select the "Windows Package Manager":

Dependency, Windows Package Manager

You don't have to define a supersedence rule and only assign the app at the end.

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.

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 command winget is not directly known in the system context, we must first navigate to the correct directory.
I do that in the Line 13 to 15.

$Path_WingetAll = Resolve-Path "C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_*_x64__8wekyb3d8bbwe" if($Path_WingetAll){$Path_Winget = $Path_WingetAll[-1].Path} cd $Path_Winget
Code language: PowerShell (powershell)

Afterward (line 17) 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 $param
Code language: PowerShell (powershell)

Finally, the transcript is ended again and the process is completed.

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) (

13 thoughts on “How to: winget & Intune”

  1. 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

    1. 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.

      1. 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
        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 ??

        1. 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*"){...}

  2. 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?

    Flo 🙂

      1. 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.

            1. 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.

    1. 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

    Leave a Reply

    Your email address will not be published.