Skip to main content

Authorizing winget (Accepting Terms)


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


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).


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).

# Get the path to winget.exe
$winget = (Get-ChildItem -Path "C:\Program Files\WindowsApps\" -Filter "winget.exe" -Recurse | Sort-Object -Property LastWriteTime | Select-Object -Last 1).FullName

# Get the directory that winget.exe is inside of
$wingetdir = Split-Path -Path $winget -Parent

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

#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.exe list --accept-source-agreements | out-null
.\winget.exe -v

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

Winget Custom Field
FileWave Download.png

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.exe 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. For more information regarding the latest Microsoft redistribute. A fileset has been provided and discussed in Installing winget.