Repository navigation
System Context #3049
Description
Description of the new feature / enhancement
This really shouldn't be moved to a discussion.
Not having the option to run winget in the System Context will essentially stop most organisations using winget. Zero Trust is a framework that more and more organisations will be adopting. Local admin rights is a dinosaur.
Some interesting stats with the winget-pkgs manifests, doing a search of InstallerType across the git repo show that msix is really a small component of what people are installing with the winget tool.
11940 results in 11134 files InstallerType: nullsoft (exe)
6318 results in 4855 files InstallerType: wix (msi)
5931 results in 5387 files InstallerType: inno
5664 results in 3754 files InstallerType: exe
2713 results in 1974 files InstallerType: msi
1004 results in 637 files InstallerType: burn (exe)
811 results in 688 files InstallerType: portable
448 results in 290 files InstallerType: msix
225 results in 217 files InstallerType: zip
Proposed technical implementation details
It's possible to run winget in the system context already, the sample code is below.
All I'm asking is for the winget-cli development team to recognise this, ensure this is a support method of running it, by simply taking this use case into consideration when developing winget further to ensure this type of usage does not break anything.
Possibly even ensure the system context executable is added to the machine PATH environment variable.
#region CODE
$winget = $null
$DesktopAppInstaller = "C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_*_x64__8wekyb3d8bbwe"
$SystemContext = Resolve-Path "$DesktopAppInstaller"
if ($SystemContext) { $SystemContext = $SystemContext[-1].Path }
$UserContext = Get-Command winget.exe -ErrorAction SilentlyContinue
if ($UserContext) { $winget = $UserContext.Source }
elseif (Test-Path "$SystemContext\AppInstallerCLI.exe") { $winget = "$SystemContext\AppInstallerCLI.exe" }
elseif (Test-Path "$SystemContext\winget.exe") { $winget = "$SystemContext\winget.exe" }
else { return $false }
if ($null -ne $winget) { $winget }
# Logs $(env:LOCALAPPDATA)\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir
& "$winget" install --id "7zip.7zip" --exact --silent --accept-source-agreements --accept-package-agreements | Out-String
#endregion
Activity
denelon commentedon Mar 6, 2023
We also know about "InstallShield" and "Squirrel" as .exe-based installers. Unfortunately, we don't have a good way to detect Squirrel, and we have separate issues for both of those. The existing breakdown of enumerated installer types helps WinGet default to standard switches for install modes. It's not a silver bullet, but it does help in many cases.
We are investing more in the area around running WinGet via the system context and the different scenarios around installers. We will be documenting both the "In-Process" and "Out-of-Process" interfaces to help both MDM providers, developers, and enterprise users.
I added the "Issue-Docs" label to cover the documentation aspect and have retained the "Issue-Feature" label to indicate other work we may need to do to make calling WinGet in the system context "easier / better".
denelon commentedon Mar 10, 2023
We're looking at having the PowerShell modules when run in System context to leverage the "In Process" COM APIs as a supported method to achieve the goal (from the above workaround).
I'd say it's not an officially supported workaround, but I'm not aware of anything that would break this any time soon. I certainly expect to have a fully supported method well in advance of anything changing.
If I hear of anything changing, I will certainly bring it up here as soon as possible.
apcsb commentedon Mar 10, 2023
[I understand that it's not currently supported, yet for info and discussion]
I have tried running WinGet (1.4.10173) in System context on a Win11 22H2 CloudPC machine. It produced very surprising and different results to my Win10 home PC
(For text search indexing: those are VCRUNTIME140.dll, MSVCP140.DLL, VCRUNTIME140_1.dll not found error messages)
I've got them by manually elevating into system context with nircmd.exe elevatecmd runassystem cmd.exe , then going to winget directory and running winget.exe
(nircmd is similar to psexec)
The %ERRORLEVEL% is -1073741515, which is the same as I was getting from the scripts I was trying to run in system context in the first place.
Again, I understand, that officially WinGet is not supported [hopefully, yet] in System context, just to draw awareness, that it behaves differently on different systems. While researching the error, I've found that the Windows Terminal app developers had a similar one (microsoft/terminal#11529) - maybe worth talking to that team...
Needless to say it runs perfectly well in user context.
Cheers
denelon commentedon Apr 5, 2023
Work in progress for PowerShell cmdlets running in system context:
nialljenIT365 commentedon May 14, 2023
Hi apcsb,
These messages are related the required entries not being in the SYSTEM PATH Variable.
For Winget current stable release (https://github.com/microsoft/winget-cli/releases/tag/v1.4.10173) you can add the following.
"C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.19.10173.0_x64__8wekyb3d8bbwe"
"C:\Program Files\WindowsApps\Microsoft.VCLibs.140.00.UWPDesktop_14.0.30704.0_x64__8wekyb3d8"
You still need to be aware of the health warning mentioned using Winget in the SYSTEM context depending on the types of applications you are attempting to deploy. Any well constructed msi with properly populated properties table and nothing wild in custom actions should be fine, EXEs and NULLSOFT your mileage may vary. APPX and MSIX should be user targeted and deployed in USER context.
denelon commentedon Jun 29, 2023
Hello all, we've published Microsoft.WinGet.Client with the ability to run WinGet in the system context. It does require running in PowerShell 7 with "-MTA".
If anyone can confirm, I'd like to close this issue.
We still have several package specific issues regarding whether the installer works correctly with the given manifest in system context, but the manifest has fields for scope to help in many of these cases.
apcsb commentedon Jun 30, 2023
But this is just a PowerShell module, right? What about WinGet.exe itself?
dzaggiel commentedon Feb 12, 2024
Getting error
to for me, getting error using psexec
Banthaf0dder commentedon Apr 9, 2024
I am a bit worried that the v7 with -MTA requirements makes this unusable for me and I suspect many others. EMM's such as Intune, Workspace ONE, etc. may not be designed to make use of Powershell 7 and may not be able to be set to execute scripts with the -MTA parameter within their scripting and application management offerings. Most of the point of running this under system context is so it can be used with these sort of EMM systems.
apcsb commentedon Apr 12, 2024
Banthaf0dder commentedon Apr 12, 2024
The scripting mechanisms in them all call on powershell.exe in C:\Windows\System32\WindowsPowerShell\v1. 0\ and there is no option to change that to anything else.
mdanish-kh commentedon Apr 13, 2024
[Policy] Context-System
HarmVeenstra commentedon May 1, 2025
I used the -MTA Parameter and the -Scope System to install apps in Intune running as SYSTEM, it finally works (For me) 👍
But not after a system reset, it starts working after running the cmdlets as SYSTEM (Using psexec -s -i cmd, pwsh), and then something happens, and it begins working. But not by default when using -Scope System and -MTA