WinGet

With Relution 5.26, it is possible to use the WinGet package manager → for app deployments on Windows devices.


Requirements

  1. The WinGet client must be installed on the device. It is available by default on all Windows 11 versions and on Windows 10 from version 2004 (May 2020 Update).
  2. The Microsoft Visual C++ Redistributable must be installed on the device, see Limitations →.
  3. Relution Server version 5.26 or higher
  4. Windows Companion version 1.11 or higher
  5. WinGet version 1.6 or higher

Supported Features

Before a broad rollout, each WinGet app should be tested on a test device.

The limitations → and known issues → sections contain more details.

  • Searching for and adding WinGet apps to the Relution AppStore
  • Deployment of WinGet apps via action, app compliance and auto deployments
  • Display of installed WinGet apps in the installed apps list of a device
  • Removal of WinGet apps via action
  • Automatic update of WinGet apps on the devices

Add WinGet apps to Relution AppStore

WinGet apps must be added to the Relution AppStore before they can be deployed on devices.

  1. Under Apps → App Store, the Add button opens the Add a new app dialog. Winget Store app is selected as the Source.

    Relution App Store showing WinGet app store selection option for Windows app deployment

  2. The WinGet app is searched for by name, selected and added to the Relution AppStore with Add details.

    Relution WinGet app search dialog for finding and adding apps to the Relution App Store

  3. Since WinGet manifests do not contain an icon, Relution uses the favicon of the publisher’s website as the app icon where possible. An existing icon, e.g. one uploaded manually, is not replaced. In the app details of a WinGet app, only the icon can be edited; all other fields are read automatically from the store.

The WinGet app details can contain additional information like installation scope, if it is provided for the WinGet app.

Relution WinGet app details showing installation scope and additional configuration information


Deploy WinGet apps

After the WinGet app has been added to the Relution AppStore and has a version in the status Release, it can be deployed to Windows devices.

Relution must install the WinGet app completely silently, see Limitations →. Due to this limitation all source and package agreements are automatically accepted when installing a WinGet app via Relution!

Deploy via action

In the action modal of a Windows device, Deploy Relution store app must be selected.

Relution Windows device action modal showing Deploy Relution Store app option for WinGet deployment

The WinGet app to be deployed is then searched for and selected.

Relution deploy action WinGet app selection list showing available apps to deploy

In the next step the deployment can optionally be adjusted. This is currently only possible for the deploy action and not for the app compliance or the auto deployments.

  • Installer type: Specifies the installer type to be used, see supported installer types →. The app must support the specified installer type or the install will fail.
  • Locale: Specifies the locale to be used (BCP47 format, at most 5 characters, e.g. en-US).
  • Timeout: Time in minutes (1 to 150) after which the Windows Companion aborts the installation. If the field is left empty, the App installation timeout from the Windows Companion → policy configuration applies.
  • Force the installation: Runs the command and continues with non security related issues.
  • Uninstall the previous version on upgrade: The previous version of the app is uninstalled on upgrade.
  • Skip upgrade: Skips the upgrade if the app is already installed.
  • Additional arguments: Passes the specified arguments on to the installer in addition to the defaults.

Uninstall the previous version on upgrade and Skip upgrade are mutually exclusive: enabling one of the two options disables the other.

Relution WinGet deploy action optional properties including installer type, locale and timeout settings

After the confirmation in the last step a deploy app action is created.

Deploy via app compliance

WinGet apps can be added to the App Compliance of a Windows policy.

Relution Windows policy App Compliance configuration showing WinGet app added to required apps list

Deploy via auto deployments

Winget apps can be added to the auto deployments of a user.

Relution user auto deployments settings showing WinGet app added for automatic installation


Remove WinGet apps via action

WinGet apps can be uninstalled from a device with the Remove app action. The WinGet apps contained in the Relution AppStore are available for selection.

The Windows Companion will execute the winget uninstall command silently, see Limitations →. Due to this limitation the source agreements are automatically accepted when removing a WinGet app from the device.

Relution Windows device action for removing a WinGet app silently from the device


Automatic update of WinGet apps on the devices

Relution will automatically update installed WinGet apps on the devices.

Requirements:

  • The WinGet app must be added to the Relution app store
  • The WinGet app must be contained in the installed apps list of the device

The Relution app store checks every day for each contained WinGet app, whether an update is available and refreshes the information of the app. When the Windows Companion refreshes the device details in Relution, Relution compares the version of the installed WinGet app with the version in the status Release in the Relution app store. Only entries of the installed apps list with WinGet as their source are taken into account. If it detects a newer version in the Relution app store, it triggers a deploy app action for this device and the app gets updated. As long as a deploy action for the app is still open on the device, no further action is created.

If the version comparison fails, the automatic update is not triggered (see Known issues →)


Limitations

The following restrictions generally apply to the use of WinGet apps in Relution.

Microsoft Visual C++ Redistributable must be installed

The Windows Companion executes WinGet commands in system context. This requires that the Microsoft Visual C++ Redistributable is installed on the device.

When the Windows Companion starts, it checks if this dependency is installed. If it is missing the Companion tries to download and install it. If it could not be installed, the Windows Companion writes a log entry into the event viewer on the device.

If this issue occurs, WinGet actions will fail. The error code -1073741515 of the failed action can be an indicator for this. In that case it is possible to install the latest Microsoft Visual C++ Redistributable → manually as a native app with a detection rule, see Known issues →

WinGet client must be installed on the device

Relution does not install the WinGet client. If the option Manage WinGet and its dependencies is enabled in the Windows Companion → policy configuration (default), the Windows Companion updates WinGet and its dependencies, such as the Microsoft Visual C++ Redistributable, when it starts. If the option is disabled, the Windows Companion does not update WinGet; it still installs a missing Microsoft Visual C++ Redistributable. The WinGet client is available by default on all Windows 11 versions and on Windows 10 from version 2004 (May 2020 Update). It is packaged in the AppInstaller, which can be installed from the Microsoft Store.

Only silent install and uninstall is supported

The WinGet app installation or uninstallation is executed by the Windows Companion. The Windows Companion is a background process, which cannot show any UI on the device. Therefore it will fail to install or remove the app, if it cannot be executed completely silent.

The Windows Companion will automatically add all possible commands to execute the install or uninstall silently:

winget install --silent --disable-interactivity --accept-package-agreements --accept-source-agreements
winget uninstall --silent --disable-interactivity --accept-source-agreements

But for some apps even those commands do not prevent the app from showing a dialog. One example is Mozilla Firefox during uninstallation.


Known issues

It is recommended to test the install and uninstall of each WinGet app on a test device before using it in production.

If the WinGet app should be used in an app compliance or in auto deployments, it must be contained in the installed apps list on the device after it has been installed and the device details have been refreshed.

If the automatic update of an installed WinGet app is important, the installed apps list must contain the app and have a correct value in the version column.

Some apps cannot be prevented from showing a dialog

If an app cannot be prevented from showing a dialog the install or uninstall will fail.

It may be possible to use a different installer in the deploy app action to work around this issue.

How to find out

  • PowerShell is opened as administrator on a test device
  • For the installation, the command winget install --id <id> --silent --disable-interactivity --accept-source-agreements --accept-package-agreements is executed, with <id> replaced by the WinGet ID of the app
    • If no dialog or prompt is shown, the app can be installed silently
    • Otherwise, another installer can be used by adding --installer-type <installer-type> to the command, if the app supports more than one.
  • For the uninstallation, winget uninstall --id <id> --silent --disable-interactivity --accept-source-agreements is executed
  • If no dialog or prompt is shown, the app can be removed silently

Alternative

If the app cannot be installed or uninstalled, using a native app with detection rules is recommended instead.

Some apps cannot be installed in system context

The WinGet client is currently not supported to be used in system context. But the Windows Companion runs in this context and therefore for some apps the installation might fail.

How to find out

  • On a test device, it is tested whether the app can be installed silently, see Known Issues →.
  • The app is removed from the test device again.
  • The same app is installed on the same test device via Relution.
  • If the installation fails, it might not be installable via system-context

Alternative

If the app cannot be installed or uninstalled, using a native app with detection rules is recommended instead.

Some apps are not shown in the installed apps list

Some apps are not shown in the installed apps list, although WinGet recognizes them as installed. These apps should not be used in an app compliance configuration or in auto deployments, because they can currently not be detected correctly and that would cause a lot of failing deploy actions.

How to find out

  • A WinGet app is installed on a test device
  • The device details are refreshed in Relution
  • The app should now be shown in the installed apps list

Alternative

If this issue occurs, using a native app with detection rules is recommended instead.

Some apps have wrong values in the installed apps list

Some detected WinGet apps have wrong values in the installed apps list, e.g. for the version. These apps can still be used in the app compliance configuration, but if the version is incorrect the automatic update might not work.

How to find out

  • A WinGet app is installed on a test device
  • The device details are refreshed in Relution
  • The app is shown in the installed apps list, but has wrong values in the columns

Alternative

If the automatic update of this app is not important, it can be used. Otherwise, using a native app with detection rules is recommended.

Duplicate detection of installed apps

If native apps with detection rules have been deployed on a device, the app might be shown twice in the installed apps list.

This does not mean that the app is installed twice.

It just means that the app is detected by the detection rule and by WinGet.

How to find out

  • An app with detection rule is installed on a test device
  • The device details are refreshed in Relution
  • The app is shown twice in the installed apps list. The name and other displayed information might differ slightly

Alternative

Currently there is no alternative for this behaviour. The duplicate entries can only be prevented, if the corresponding native app with detection rule is removed from Relution app store and the WinGet app is used instead.

Due to the limitations → and known issues → of WinGet apps it is not recommended to switch from native apps with detection rules to WinGet apps!

Missing dependency Microsoft Visual C++ Redistributable

As mentioned in limitations section → the dependency Microsoft Visual C++ Redistributable is required to be able to work with WinGet apps in Relution.

Therefore, the Windows Companion tries to install it on the device, if it is missing. This check is executed when the Windows Companion is started, e.g. after it is fresh installed or the device is rebooted.

It may happen that the automatic installation of the Microsoft Visual C++ Redistributable fails, which causes all WinGet commands to fail.

How to find out

  • A WinGet app is installed via Relution
  • The app is not installed on the device
  • The action is marked as failed and possibly contains the error code -1073741515

Alternative

The latest Microsoft Visual C++ Redistributable → can be manually installed as a native app with a detection rule.

  1. Downloading the .exe file for the architecture (x64, arm64, x86) of the device

  2. Adding a new native app

    • It is suggested to add the architecture in the app name to avoid confusion, e.g. VC Redist x64
    • Suggested install parameters: /install /quiet /norestart
    • Suggested uninstall parameters: /uninstall /quiet
    • Path to uninstaller: must be determined for each version and architecture, see below
    • Suggested detection rule:
      • Registry
      • Registry key: HKLM\SOFTWARE\Microsoft\VisualStudio\14.0\VC\Runtimes\{x64|x86|arm64}, see Microsoft documentation →
      • Registry value name: Version
      • Detection method: A value with the specified name exists
  3. Deploying the app on the devices with the same architecture

  4. The action should succeed

  5. Refreshing the device details

  6. The app should be contained in the installed apps list

How to detect the path to the uninstaller:

  • Opening the registry key: HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\
  • Searching for the key of the vc_redist.{x64|x86|arm64}.exe. The key is a product code, e.g. {2d48c97b-0c1e-4160-b3c4-c6dabebde745}
  • The path to the uninstaller can be found in the value: QuietUninstallString, e.g. C:\ProgramData\Package Cache\{2d48c97b-0c1e-4160-b3c4-c6dabebde745}\VC_redist.arm64.exe

WinGet upgrade fails with broken manifest

Some apps fail to upgrade with winget upgrade, even when a newer version is listed in the Relution app store. If the cause is a broken upstream manifest on the WinGet side, the upgrade command exits with one of the following error codes -1978335189 (no applicable upgrade), -1978335215 (package not found), -1978335192 (no applicable installer found), or -1978335216 (manifest / installer failure) and the app may still be installable via a script.

How to find out

  • The automatic update or a deploy action for the app fails
  • The failed action reports one of the error codes above

Alternative

The upgrade can be retried as a forced install via a Relution script, see WinGet Upgrade Workaround →.

Top