Why does the powershell script "winget" doesn't work with BigFix?

Usage and Config
1

Hello all,

Well, I’ve been trying to update applications in Windows using “winget”, but I’m getting failed error -1 or error 1 everytime I try to run it with BigFix, but locally using powershell it works perfectly fine to upgrade like 99% of apps, upgradable through winget.

Here’s the script I’m using:

winget upgrade --recurse --all --accept-package-agreements --accept-source-agreements --silent --force --disable-interactivity

I’ve also used this one to make sure winget is installed:

# Ensure Winget is present (if needed, BigFix can deploy it)
if (!(Get-Command winget -ErrorAction SilentlyContinue)) {
   # Handle the case where Winget is not found (log, alert, etc.)
   Write-Error "Winget is not installed. Please install Winget for package management."
   exit 1  # Or a custom error code for BigFix 
}

# Upgrade all packages silently, forcing updates, and accepting license agreements
winget upgrade --all --silent --force --accept-package-agreements --accept-source-agreements

Nothing seems to work remotely using BigFix with Powershell Command.

Anyone knows the reason why some scripts works fine locally with powershell, but can’t run at all through bigfix?

2

Don’t forget that BigFix runs in the localsystem security context.

Microsoft Learn: winget Administrator considerations

See this tip for more information on using Action Override User settings.

1 Like
3

I understand, but I’m using pure PowersShell and not ActionScript that “calls” for a PowerShell file and then runs the code.

4

All scripts are run by the BigFix Client, whether it’s powershell or actionscript. The client runs in the LocalSystem security context, unless you use the action override user settings to change to another security context.

1 Like
5

Actually, never mind. I simply run

waithidden cmd.exe /c "winget upgrade --all --silent --force --accept-package-agreements -a x64"

And it worked flawless. Turns out I didn’t need to run it through powershell and BigFix ActionScript did the job well.

Thank you anyway for the insights.

4 Likes
6

That’s excellent news. Posting your solution will be helpful to others when they are searching ways to solve for similar issues.

2 Likes
7

I apologize I had this written out yesterday but I guess it never sent, i’ll go ahead and send it even though i believe you already switched to actionscript at this point. I’m not positive about why it wasn’t working in powershell but it could be that it’s running 32-bit powershell since the Bigfix client is 32bit.

We use winget quite a bit with Actionscript and it has worked pretty good without needing to involve powershell in the processing.

if {exists key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\winget.exe" whose (default value of it as string as lowercase starts with "c:\program files\windowsapps\microsoft.desktopappinstaller" as lowercase) of native registry}
	parameter "wingetPath" = "{default value of key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\winget.exe" of native registry}"
else
	parameter "wingetPath" = "{default value of key whose (name of it as lowercase is "winget.exe" and default value of it as string as lowercase starts with "c:\program files\windowsapps\microsoft.desktopappinstaller" as lowercase) of key "Software\Microsoft\Windows\CurrentVersion\App Paths" of current user key (logged on user) of native registry}"
endif


waithidden "{parameter "wingetPath"}" install Amazon.Corretto.11 --silent --accept-package-agreements --accept-source-agreements
3 Likes