winget update --source winget shows different results called locally / remotely

[dteusner]

Hi,

I have written a powershell script that cycles through our servers, runs the command

winget update --source winget

to get a list of all programs for which an update is available on the current server and tries to install found updates. Since I run the script from a central server, I use the following Invoke-Command to run the above command on the remote server:

Invoke-Command -ComputerName current_servername -ScriptBlock {
	winget update --source winget 
}

This works fine so far, except that I get different results through Invoke-Command in comparison to running simply winget update --source winget directly on the remote machine.

I am at a loss as to why that is the case. It does not matter if I run the script in Powershell 5 or 7 as wells as an admin or not. Does anybody have a similar problem or even the same? And does anybody have an idea as to why that behaviour is happening?

Yours

David

"Example"
Run remotely (with invoke-command):

SearchName SearchId SearchVersion AvailableHeader

Cloud PBX 2.0 Cisco.Webex 43.11.0.27795 45.10.0.33234
Google Chrome Google.Chrome 141.0.7390.123 142.0.7444.60
AvailableUpgrades

Run locally:

SearchName SearchId SearchVersion AvailableHeader

Cloud PBX 2.0 Cisco.Webex 43.11.0.27795 45.10.0.33234
Google Chrome Google.Chrome 141.0.7390.123 142.0.7444.60
Greenshot 1.3.290 Greenshot.Greenshot 1.3.290 1.3.301
MSTeams Microsoft.Teams 25255.703.3978.7153 25275.2601.4002.2815
AvailableUpgrades

[Md. Mamun Or Rashid (MamunOrRashidIT)]

Hi dteusner, the missing apps are the clue: Greenshot and Teams only show up locally, while Webex and Chrome show up in both runs. Winget does not see one machine-wide list of installed apps — it sees the apps for the user/session it is running in.

Greenshot and Teams in your example are installed per-user, while Webex and Chrome are installed machine-wide. Invoke-Command runs winget in a non-interactive WinRM session, not in the logged-on user's interactive session, so it does not see that user's per-user installs (or that user's winget source cache). That is why admin vs. non-admin, and PowerShell 5 vs. 7, do not change the result.

You can confirm it by running this both locally and inside Invoke-Command, and comparing the output:

whoami
$env:USERNAME
winget --version
winget list --id Greenshot.Greenshot
winget list --id Microsoft.Teams
winget list --id Google.Chrome

To get the full list, run winget in the logged-on user's interactive session instead of through Invoke-Command. For example, use a scheduled task on the server set to "Run only when user is logged on" with that user's account, and run winget source update first in that session.

For servers, it is also worth installing shared apps machine-wide where possible, so any admin session can see and update them. Per-user apps will only be found and updated in that user's own session.

[dteusner]

Dear Md. Mamun Or Rashid (@MamunOrRashidIT) ,

thank you very much for your ellaborate answer. That explains quite a lot. We now have to reconsider how to approach this.

Yours David