Authorizing Winget (Accepting Terms)

What

Winget is a command line tool to manage applications on the Windows 10 and 11 platform.

When/Why

We'll use winget for all sorts of application management: installation, removal, upgrade, and even inventory.  But, before we can use winget for the first time on any device, we must accept terms (which will update from time to time if this service behaves as other licensing services).

How

Thankfully, we can authorize winget through PowerShell, and we don't have to do so manually.  To do a simple test, if we try winget -v to show the version of winget (or any other), we'll get a prompt that looks like this:

To avoid this, we need to include --accept-source-agreements (& --accept-package-agreements if an install command is used) on our first command to make sure it is authorized.  Placing this authorization in a custom field would be very efficient, as it would then be executed every day and always keep our devices up to date.  Note that we use winget list below (which lists installed applications, but any winget command here would do).

# because we run this from system account, we must define where winget is...the registry tells us
$winget_locale=Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\winget.exe" -Name Path -ErrorAction SilentlyContinue

# we change directory to this locale so we can run the winget command without the full path
cd $winget_locale.Path

#You must run a legit command to accept terms, but we don't really care about the output of this command, so we direct to null
./winget list --accept-source-agreements | out-null

#But, the version of winget in a custom field would be nice, so let's output that, which also serves to prove it is working
./winget -v

For convenience, you'll find the winget version  custom field here for import: Winget Version.customfields

There are three elements that are special about running winget from FileWave:

  1. When we run PowerShell scripts through FileWave, they run in the context of the system account.  The system account does not know about winget, so we must tell the FileWave client where it is. (Which will vary on each device)
  2. Once we have that location, we'll change directories to it, so that we can call winget, and...
  3. When you call an EXE from PowerShell in the current directory, you must precede it with a ./

Each of those elements you'll see documented above.


To test whether your script is working correctly, you may need to revert a device to "not accepting terms", which is easier than finding another test device.  You can revert a device with the following:

#revert a device to non-acceptance
winget source reset --force

Digging Deeper

You may find that on certain Windows versions that running winget through FileWave results in no output.  We have found that running winget through the system account (which FileWave does) is dependent on Visual C redistributable that are on the endpoint.  Deploying the latest redistributable from the following location should address this problem for you: https://docs.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170