Unable to install Winget app using script

[kaspersmjohansen]

I am having som trouble installing Winget apps using your script. To simplify the process I am using the WinGet-WrapperImportFromCSV.ps1 script with the WinGet-WrapperImportFromCSV.csv file, which contains. I have made a minor change though, I have configured the UpdateOnly property to 0, as I want the VLC app installed, and not just updated.

The intinewin file is built and imported to my Intune tenant with no issues whatsoever.

On my test machine I can see the Intune pushing the app to the machine, but the app setup fails. Below are the contents of the log files generated on the machine:

VideoLAN.VLC_WinGet_Detection_2023-11-22_09-40-17: _[2023-11-22 09:40:17] WinGet-WrapperDetection v.3.5 [2023-11-22 09:40:17] https://github.com/SorenLundt/WinGet-Wrapper [2023-11-22 09:40:17] ** [2023-11-22 09:40:17] Host: WLS-6611 [2023-11-22 09:40:17] PackageName: VideoLAN.VLC [2023-11-22 09:40:17] TargetVersion: [2023-11-22 09:40:17] AcceptNewerVersion = True [2023-11-22 09:40:17] LogPath: C:\ProgramData\WinGet-WrapperLogs [2023-11-22 09:40:17] ** [2023-11-22 09:40:17] Running in System Context [2023-11-22 09:40:17] WinGet path: C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.21.3133.0_x64_8wekyb3d8bbwe\winget.exe [2023-11-22 09:40:18] WinGet version: [2023-11-22 09:40:19] Failed to get installed version: Cannot index into a null array. [2023-11-22 09:40:19] exit 1 - Report Not Installed

VideoLAN.VLC_WinGet_Wrapper_2023-11-22_09-40-21 _[2023-11-22 09:40:21] WinGet-Wrapper v.1.9 [2023-11-22 09:40:21] https://github.com/SorenLundt/WinGet-Wrapper [2023-11-22 09:40:21] ** [2023-11-22 09:40:21] Host: WLS-6611 [2023-11-22 09:40:21] PackageName: VideoLAN.VLC [2023-11-22 09:40:21] StopProcess: [2023-11-22 09:40:21] PreScript: [2023-11-22 09:40:21] PostScript: [2023-11-22 09:40:21] ArgumentList: install --exact --id VideoLAN.VLC --silent --accept-package-agreements --accept-source-agreements --scope Machine [2023-11-22 09:40:21] LogPath: C:\ProgramData\WinGet-WrapperLogs [2023-11-22 09:40:21] ** [2023-11-22 09:40:21] Running in System Context [2023-11-22 09:40:21] WinGet path: C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.21.3133.0_x648wekyb3d8bbwe\winget.exe [2023-11-22 09:40:21] Executing C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.21.3133.0_x648wekyb3d8bbwe\winget.exe install --exact --id VideoLAN.VLC --silent --accept-package-agreements --accept-source-agreements --scope Machine [2023-11-22 09:40:21] Script Finished_

VideoLAN.VLC_WinGet_Detection_2023-11-22_09-40-37 _[2023-11-22 09:40:37] WinGet-WrapperDetection v.3.5 [2023-11-22 09:40:37] https://github.com/SorenLundt/WinGet-Wrapper [2023-11-22 09:40:37] ** [2023-11-22 09:40:37] Host: WLS-6611 [2023-11-22 09:40:37] PackageName: VideoLAN.VLC [2023-11-22 09:40:37] TargetVersion: [2023-11-22 09:40:37] AcceptNewerVersion = True [2023-11-22 09:40:37] LogPath: C:\ProgramData\WinGet-WrapperLogs [2023-11-22 09:40:37] ** [2023-11-22 09:40:37] Running in System Context [2023-11-22 09:40:37] WinGet path: C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.21.3133.0_x64_8wekyb3d8bbwe\winget.exe [2023-11-22 09:40:38] WinGet version: [2023-11-22 09:40:39] Failed to get installed version: Cannot index into a null array. [2023-11-22 09:40:39] exit 1 - Report Not Installed

I am currently running tests on W11 23H2, but I have the same issue on a W10 22H2 machine.

Do you have any suggestions to what's going on?

[SorenLundt]

Hi Kasper, Seems that the machine cannot find the "WinGet Version"

See the log file is empty at [2023-11-22 09:40:38] WinGet version:

Usually should look like this [2023-11-22 08:39:05] WinGet version: 3.0.20

Could you try manually opening CMD as system account (psexec) on the target machine. Then run this:
cd C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.21.3133.0_x64__8wekyb3d8bbwe winget show --id VideoLAN.VLC --exact --accept-source-agreements winget list VideoLAN.VLC --exact --accept-source-agreements --scope Machine

Let me know what the output is. It seems to me that winget itself is having some issues on this client.

Curiously awaiting your response.

[kaspersmjohansen]

This is interesting

I have started a cmd.exe in system context, I have verified that it is indeed running in system using the whoami command.

When I go the the Winget folder and execute the winget.exe file nothing happens at all:

Currently spinning up a Windows 10 22H2 to verify. I'll be back (With a "Schwarzenegger voice" :) )

[kaspersmjohansen]

OK, so I tested the same thing in a Windows 10 machine same issue.

I have also tested on an Windows 11 machine, that is not enrolled in my Intune tenant, it's a basic workgroup joined Windows 11, same issue.

[kaspersmjohansen]

Have you seen this: https://github.com/microsoft/winget-cli/issues/3049

[SorenLundt]

OK, so I tested the same thing in a Windows 10 machine same issue.

I have also tested on an Windows 11 machine, that is not enrolled in my Intune tenant, it's a basic workgroup joined Windows 11, same issue.

That is strange. This is not the behaviour i see when executing winget.exe under system account. We have tested this on around 100 devices not showing the same issues.

Have you seen this: microsoft/winget-cli#3049

Interesting. Making it easier to run under SYSTEM and Microsoft recognizing its support for such operations simplifies things.

[kaspersmjohansen]

OK, so I tested the same thing in a Windows 10 machine same issue. I have also tested on an Windows 11 machine, that is not enrolled in my Intune tenant, it's a basic workgroup joined Windows 11, same issue.

That is strange. This is not the behaviour i see when executing winget.exe under system account. We have tested this on around 100 devices not showing the same issues.

Have you seen this: microsoft/winget-cli#3049

Interesting. Making it easier to run under SYSTEM and Microsoft recognizing its support for such operations simplifies things.

Yes I have seen that, it doesn't work either.

I have extended my tests to a vanilla Windows 11 23H2, no domain join, no Intune join only workgroup.Same thing.

I use PSexec to test winget in system context. I have found an older post here as well, which mentions issues with running winget in system context: https://github.com/microsoft/winget-cli/discussions/962

[SorenLundt]

OK, so I tested the same thing in a Windows 10 machine same issue. I have also tested on an Windows 11 machine, that is not enrolled in my Intune tenant, it's a basic workgroup joined Windows 11, same issue.

That is strange. This is not the behaviour i see when executing winget.exe under system account. We have tested this on around 100 devices not showing the same issues.

Have you seen this: microsoft/winget-cli#3049

Interesting. Making it easier to run under SYSTEM and Microsoft recognizing its support for such operations simplifies things.

Yes I have seen that, it doesn't work either.

I have extended my tests to a vanilla Windows 11 23H2, no domain join, no Intune join only workgroup.Same thing.

I use PSexec to test winget in system context. I have found an older post here as well, which mentions issues with running winget in system context: microsoft/winget-cli#962

https://github.com/microsoft/winget-cli/discussions/962. It seems that the issue referred to here is related with being able to run "winget" command directly without being in the correct filepath as system. This is handled in winget-wrapper by resolving the winget path, so this should not be the same issue.

Could you try running this below script?

$resolveWingetPath = Resolve-Path "C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_*_x64__8wekyb3d8bbwe"
Write-Host "$resolveWingetPath"
Set-Location $resolveWingetPath
Get-ChildItem -Filter *.exe

Here is my result executing the above on Windows 11 23H2 (22631.3007):

    Directory: C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.21.3482.0_x64__8wekyb3d8bbwe

Mode                 LastWriteTime         Length Name                                                                                                                     
----                 -------------         ------ ----                                                                                                                     
-a----        19-12-2023     08:35        2484736 AppInstaller.exe                                                                                                         
-a----        19-12-2023     08:35         292352 AppInstallerFullTrustAppServiceClient.exe                                                                                
-a----        19-12-2023     08:35         278528 AppInstallerPythonRedirector.exe                                                                                         
-a----        19-12-2023     08:35         563200 AuthenticationManager.exe                                                                                                
-a----        19-12-2023     08:35          46592 WindowsPackageManagerServer.exe                                                                                          
-a----        19-12-2023     08:35          12288 winget.exe                                                                                                               
WinGet info:
Windows Package Manager v1.6.3482
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.22631.3007
System Architecture: X64

Winget Directories                 
------------------------------------------------------------------------------------------------------
Logs                               %TEMP%\WinGet\defaultState
User Settings                      %LOCALAPPDATA%\Microsoft\WinGet\Settings\defaultState\settings.json
Portable Links Directory (User)    %LOCALAPPDATA%\Microsoft\WinGet\Links
Portable Links Directory (Machine) C:\Program Files\WinGet\Links
Portable Package Root (User)       %LOCALAPPDATA%\Microsoft\WinGet\Packages
Portable Package Root              C:\Program Files\WinGet\Packages
Portable Package Root (x86)        C:\Program Files (x86)\WinGet\Packages
Installer Downloads                %USERPROFILE%\Downloads

Links               
---------------------------------------------------------------------------
Privacy Statement   https://aka.ms/winget-privacy
License Agreement   https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage            https://aka.ms/winget
Windows Store Terms https://www.microsoft.com/en-us/storedocs/terms-of-sale

Admin Setting                             State
--------------------------------------------------
LocalManifestFiles                        Disabled
BypassCertificatePinningForMicrosoftStore Disabled
InstallerHashOverride                     Disabled
LocalArchiveMalwareScanOverride           Disabled
Current user:
nt authority\system

[kaspersmjohansen]

Your suggestion seems to work. Compared to what I have tested earlier, the Set-Location is new.

Is that already a part of your winget wrapper script?

[kaspersmjohansen]

I spoke too soon:

[SorenLundt]

Hi Kasper, Could you try to run the below code ? Planning to add this into code to ensure WinGet is installed.

#Check and install WinGet (Appx) if not installed
$appxPackageName = "Microsoft.DesktopAppInstaller"
$appxPackageURL = "https://github.com/microsoft/winget-cli/releases/latest/download/Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle"

if (-not (Get-AppxPackage $appxPackageName -ErrorAction SilentlyContinue)) {
    Write-Host "Appx package $appxPackageName not found. Downloading and installing the MSIXBundle package..."
    try {
        Invoke-WebRequest -Uri $appxPackageURL -OutFile "$env:TEMP\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle"
        Add-AppxPackage -Path "Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle" -ForceUpdateFromAnyVersion -ForceApplicationShutdown
        Write-Host "Installation complete."
    } catch {
        Write-Host "Failed to download or install $appxPackageName package: $_"
        Write-Host "$appxPackageName URL: $appxPackageURL"
        Write-host "exit 1"
    }
}
else 
{
    Write-Host "Appx package $appxPackageName found. Skipping installation."
}

[kaspersmjohansen]

End result is the same as before:

Remember I am executing this i SYSTEM context. It's working perfectly fine in both non-admin and admin context.

[SorenLundt]

Could you try to run it from ISE directly without saving to script file first ? Seems there is some issue in downloading the .msixbundle but the error does not show on your output.

[kaspersmjohansen]

Here is the script being run from ISE as SYSTEM

[JazzyStahh]

Hi,

I have the exact same issue, was a resolution found for this?

[kaspersmjohansen]

Hi,

I have the exact same issue, was a resolution found for this?

Hi Jazzy

I have not yet found a solution. It's a problem with winget itself, not this script from Soren. Even the Winget Powershell module has the issue. It's really too bad, because I really like Sorens approach with this, but as long as winget doesn't work in SYSTEM context, it's not a viable solution with Intune.

[InnovationForge-com]

From my experience Winget packages makes issues when you assign them to devices in Intune. Whenever winget runs before the first user logins, for example after Autopilot, then it's not possible to use Winget anymore in the user session due to an error. I had this issue with 3 customers until I found out how to avoid it.

Make sure to assign even the apps with System context only to users and not the devices. Then at least for me it always works. With the user ESP you can still configure that the apps that are assigned to users, are being installed at the fist login before the user can use the device.