System Context

[cgerke]

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

[denelon]

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]

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]

[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]

Work in progress for PowerShell cmdlets running in system context:

• Use in-proc winget in PowerShell module when running as SYSTEM #3129

[nialljenIT365]

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]

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]

But this is just a PowerShell module, right? What about WinGet.exe itself?