Numerous Issues with WinGet

Brief description of your issue

Running WinGet in different security context than the actual logged on user results in strange behavior.
We could solve or at least workaround most of these issues but I thought I would post this A. for the dev team to maybe consider this for future updates and B. for the uncountable amount of other users facing similar issues.
This post actually tackles more than one issue.

Steps to reproduce

Situation 1: Running WinGet in an elevated Powershell / CMD window (e.g. logged on User has no Admin permission and you right click the Powershell with "run as administrator"
Situation 2: Running WinGet as NT-Authority\System with psexec or in our case TacticalRMM Powershell Scripts.

Expected behavior

Expected behavior would be for WinGet to either work as it does when ran from an logged on user security context or give exact error and troubleshooting steps on why it does not run as expected.

Actual behavior

Situation 1: WinGet may or may not run at all. If it does run it will not find Packages from the WinGet Source but only from MSStore Source.

Situation 2: WinGet does not put out any response whatsoever. Not even an error.

Environment

This happens in multiple Environments all running the latest winget version as of the posting date.
Most clients are running Windows 11 with some still on Windows 10 but all with the latest patch level.
What we are doing is automating SW deployment with TacticalRMM in combination with winget.
So we are running most of our Scripts as NT\System.

Here are some Solutions for the dev´s and community hope this helps someone out there:

WinGet is not installed or want run at all:
One or the combination of all the following commands fixed this for us...
# Install-Module -Name Microsoft.WinGet.Client -Force -Repository PSGallery | Out-Null
# Repair-WinGetPackageManager -Force -Latest
# Get-AppxPackage appInstaller | Reset-AppxPackage
# .\winget.exe source reset --force
# Add-AppxPackage -RegisterByFamilyName -MainPackage Microsoft.Winget.Source_8wekyb3d8bbwe

Winget does not find packages from sources other than MSSTORE (User context and elevated context)
Try the commands above and
# [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
# Install-PackageProvider -Name NuGet -Force | Out-Null

Winget does produce any output at all (also no errors).
For the NT\System Account to run WinGet you must first of all run it directly from its directory:
$WinGetLoc=(Get-Childitem -Path "C:\Program Files\WindowsApps" -Include winget.exe -Recurse -ErrorAction SilentlyContinue | Select-Object -Last 1 | %{$_.FullName} | Split-Path)
cd $WinGetLoc
.\winget.exe

Also if this still does not provide any output check if VC Redist (Visual C++ Redistributable) is installed on your machines and if not install it.
# Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://vcredist.com/install.ps1'))


With the commands above and / or the combination of them we were able to solve all our WinGet issues.
Please keep in mind that I am no PowerShell / WinGet pro and that I have no idea what I am doing for the most part... All of this is copied from somewhere at the internet and put together in questionable ways by me and my colleagues. So use this at your own risk.
Have a nice day!

No source files or tests are named. Start by reproducing both elevated-user and NT AUTHORITY\SYSTEM cases with winget.exe, comparing source discovery, output, and errors; done means each context either works consistently or reports an exact actionable failure.