Use WinGet to deploy, update (& secure?) Apps

At my current employer, we use Microsoft Intune to manage and white‑glove-deploy our Windows endpoints in a hybrid‑join environment. Until I joined, they relied on Chocolatey to deploy and update (some) applications. With the release and maturing of WinGet some time ago, it’s now a good replacement to start using it, together with a custom updater tool, to install most of the Apps, packages and software and keep it current, that even works on many of existing installed applications.

Preparations

First, we silently roll out WinGet (the Microsoft App Installer) to every endpoint. While Windows 11 comes with it preinstalled, we still ensure our Windows 10 machines have it by deploying the App Installer as a Modern Store app through Intune. You might wonder why we don’t just use the Modern Store for all our app deployments, unfortunately, not every application is available there, so WinGet fills in the gaps with the repository checked & scanned by Microsoft. And as a bonus you can even host and register your own repository :)

So we deploy the Microsoft App Installer (UWP Package ID: 9NBLGGH4NNS1)

Autoupdater

To keep every app up to date, you can either use a scheduled script that checks for and applies updates at regular intervals or deploy a third‑party tool with built‑in management features. We opted for Weatherlights’ fork (https://github.com/Weatherlights/Winget-AutoUpdate-Intune), since it integrates seamlessly with Intune and is by far the simplest, most straightforward solution to configure and maintain.

Begin by downloading the ADMX template just as you would when grabbing one for GPO, from the Weatherlights GitHub releases page (for example, https://github.com/Weatherlights/Winget-AutoUpdate-Intune/releases/tag/1.04.0012). Before deploying it, double check the repository for any newer versions of the ADMX so you’re always working with the latest settings.

Upload the ADMX in Intune:

And create a new policy by using the Imported templates:

Then tune your policies:

Save and assign to the users/devices you want to use with Winget-Auto-Updater

Next, we deploy the application itself by adding it as a Win32 preview Windows Store app in Intune (Win32 Package ID: XP89BSK82W9J28).

Deploying (and Redeploying existing) Apps

You can deploy WinGet apps in several ways, but we’ve identified two methods that are the simplest and most reliable for our environment. Your milage may vary.

When deploying in the SYSTEM context, Intune can’t resolve the WinGet executable path. To work around this, I use a PowerShell one‑liner that invokes WinGet via its full path as the install command. That makes it really easy to (auto) deploy apps at speed.

You might ask, “Why not just use a script?” Because this trick lets us swap out the install command on already‑deployed Win32 apps—switching from our old install.cmd (Chocolatey) to WinGet—without repacking or re‑uploading the .intunewin package. Not too bad for an non Microsoft-certified fart, right?

For new applications we just upload a blank.intunewin file containing an exit0, you might want to deploy smarter.

Commands:

install as SYSTEM

Install command:

powershell -Command "& (Get-Item 'C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_*_x64__8wekyb3d8bbwe\winget.exe').FullName install --id 'Microsoft.PowerShell' --silent --force --accept-package-agreements --accept-source-agreements --scope machine --exact"

Uninstall command:

powershell -Command "& (Get-Item 'C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_*_x64__8wekyb3d8bbwe\winget.exe').FullName uninstall --id 'Microsoft.PowerShell' --silent --force --scope machine --exact"

Install as USER

Install command:

winget install --id "Microsoft.PowerShell" --silent --force --accept-package-agreements --accept-source-agreements --scope user --exact

Uninstall command:

winget uninstall --id "Microsoft.PowerShell" --silent --force --scope user --exact

And an detection script that we found that works in any context:

# Define the App ID
$appId = "Microsoft.PowerShell" # change appId to the app you want to detect

# Attempt to resolve winget.exe location for system context
$wingetPath = Get-ChildItem -Path "C:\Program Files\WindowsApps\" -Filter "Microsoft.DesktopAppInstaller_*_x64__8wekyb3d8bbwe" -Directory |
    Sort-Object LastWriteTime -Descending |
    Select-Object -First 1 |
    ForEach-Object { Join-Path $_.FullName "winget.exe" }

# Exit with error if winget is not found
if (-not (Test-Path $wingetPath)) {
    Write-Error "winget.exe not found"
    exit 1
}

# Run winget list command using the app ID
$wingetOutput = & "$wingetPath" list --id $appId 2>&1

# Check if the app is listed as installed
if ($wingetOutput -match [regex]::Escape($appId)) {
    Write-Host "$appId is installed."
    exit 0
} else {
    Write-Host "$appId is NOT installed."
    exit 1
}

Finding Packages

To find the exact package names and IDs, we often use two web‑based GUI explorers:

https://winstall.app/ & https://winget.run/

Or check our own installed apps with the list command.

Automation?

You can easily automate the process to make it easier for your colleagues to deploy WinGet apps. For example, a small tool I wrote authenticates the user via Microsoft Graph, lets them enter the app ID, and then retrieves the metadata from the API. Or let’s them set it manually. It’s not nice enough to release it on GitHub yet, maybe one day. But for now it’s an internal tool.

Or just use powershell ;)

Results

Deploying first party Microsoft apps works amazingly well—persistent and consistent every time. Most other apps behave similarly, though redeploying can occasionally cause conflicts (nothing a simple remediation script can’t fix). Not having to hunt down & update installers, parameters, and detection rules saves a ton of time. Our first-line support can now easily install apps from a remote terminal. And the biggest bonus? WinGet updates apps that Windows Update doesn’t touch, reducing endpoint vulnerabilities from outdated software. Win win win—which is exactly why I wanted to share this.

Thanks for reading, proost!