Winget Failed to extract archive with code -2147417851

[maottsen]

Hey all,

I have a strange issue, not sure if anyone can help as it relates to Winget with SCCM.
I have this simple powershell script to install K9s for our clients:

        ## <Pre Installation>
        mkdir "$env:ProgramFiles\Kubernetes Tools\K9s"
		## <Perform Installation tasks here>
        $winGetPath = (Get-ChildItem -Recurse -Filter winget.exe -Path ($env:SystemDrive + "\Program Files\WindowsApps\") | Sort-Object LastWriteTime | Select-Object -Last 1).FullName
        & $winGetPath install --exact --id Derailed.k9s --silent --source winget --accept-package-agreements --accept-source-agreements --location "C:\Program Files\Kubernetes Tools\K9s"

		## <Perform Post-Installation tasks here>
        Copy-Item -Path "$PSScriptRoot\SupportFiles\K9s.check" -Destination "C:\Program Files\Kubernetes Tools\K9s" -Force

        # Editing file permissions
        $filePath = 'C:\Program Files\Kubernetes Tools\K9s\K9S.exe'
        # Adding read and execute rights to k9s.exe
        $rule = ':(RX)'
        icacls $filePath /grant Users$rule
        # Adding k9s to environment variables, so it can be triggered easily from cmd
        $k9sPath = 'C:\Program Files\Kubernetes Tools\K9s'
        $customVariableName = 'K9sPath'

This works as expected, when i test the script manually in SYSTEM user context.
If i run the script through SCCM and trigger it by Software Center it gets these errors:
2023-11-23 13:44:44.932 [FAIL] C:\__w\1\s\external\pkg\src\AppInstallerCommonCore\Archive.cpp(48)\WindowsPackageManager.dll!00007FFBABE51E62: (caller: 00007FFBABDCD8AC) ReturnHr(1) tid(13d8) 80010105 The server threw an exception. 2023-11-23 13:44:44.932 [CLI ] Failed to extract archive with code -2147417851 2023-11-23 13:44:44.932 [CLI ] Terminating context: 0x8a15005c at C:\__w\1\s\external\pkg\src\AppInstallerCLICore\Workflows\ArchiveFlow.cpp:42

I have no clue why this is, SCCM also uses the SYSTEM user to perform this action.
Any clue why this might be happening?

[florian-de]

@maottsen
I'm encountering the exact same issue when running WinGet installations as the System user in a Packer image build, and I've been stuck on this for quite a while. Have you found a solution? If so, I'd really appreciate it if you could share how you resolved it. Thanks in advance!

[denelon]

We've got a fix to use tar.exe for portable installs coming from the system context. The issue is in user context, we were calling shell APIs that only exist for a logged in user.