Intune Deploy - AppID not found

[jaredonair]

I have been trying to make the winget-install script run with Intune. I can verify it's deploying, but according to the log file it's not finding the app. If I run the command from powershell, it works fine.

"%systemroot%\sysnative\WindowsPowerShell\v1.0\powershell.exe" -NoProfile -ExecutionPolicy Bypass -File winget-install.ps1 -AppIDs "Notepad++.Notepad++" -LogPath "C:\temp\logs"

LOG:

08:13:58 - ### 11/8/2022 - NEW INSTALL REQUEST ###
08:13:58 - Using following Winget Cmd: C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.18.2691.0_arm64__8wekyb3d8bbwe\winget.exe

08:13:58 - Start 7zip.7zip processing...
08:13:58 - -> Notepad++.Notepad++ does not exist on Winget Repository! Check spelling.
08:13:58 - Notepad++.Notepad++ processing finished!

08:13:59 - ### END REQUEST ###

Any ideas what I am doing wrong?

[KnifMelti]

-AppIDs "Notepad++.Notepad++" should be -AppIDs Notepad++.Notepad++ (no "fnutts")

[KnifMelti]

@Romanitho is this description really right:
https://github.com/Romanitho/Winget-Install#multiple-apps-at-once :
-AppIDs "7zip.7zip, Notepad++.Notepad++" (note the "fnutts" and the space...)
when the code examle is: -AppIDs 7zip.7zip,notepad++.notepad++

[KnifMelti]

And, I see you're using an ARM (_arm64__), then the correct detection is in the now open PR #66
If you can't wait, change in winget-detect.ps1 to:
$ResolveWingetPath = Resolve-Path "$env:ProgramFiles\WindowsApps\Microsoft.DesktopAppInstaller_*_*__8wekyb3d8bbwe" | Sort-Object { [version]($_.Path -replace '^[^\d]+_((\d+\.)*\d+)_.*', '$1') }

[axelv83]

I am running powershell -ExecutionPolicy bypass -File winget-install.ps1 -AppIDs Google.Chrome -LogPath "C:\temp\logs"

I have the same issue "APP does not exist on Winget Repository! Check spelling."
From what I saw in the powershell script, somehow the variable $WingetApp is empty when running $WingetApp = & $winget show --Id $AppID -e --accept-source-agreements | Out-String
And further on if:
if ($WingetApp -match [regex]::Escape($AppID))
it will return False every time.
This is happening when running from Workspace One. If i run locally its working.

Log:

06:33:21 - ### 12/20/2022 - NEW INSTALL REQUEST ###
06:33:21 - -> WingetPath >> C:\Program Files\WindowsApps\microsoft.desktopappinstaller_1.18.2691.0_x64__8wekyb3d8bbwe.

06:33:22 - Start Google.Chrome processing...
06:33:22 - Confirm-Exist:> Using following Winget Cmd: C:\Program Files\WindowsApps\microsoft.desktopappinstaller_1.18.2691.0_x64__8wekyb3d8bbwe\winget.exe

06:33:22 - Confirm-Exist:> The result for comparison is False

06:33:22 - -> Google.Chrome does not exist on Winget Repository! Check spelling.
06:33:22 - Google.Chrome processing finished!

06:33:23 - ### END REQUEST ###

[KnifMelti]

A correct execution results in following log start (with powershell -NoProfile -ExecutionPolicy bypass -File C:\virtualtest\winget-install.ps1 -AppIDs Google.Chrome -LogPath "C:\temp\logs" - in my test environment):

18:24:27 - ###   12/22/2022 - NEW INSTALL REQUEST   ###
18:24:30 - Using following Winget Cmd: C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.18.2691.0_x64__8wekyb3d8bbwe\winget.exe

18:24:30 - Start Google.Chrome processing...
18:24:33 - -> Google.Chrome exists on Winget Repository.
18:24:34 - -> Installing Google.Chrome...
18:24:34 - -> Running: "C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.18.2691.0_x64__8wekyb3d8bbwe\winget.exe" install --id Google.Chrome -e --accept-package-agreements --accept-source-agreements -h 

A failed find (does not exist on Winget Repository) should look like this:

18:34:21 - ###   12/22/2022 - NEW INSTALL REQUEST   ###
18:34:22 - Using following Winget Cmd: C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.18.2691.0_x64__8wekyb3d8bbwe\winget.exe

18:34:22 - Start Google.Chrome processing...
18:34:23 - -> Google.Chrome does not exist on Winget Repository! Check spelling.

In your failed log there's WingetPath >>/Confirm-Exist:>, is the script edited by you?
Do you have the latest scripts?

[KnifMelti]

Other than that I don't think I can be of any more help.
It works locally for you, but in Workspace One it doesn't; maybe the Workspace One community knows exactly why?

[axelv83]

Yes, i have the latest scripts, and i added some output to check where it crash.
From Workspace One the script are deployed as an App and the archive gets to the client where is executed, but this command somehow doesn't work $WingetApp = & $winget show --Id $AppID -e --accept-source-agreements | Out-String
I will investigate more.

[KnifMelti]

Yes, very odd...
That command is (as you know) just a winget command to show information about the $AppID (Google.Chrome) and putting the result in a variable for later testing if ($WingetApp -match [regex]::Escape($AppID)):

Found Google Chrome [Google.Chrome]
Version: 108.0.5359.125
Publisher: Google LLC
Publisher Url: https://www.google.com/
Publisher Support Url: https://support.google.com/?hl=en
Author: Google LLC
Description: A more simple, secure, and faster web browser than ever, with Google’s smarts built-in.
Homepage: https://www.google.com/intl/en_us/chrome/
License: Freeware
License Url: https://www.google.com/intl/en_us/chrome/terms/
Privacy Url: https://policies.google.com/privacy?hl=en
Copyright: Copyright 2022 Google LLC. All rights reserved.
Installer:
  Type: wix
  Download Url: https://dl.google.com/dl/chrome/install/googlechromestandaloneenterprise64.msi
  SHA256: 91411a41f74b03dd135d466a1cb9dc1b9bc58fa6c0ee311ede5717daf86863bd
  Release Date: 2022-12-13

[KnifMelti]

Another odd thing is that in your logs the winget.exe directory under C:\Program Files\WindowsApps is all in lower case:
microsoft.desktopappinstaller_1.18.2691.0_x64__8wekyb3d8bbwe
That directory on all our clients is:
Microsoft.DesktopAppInstaller_1.18.2691.0_x64__8wekyb3d8bbwe

The behavior you're describing is like winget.exe is in the file system, but it's not executing correctly; hence the empty variable resulting in Google.Chrome does not exist on Winget Repository! Check spelling.

I get exactly the same result if I in the code replace the Path to winget.exe with another Path (and a dummy exe)...
...is locally a run from one of the clients that fails under Workspace One or is it locally on your own client (in System context - https://www.nirsoft.net/utils/advanced_run.html)?