How to deploy WinGet apps with Intune: 4 methods that work

When you want to deploy WinGet apps with Intune, it should be a straightforward process. After all, WinGet already knows the installer URL, version, and silent switches for thousands of Windows apps, so you should be able to point Intune at the catalog and deploy, right?

Well, there’s a catch. Intune has no app type that can deploy directly from the WinGet community repository, just apps from the Microsoft Store. To complicate matters further, the WinGet command-line tool isn’t supported when a script runs as SYSTEM, the context Intune uses when an app’s install behavior is set to System.

With that in mind, how can you deploy WinGet with Intune? We’ve identified four methods that can make deployment easier, so let’s review what they are, what each costs, how to set them up, and how to address any issues you may encounter.

Can Intune deploy WinGet apps natively?

Partly. Intune’s Microsoft Store app (new) type uses Windows Package Manager to find and install apps from the Microsoft Store. It can’t reach the WinGet community repository, the public catalog most WinGet guides use, and no Intune app type deploys from it. To deploy community repository apps, you need a script wrapper or a Win32 package.

That gap comes down to how WinGet is organized. It pulls apps from two main sources: the Microsoft Store (msstore) and the WinGet community repository on GitHub. Intune’s Store integration, which replaced the retired Microsoft Store for Business, connects only to the first.

You may also see Microsoft’s Enterprise App Catalog mentioned in Intune WinGet discussions. It’s a separate library of Win32 apps that Microsoft prepares and hosts, and Microsoft states that it doesn’t use WinGet. It also requires a subscription beyond Intune Plan 1 or Plan 2.

Four ways to use WinGet with Intune

If you want to deploy WinGet apps with Intune, there are still ways to do it. These are the four most common ways to use WinGet with Intune, including what they’re best for and their limitations:

Here’s how each method works, step by step.

Method 1: Deploy Microsoft Store apps with the Microsoft Store app (new) type

The first (and arguably easiest) way of deploying apps is through the Microsoft Store app. You can do this in a few quick steps:

1. In the Intune admin center, go to Apps → All Apps → Create, then pick Microsoft Store app (new) under Store app.

2. Select “Search the Microsoft Store app” and search for the app you want by name, publisher, or Store app ID. The results will show whether each app is Win32 or UWP.

3. Review the prefilled app information, set the Install behavior to System or User (note that some apps only support one), and set Company Portal options (such as featured app and category).

4. Assign the app as Required, Available for enrolled devices, or Uninstall, and set end user notifications, restart grace period, and installation deadline.

5. Review and create. Intune keeps the app updated as new versions appear.

With that said, there are some limitations and prerequisites you’ll want to keep in mind. These can complicate the process and may mean you’ll need to try a different method:

1. Devices need the Intune Management Extension, at least two processor cores, and network access to the Store and to the publisher's content.

2. Win32 apps in the Store are still in preview, and not every Win32 app is searchable. Similarly, paid apps and ARM64 installers aren't supported.

3. Win32 apps from the Store only stay updated while they remain assigned in Intune.

4. Entra-registered devices must use System install behavior (so User is not an option).

Method 2: Wrap a WinGet command in a Win32 app

If the Microsoft Store app won’t work for your needs, you can deploy WinGet via Intune by wrapping a WinGet command in a Win32 app. In these cases, a Win32 app is more reliable than a plain platform script because it includes status detection, return codes, and an uninstall command, which one-line script deployments lack.

Why WinGet fails when Intune runs as SYSTEM

When a Win32 app’s install behavior is set to System, Intune runs its install command as SYSTEM, and that’s where WinGet breaks. The WinGet CLI isn’t supported in the SYSTEM context because it ships inside App Installer, a packaged (MSIX) app registered per user. As a result, calling WinGet by name in a SYSTEM script typically fails because SYSTEM can’t locate it.

There are some workarounds. Community scripts typically address this issue by resolving winget.exe under C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_*_x64__8wekyb3d8bbwe, but this is not a method supported by Microsoft. The Microsoft-supported option is the Microsoft.WinGet.Client PowerShell module, which works in the system context for apps installed machine-wide.

Write the install script

To write the install script, you’ll want to find the package ID first, then install it by that exact ID from the community repository. You can look up the ID with winget search <app name>, or without the command line on winstall, Splashtop’s free WinGet catalog browser. Once you have the ID, the install command looks something like this: winget install --id Git.Git -e --source winget --silent --accept-package-agreements --accept-source-agreements

For SYSTEM installs, you’ll want to include --scope machine. Keep in mind that Microsoft warns that EXE installers don’t handle scope consistently.

For Microsoft Intune, the install command can be a PowerShell script up to 50 KB. Using powershell.exe in the command field launches 32-bit, while using the Sysnative path allows for 64-bit PowerShell.

Add a detection script

Be sure to add a script to detect and confirm when the app is properly installed. Intune counts the app as installed only when the script exits with code 0 and writes output to STDOUT; any STDERR output reads as not installed. The script typically checks the app’s install folder, file version, or uninstall registry key. If you check with winget list, that will hit the same SYSTEM problem, so it’s better to use file or registry checks.

Package the scripts and upload the Win32 app

Finally, wrap the scripts with the Microsoft Win32 Content Prep Tool to produce the .intunewin file. You can then add that file under Apps → All apps → Add → Windows app (Win32), set the install behavior to System, and add the uninstall command, detection script, and requirements. Use full paths in the uninstall command, since Intune doesn’t expand environment variables there.

Keep in mind that every app needs its own script set and updates, and WinGet must be present and working on each device it’s installed on. As such, this method can have a higher maintenance load than the others tend to.

Method 3: Keep WinGet apps updated with Intune Remediations

With Intune Remediations, you can pair a detection script with a remediation script. For WinGet, your detection script checks whether an installed app has a new version available; if so, the remediation script runs winget upgrade for that package ID. This works as an update method that pairs with Methods 2 and 4, but it doesn’t handle the initial installation.

Licensing comes first. Intune Remediations requires Windows Enterprise E3 or E5 (included in Microsoft 365 F3, E3, or E5) or Windows Education A3 or A5, and devices must be Intune-managed or co-managed and run Windows Enterprise, Professional, or Education.

To keep apps updated with Intune Remediations, just follow a few simple steps:

1. In the Intune admin center, go to Devices → Manage devices → Scripts and remediations.

2. Create a script package with a detection script that checks the package ID for an available upgrade.

3. Add a remediation script that runs the upgrade for that ID with --silent and both --accept flags.

4. Assign it to a device group and set a schedule to check for updates.

Make sure you target the specific package IDs you want to upgrade. While you can use winget upgrade --all, that will update every app WinGet recognizes, including ones IT hasn’t approved or tested. Also keep in mind that WinGet installs the latest version from the repository, so it may roll out updates before the IT team has a chance to test them. If the remediation script runs as SYSTEM, it hits the same WinGet limitation covered in Method 2.

Method 4: Package the installer as a native Win32 app

It’s also possible to repackage the installer as a native Win32 app. In this case, WinGet serves as a source of app information, rather than the app itself. By using the WinGet manifest to find the installer and its silent switches, you can deploy the installer as a standard Win32 app.

This means that devices can deploy the app without a working WinGet client, the SYSTEM context problem doesn’t apply, and you have access to Intune’s full Win32 features.

You can package the installer as a Win32 app in a few steps:

1. Find the package ID with winget search (or look it up on winstall) and review its manifest for the installer type, download URL, and silent switches. (WinGet requires every listed installer to support silent install.)

2. Download the installer with WinGet or from the vendor.

3. Confirm the silent install command for that installer type. Our guides to MSI silent installs and EXE silent installs cover the switches for each installer type.

4. Wrap the installer with the Microsoft Win32 Content Prep Tool to create the .intunewin file.

5. Add it as a Windows app (Win32), including install and uninstall commands, a detection rule (by MSI product code, file, or registry), requirements, and return codes.

6. Test how well the app installs, detects a completed installation, and uninstalls on a clean test device before rolling it out to more devices.

7. Whenever a new version is released, you’ll need to repeat the build and use supersedence to replace the old app.

This option provides the most customization and control for IT teams, although it also means they have to repeat the process for every app and update. As a result, teams with large app catalogs may struggle to keep up with the workload.

So, which method is the most effective? We can break them down and see when the tradeoff is worth it and when other methods are better.

WinGet vs Win32 app in Intune: which approach fits

The core choice is whether devices run WinGet at install time or receive a Win32 app you packaged ahead of time. Here’s how the two compare:

Comparing the options, we can see a few important details. For a handful of low-risk utilities, WinGet scripts can be fast and require less upfront effort. For business apps, regulated devices, or large catalogs, a packaged Win32 app is more reliable because it provides predictable versions and testing before rollouts.

If the app is listed in the Microsoft Store, Method 1 is usually the lightest option.

Common problems when deploying WinGet apps with Intune

Even with the right method, deploying WinGet apps with Intune has its challenges. IT teams may encounter common issues when deploying apps, but they can identify and address them.

Common problems include:

1. WinGet isn't recognized in an Intune script

If your script reports that winget isn’t recognized, the script is most likely running as SYSTEM, where the WinGet CLI isn’t supported because App Installer registers per user. This can be addressed by resolving winget.exe by its full path or by using the Microsoft.WinGet.Client PowerShell module, as mentioned in Method 2.

2. The app installs for the wrong user or in the wrong place

If the app installs in the wrong place or for the wrong user, that’s a matter of install scope. With SYSTEM, user scope resolves to SYSTEM’s own profile, while EXE installers handle user vs machine scope inconsistently. To fix this, use --scope machine for SYSTEM installs (make sure you test it first before rolling out the app more widely).

3. The download fails with a 403 Forbidden error

If the download returns a 403 Forbidden error, the software vendor may be blocking WinGet’s user agent on its download servers. If the installer downloads fine in a browser, that’s the likely cause. When that happens, you can download the installer directly and deploy it as a packaged Win32 app, as discussed in Method 4.

4. A Store app doesn't show up in Intune search

If a Store app doesn’t appear when you search for it, it could be for one of three reasons: 1. It’s not available in your region, 2. It’s a paid app, which means it’s not supported, or 3. Its platform isn’t supported. Regardless of the cause, start by confirming the app’s listing, and if it’s inaccessible, use Method 2 or 4 to install it.

5. A UWP Store app reports "not detected after installation" (0x87D1041C)

If you get this alert, it means a UWP app is assigned with System install behavior to a device that already has it. In this case, don’t worry; the app is still installed correctly. Microsoft also recommends not mixing user and system contexts for the same app.

6. Find out why a WinGet install failed

If a WinGet install failed and you’re not sure why, you can investigate to determine and address the cause. Adding --verbose-logs to the command gives you full logs, and you can run winget error <code> to translate an exit code into a description. Note that this covers WinGet, MSIX, and MSI codes, but many EXE installers can use non-standard codes. Our EXE silent install guide covers how to find those.

How Splashtop Agentic Packr turns WinGet apps into tested Intune packages

Deploying WinGet apps with Intune can be complicated, but it doesn’t have to be. With the right automation, teams can package installers quickly and efficiently without tying up IT resources.

That brings us to Splashtop Agentic Packr, an AI-powered application packaging and deployment tool for modern IT teams. Agentic Packr can package, validate, and deploy applications via Microsoft Intune, SCCM, and more, with far less manual effort.

Splashtop Agentic Packr provides several features and benefits, including:

1. WinGet as a source, with no WinGet client on devices

Splashtop Agentic Packr can package apps from a verified WinGet catalog, by WinGet or Chocolatey package ID, or from your own installers. It builds an Intune-native Win32 app, so you don’t need to worry about the WinGet and SYSTEM context problems users often encounter.

2. Detection rules written and tested before anything ships

When the AI-powered agent reads the installer, it writes detection rules and tests the build on a clean virtual machine. These tests check that install, detection, and uninstall work, run a malware scan, and produce a QA scorecard and logs that IT admins can review before the app reaches Intune and deploys across devices.

3. Publishing and new versions without manual rebuilds

Splashtop Agentic Packr removes the need to manually rebuild packages every time a new update comes out. With its one-click Express connection to the Intune tenant and automatic version updates, Agentic Packr detects new updates, packages them, tests them, and rolls out the updated package without admins needing to handle each update manually.

4. Control over what users see

Splashtop Agentic Packr gives IT control over how installs and updates appear to users. Teams can customize end-user notifications, deferrals, restart prompts, and grace periods, so required installs and updates are less likely to interrupt users mid-task.

Deploy WinGet apps to Intune without maintaining scripts

WinGet is a strong source of app information, and Intune is great for deploying apps, but Intune can’t deploy from the WinGet community repository directly. The method that scales is turning WinGet entries into tested Win32 packages.

With Splashtop Agentic Packr, you can build, test, and publish app packages with far less manual work. Agentic Packr makes packaging faster and easier, using a single console to package, deploy, and update apps while keeping admins in control.

Want to deploy WinGet apps with Intune without the hassle? See how Splashtop Agentic Packr can help you today.