winget for Intune (and SCCM)

I’ve been trying to utilise winget via Intune for some time however the integration is difficult:

1. winget is seemingly designed to only run under a user context. If you try and run “winget.exe” in the SYSTEM context then you receive an error that the file does not exist. Meanwhile, the majority of software available in winget has a scope of “machine”, meaning local administrator rights are required to install the software. This is a massive showstopper in enterprise environments where users are not local administrators and so cannot install software.
2. winget is not PowerShell friendly. Trying to script any winget process means manually processing all output.
3. The way in which winget outputs text breaks typical ways of using PowerShell to capture output from a process. It is difficult to explain this one (ie: I don’t know the intricate implementation details of winget), however, I believe it is related to winget re-writing text to the same line instead of just outputting it in a standard way sequentially on new lines. The end result is deadlock issues in all of the solutions that others have written [which I’ve tested]. The way these deadlock issues manifest are not obvious and so you are left with a “sometimes it works, sometimes it doesn't” solution.
4. winget itself is not perfect. For example, at the time of writing, Visual Studio Code can be installed using the “-- id” parameter (ie: --id Microsoft.VisualStudioCode ) however trying to uninstall using its ID results in an error that the package is not installed. If you instead try to uninstall using the --name parameter then it will uninstall successfully.

I present my own implementation of a winget wrapper for use with Intune (and SCCM) which overcomes issues 1 to 3 above, and the ability to work around item 4: https://github.com/auash/IntuneWinget

Features

• winget can now run under either the SYSTEM or User context. Use winget to install software in enterprise environments where users are not local administrators.
• The mechanism I use to execute winget avoids the deadlock issues other solutions are susceptible to. The solution is robust and its behaviour is consistent.
• Ability to specify what proxy is utilised when running under the SYSTEM context (as the SYSTEM context doesn’t automatically receive the proxy settings applied to users in enterprise environments)
• Timeout support for the winget process
• Ability to target applications via Id or Name
• Support for all current and future winget parameters either directly (as parameters on this script) or through the -CustomArgs parameter

Usage

• Package the Manage-WingetApp.ps1 file into an .intunewin file using the Microsoft Win32 Content Prep Tool
• Workout the application ID (or name) you need to use, as well as if you will be installing under the SYSTEM or user context. To find out what context you can use, find your application here: https://github.com/microsoft/winget-pkgs/tree/master/manifests
  
  Locate the xxxxx.installer.yaml file for the application and look for the “Scope” line(s). For example, FileZilla can only be installed under the machine context. If your users don’t have local administrator rights, then you will have to install this software under the SYSTEM context:

• If the YAML file lists both a user scope and a machine scope, then you can choose which one to use. Your own organisational needs and desired user experience will influence this decision.
• Create a new Intune Application with the following configuration:
• Install command: %windir%\sysnative\WindowsPowershell\v1.0\powershell.exe -file Manage-WingetApp.ps1 -AppId “TimKosse.FileZilla.Client"
• Uninstall command:
  %windir%\sysnative\WindowsPowershell\v1.0\powershell.exe -file Manage-WingetApp.ps1 -AppId “TimKosse.FileZilla.Client" -Action Uninstall
• Set the “Install Behavior” toggle to match the YAML file option available/you want to use. The script will perform the application installation to match this toggle:

• All other Application configuration options should be configured like any other application.
• Regarding Detection Rules: I find it easiest to manually install the software via winget on a device first and work out a way to detect the software. Eg: MSI product code, file path, registry. Remember if you are expecting to do a SYSTEM install in Intune, then you must also do the manual install in the SYSTEM context (psexec helps)
• 2 log files are created each time the wrapper script is utilised. By default these logs are created in C:\ProgramData\Intune Winget Logs
  - One log file for the wrapper script and the output of the winget.exe (file name ends in - wrapper.log)
  - One log file for the application installation executable itself (file name ends in - installation.log)