Winget Extension

The Toolkit Extensions
1

In attempting to use the Winget Extension with 4.1.7, the script works perfectly when on my test system.

When deployed via Intune, I was getting nothing except immediate fail. After turning on system wide powershell transcription, I found error messages on launching the ToolKit that state that 'The term Find-ADTWinGetPackage is not recognized as the name of a cmdlet, function..blahblah.

I suspect this may be because I am using Find-ADTWinGetPackage early in the script, outside of the Install functions. The idea is this package can be used for multiple apps so is using that to get the app name for the variables. (When the vendor updates once, we dont need to rebuild 15 packages)

[CmdletBinding()]
param
(
    # Default is 'Install'.
    [Parameter(Mandatory = $false)]
    [ValidateSet('Install', 'Uninstall', 'Repair')]
    [System.String]$DeploymentType,

    # Default is 'Auto'. Don't hard-code this unless required.
    [Parameter(Mandatory = $false)]
    [ValidateSet('Auto', 'Interactive', 'NonInteractive', 'Silent')]
    [System.String]$DeployMode,

    [Parameter(Mandatory = $false)]
    [ValidateSet('JRE8x86', 'JRE8x64', 'JRE11', 'JDK11', 'JRE17', 'JDK17', 'JRE21', 'JDK21', 'IcedTea')]
    [System.String]$Product,

    [Parameter(Mandatory = $false)]
    [System.Management.Automation.SwitchParameter]$SuppressRebootPassThru,

    [Parameter(Mandatory = $false)]
    [System.Management.Automation.SwitchParameter]$TerminalServerMode,

    [Parameter(Mandatory = $false)]
    [System.Management.Automation.SwitchParameter]$DisableLogging
)

    # Product and Version Specification
    switch ($Product.ToLower()) {
        'JRE8x86'   {$wingetID = 'Azul.Zulu.8.JRE'; $wingetArch = 'x86'}
        'JRE8x64'   {$wingetID = 'Azul.Zulu.8.JRE'; $wingetArch = 'x64'}
        'JRE11'     {$wingetID = 'Azul.Zulu.11.JRE'; $wingetArch = 'x64'}
        'JDK11'     {$wingetID = 'Azul.Zulu.11.JDK'; $wingetArch = 'x64'}
        'JRE17'     {$wingetID = 'Azul.Zulu.17.JRE'; $wingetArch = 'x64'}
        'JDK17'     {$wingetID = 'Azul.Zulu.17.JDK'; $wingetArch = 'x64'}
        'JRE21'     {$wingetID = 'Azul.Zulu.21.JRE'; $wingetArch = 'x64'}
        'JDK21'     {$wingetID = 'Azul.Zulu.21.JDK'; $wingetArch = 'x64'}
        'IcedTea'   {$wingetID = 'Azul.IcedTea-Web'; $wingetArch = 'x64'}
        default {
            Write-ADTLogEntry -Message "Unknown Product $Product" -Severity Error
            End-Script -Exitcode 1
        }
    }
    $App = Find-ADTWinGetPackage -Query $wingetID | Select-Object Name, Version
    $appName= $App.Name
    $AppVersion = $App.Version

##================================================
## MARK: Variables
##================================================

# Zero-Config MSI support is provided when "AppName" is null or empty.
# By setting the "AppName" property, Zero-Config MSI will be disabled.
$adtSession = @{
    # App variables.
    AppVendor = 'Azul' 		# Who Makes the App
    AppName = $appName      		# App Name
    AppVersion = $appVersion     		# Version of the App
    AppArch = ''
    AppLang = 'EN'
    AppRevision = '01'
    AppSuccessExitCodes = @(0)
    AppRebootExitCodes = @(1641, 3010)

    AppProcessesToClose = @()           # Example: @('excel', @{ Name = 'winword'; Description = 'Microsoft Word' })
    AppScriptVersion = '1.0.0'          # How many times you wrote this
    AppScriptDate = '2025-11-06'        # When are we
    AppScriptAuthor = '<*********>'    # Who is You

    RequireAdmin = $true

    # Install Titles (Only set here to override defaults set by the toolkit).
    InstallName = ''   # This becomes the name of the log file - Spaces are stripped out. (This text + PSAppDeployToolkit_Install or Uninstall)
    InstallTitle = ''  # Shows as title of InstallationWelcome Popup Window if set.  Otherwise it is vendor + Name + Version from above.

    # Script variables.
    DeployAppScriptFriendlyName = $MyInvocation.MyCommand.Name
    DeployAppScriptParameters = $PSBoundParameters
    DeployAppScriptVersion = '4.1.7'
}

Is there a way around this, or am I just hosed on my plan? I prefer to leave this here instead of dropping it into the install routines as I can obtain the current version without moddifying the entire package every time.

The idea is that I could trigger an update on the systems in the environment for this application by simply modifying the detection registry key used for the update package.

2

If you need to call a function like Find-ADTWinGetPackage that early, you'll need to re-arrange the script so that the module(s) are imported ahead of time. Right now they're imported after all of that is defined, down the bottom of the script.

1 Like
4

So I got past this issue a while ago, but am having no end of trouble using this extension.

From attempts to install returning 'No Package found matching input criteria' when winget directly finds it without issue, to attempts to update not going through because more than one version is found and the 'All-Versions' flag not being supported as far as I can tell..

At this point I am still trying to use it to at least ensure that Winget is operable on the client, and then simply target the Winget exe specifically. Is there something in this that can let me get the currently installed path to the winget executable easily in this maybe?

I am finding on client systems that it ensures that Winget is up to date on the system, but if I call winget directly it is unable to find it, my assumption being that winget is installed under the user profile and the winget running in the system context cannot locate it.

5

So back on this..

Using winget.exe as a target in my PSADT Scripts, deployed via Intunes fails as Winget appears to be installed under the user contexts, and my package is operating under System context. So the response I get in the logs is 'The Term winget.exe is not recognised....'

However, when I run Install-ADTWinGetPackage the error I get in the log is 'No applicable installer found.'

Running the winget command directly on the client exactly as it is passed by the toolkit, I get the exact same message. However, if I run the command without the ' -scope Machine' flag that the toolkit is adding, it works properly.

My command in the script is:
Install-ADTWinGetPackage -Id $id -Mode Silent -Force -ErrorAction SilentlyContinue

What that translates to according to the log is:
winget.exe Install --id Microsoft.DotNet.DesktopRuntime.9 --scope Machine --force --log c:\ProgramData\Microsoft\IntuneManagementExtension\Logs\Microsoft_WindowsDesktopRuntime_9_EN_01_WinGet.Log --exact --silent --Accept-Source-Agreements --Accept-Package-agreements

How can i get the toolkit to run that same command, while omitting '--scope machine' so this package will work properly?

If I can target a manifest file with the toolkit commands, I was thinking I might be able to create a manifest file locally and have winget target that to manage the install, but that still leaves us in a spot where we need to regularly rebuild the package with every version update which is what I am trying to avoid by using Winget in the first place.

6

The enforced adding of --scope machine is mostly for safety so you don't install a user scoped app to the SYSTEM account.

I'll look at adding something to allow overriding of this default behaviour.