SorenLundt
Unable to install Winget app using script
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_x64__8wekyb3d8bbwe\winget.exe [2023-11-22 09:40:21] Executing C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.21.3133.0_x64__8wekyb3d8bbwe\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?
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.
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" :) )
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.
Have you seen this: https://github.com/microsoft/winget-cli/issues/3049
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.
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
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
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?
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."
}
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.
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.
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.
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.
