Using WinGet with Intune

System administrators familiar with the Linux platform understand different package managers like APT (Advanced Packaging Tool) and RPM (Red Hat Package Manager). These package managers are convenient for administrators. They maintain a list of trusted repositories, and administrators use the tool to compare installed apps against the published version. If they find any version update, they install it with the command-line tool included in the package. System administrators always use these packaging tools to download, install, or update application packages on the Linux platform. Microsoft created WinGet (Windows Package Manager) as the Windows version of the package manager. This article will focus on how to leverage WinGet in Intune and how to control WinGet.

Quick Overview of WinGet

WinGet works similarly to its Linux counterparts, which help deploy and maintain applications installed on devices against a trusted repository of app metadata. Microsoft maintains the community repository that WinGet leverages. Application developers, like Adobe, for example, still need to submit the package information there. If you are a developer, you can go to https://github.com/microsoft/winget-pkgs to learn more about the submission process or maintain packages.

Once a package’s metadata is published on the repository, the WinGet client, usually using the `winget` command, can then extract the installed app information from your device to compare against the metadata on the repository. The WinGet client then compiles a list of apps that need updating. You can also use WinGet to deploy applications with a single command. If you want to know more about how WinGet works, you can visit this page or their official GitHub repo.

Installing and maintaining applications using a package manager is a very familiar process in the Linux world, but it’s something new to the Windows world. Microsoft developed WinGet as a replacement for the Microsoft Store for Business when its retirement was announced. However, some administrators still do not fully embrace the new solution. We will explain some of the limitations after we discuss how to use WinGet from an endpoint administrator’s standpoint.

Deploying WinGet with Intune

WinGet is available as a command-line tool, which you might think we can simply get Intune to run, right? Unfortunately, that is not the case. We must first install WinGet onto your device. You can either install it via the Microsoft Store or go to the WinGet GitHub repo and download the latest package files. When you download the packages from the GitHub release page, make sure you download both the .msixbundle file and the dependencies.zip file, as shown in Figure 1. You will need both during the next step.

After that, upload the .msixbundle file to Intune as a Line-of-Business app to distribute it as a normal Windows app, as shown in Figure 2.

You will need to add the required dependencies as part of the package before saving. These dependencies are available inside the dependencies.zip file you downloaded from the GitHub Release page. After adding the app to Intune, you can assign it to devices just like other applications, by deploying the package to the device context instead of the user during assignment, as Figure 3 illustrates.

Note that since we are deploying packages manually rather than using the Microsoft Store, we will need to update them periodically to ensure they are current. You can do this by downloading the latest package files from the GitHub repo and then editing the existing app in Intune.

Using WinGet with Intune

Once all packages are deployed, we can then start to leverage WinGet to manage applications on the devices. Let’s begin with the easy task: using WinGet to update installed applications on the endpoint. We will need to prepare a PowerShell script and run the script using the Platform Script feature in Intune. In the example below, we will update all installed applications that have manifest files in the Windows Package Manager Community Repository by using winget.exe, which is the command-line interface (CLI) for most of the WinGet operations (Figure 4). To learn more about using custom scripts in Intune, you can refer to my previous article.

$winget_path = Resolve-Path "C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_*_*__8wekyb3d8bbwe\winget.exe"
if ($winget_path.count -gt 1) {
    $winget_path = $winget_path[-1].Path
}
# check exe and functionality
if ($winget_path) {
    if (& $winget_path -v) {
        echo $winget_path
        & "$winget_path" --info
        # Update source
        & "$winget_path" source update
        # Run the upgrade command
        & "$winget_path" upgrade --all --silent --accept-source-agreements
    }
}
exit 0

I created the script above, referring to a similar script by another MVP Florian Salzmann and his work posted on GitHub. I will also refer to some of Florian’s work later in this article. I want to highlight that we cannot simply call winget.exe because the install folder is not always a shared path (i.e., user context), which may vary from device to device. Therefore, we need to find winget.exe and then call it.

Deploying Apps with WinGet and Intune

Deploying applications using WinGet presents some complexities. You might wonder why we don’t just create a script similar to the update script, modifying it to run a command like winget install –id Microsoft.PowerShell –source winget when deploying PowerShell 7 to all Intune-managed endpoints.

While this approach works, it sacrifices several capabilities provided by Intune. The key lost capabilities include:

• Tracking installation status: This issue is similar to running a script, where delays in update status are often acceptable. However, for application installations,a reliable method to confirm correct app installation is usually necessary. Using a one-line command or a simple install script like this may not provide that reliability, as the script doesn’t collect actual installation results and send feedback to Intune correctly.
• Uninstall capability: A separate script would be required for uninstallation, leading to administrative overhead and risk of not completely uninstalling the applications.

To deploy applications using WinGet, I recommend using a Win32 app package (.intunepkg file) and creating install, detect, and uninstall scripts. This may sound complicated, but thanks to Florian, a template package is already available in his Github repo, along with detailed guidance on how to use it in his blog post. In essence, you will need to download and modify his script, adding the application ID. Then, you will use a different Intune feature to run the script. His package already includes a detection script that you can use to confirm correct app installation and report the status back to Intune.

For example, we will need to modify the value of the ProgramName variable as illustrated in Figure 5.

Identify the program name by running the command winget search or checking the online documentation of the package you want to install.

Controlling WinGet

To better control WinGet’s behavior and enhance its security, I recommend deploying WinGet policies to endpoints using Intune or GPO. If you decide to use GPO, you may need to go to WinGet’s release page to download the latest policy package, which includes the latest ADMX files. You can then copy these to your AD and deploy them the same way as other GPOs. If you are using Intune, you can create a configuration profile using the Intune settings catalog. In the settings picker, navigate to Administrative Templates > Windows Components > Desktop App Installer (note, it’s not called WinGet in the policy configuration screen) as illustrated in Figure 6.

I recommend deploying the following policy to ensure security when using WinGet.

1. Set App Installer Source Auto Update Interval In Minutes – This setting controls the time in minutes that WinGet releases its local package cache to improve performance checks.
2. Enable App Installer Default Source – This makes the default repository location available and prevents users from removing it.
3. Enable App Installer Allowed Sources – This controls the list of repositories WinGet is allowed to check against.
4. Enable App Installer – This controls whether WinGet is enabled.

You can refer to this CSP (Configuration Service Provider) documentation page for detailed configurations and other settings that you can deploy via Intune Configuration Profile.

WinGet is Good, but Not Without its Issues

Using WinGet with Intune is already streamlined a lot compared to the early days. However, WinGet itself comes with a few issues:

1. The package repository does not yet have the ability to mark the publisher as verified. This could be a security risk along the way, as a risky package could be downloaded via the repository.
2. Integration with Intune is still half-baked, which requires using a script or some tricks to get things working.

Yet, WinGet is still one of the best ways to force update Microsoft’s and some third-party vendors’ apps to the latest version without using any third-party apps or services. Other, more integrated and better coverage approaches require subscriptions, such as Windows AutoPatch or PatchMyPC’s services. But using WinGet together with Intune is a good start if an organization has a limited set of apps and most of them are covered by WinGet’s community repos.