[Bug]: Issues when running as local system

PJMarcum commented 1 year ago

Describe the problem

I'm getting errors when trying to use this in local system context.

PS C:> get-WGReleaseNote Name : Windows Package Manager 1.3.2691 Version : v1.3.2691 Published : 10/4/2022 6:41:33 PM Prerelease : False Notes : This is the second stable release of the Windows Package Manager 1.3. This release is just for the sake of transparency for Windows Package Manager users. This ensures that the GitHub release is aligned with any changes related to AppInstaller. The changes associated with this release only affect AppInstaller. No additional features or bug fixes related to winget were included.
Experimental features are disabled in this release. Link : https://github.com/microsoft/winget-cli/releases/tag/v1.3.2691

PS C:> whoami nt authority\system

PS C:> Get-WGPackage -id github.cli C:\Program : The term 'C:\Program' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. At line:1 char:1

C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.18.2091. ...


+ CategoryInfo          : ObjectNotFound: (C:\Program:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException

PS C:> Install-Winget -Verbose VERBOSE: [12:17:20.8899057] Starting Install-WinGet VERBOSE: Installing Desktop App requirement VERBOSE: GET with 0-byte payload VERBOSE: received 6638831-byte response of content type application/octet-stream Add-AppxPackage : Deployment failed with HRESULT: 0x80073CF9, Install failed. Please contact your software vendor. (Exception from HRESULT: 0x80073CF9) Deployment Add operation rejected on package Microsoft.VCLibs.140.00.UWPDesktop_14.0.30704.0_x64__8wekyb3d8bbwe from: Microsoft.VCLibs.x64.14.00.Desktop.appx install request because the Local System account is not allowed to perform this operation. NOTE: For additional information, look for [ActivityId] 8c45cda6-dc00-0002-b98e-478c00dcd801 in the Event Log or use the command line Get-AppPackageLog -ActivityID 8c45cda6-dc00-0002-b98e-478c00dcd801 At C:\Program Files\WindowsPowerShell\Modules\WingetTools\1.6.0\functions\Install-Winget.ps1:31 char:17

Add-AppxPackage -Path $vclib -ErrorAction Stop


+ CategoryInfo          : WriteError: (C:\Windows\TEMP...00.Desktop.appx:String) [Add-AppxPackage], IOException
+ FullyQualifiedErrorId : DeploymentError,Microsoft.Windows.Appx.PackageManager.Commands.AddAppxPackageCommand

PS C:>

Expectation

No response

Additional Information

No response

PowerShell version

5.1

Platform

No response

Additional Checks

[X] You are using the latest version of this module.
[X] You have read this repository's README file.
[X] You have read full help and examples for the command you are having problems with.
[X] You are running PowerShell in an elevated session.
[X] You are running in a traditional PowerShell console or Windows Terminal

jdhitsolutions commented 1 year ago

Dealing with paths is problematic but not insurmountable. I don't think winget was ever designed with the idea that someone would run under the system context.

PJMarcum commented 1 year ago

Ah, I didn't know if the module was supposed to handle that or not. I don't remember who pointed me to this repository, but someone told me this should work as local system. As far as Winget not being designed to run in the system context I wonder how Microsoft plans to deal with this when they retire the Windows Store next year. I thought Winget was the way forward, but all deployment tools operate in the system context. Here's a function to get the path. I don't know how to use it with your module though.

Function Get-WinGetExePath {
    [CmdletBinding(SupportsShouldProcess)]
    param()

    $wingetCmd = Get-Command 'winget.exe' -ErrorAction Ignore
    if(($wingetCmd -ne $Null ) -And (test-path -Path "$($wingetCmd.Source)" -PathType Leaf)){
        $wingetApp = $wingetCmd.Source
        Write-Verbose "✅ Found winget.exe CMD [$wingetApp]"
        Return $wingetApp 
    }
    $wingetAppxPackage = Get-AppxPackage -Name "Microsoft.DesktopAppInstaller"
    if($wingetAppxPackage -ne $Null ){
        $wingetApp = Join-Path "$($wingetAppxPackage.InstallLocation)" "winget.exe"
        if (test-path -Path "$wingetApp" -PathType Leaf){
            Write-Verbose "✅ Found winget.exe APP PACKAGE PATH [$wingetApp]"
            Return $wingetApp    
        }
    }

    $wingetApp = Join-Path "C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.18.2091.0_x64__8wekyb3d8bbwe" "winget.exe"
    if(test-path $wingetApp){
        return $wingetApp
    }
    Throw "Could not locate winget.exe"
}

jdhitsolutions commented 1 year ago

I am using a function to get the path. I'm facing an additional hurdle in getting the path when using non-US cultures. This is definitely a nuisance problem.

PJMarcum commented 1 year ago

Gotcha, FWIW I am on US English devices.

danhicks852 commented 1 year ago

The C:\Program not found issue I was able to fix by modifying Get-WingetPath.ps1 line 10: $winget = (Get-ChildItem -Path "$env:ProgramFiles\WindowsApps" -Recurse -File | Where-Object { $_.name -like "AppInstallerCLI.exe" -or $_.name -like "WinGet.exe" } | Select-Object -ExpandProperty fullname).Replace('Program Files',"'Program Files'")

jdhitsolutions / WingetTools