How do you guys handle portable / binary deployments?

[SebastianK90]

Hi guys,

I just stumbled across this cool module.
I'm wondering, though, how you guys handle the deployment of portables or binaries, such as the following WinGet packages:
eksctl.eksctl
jqlang.jq
or even
Rclone.Rclone

When I run them, they always get placed in the system context, even when I’m specifically using the user context.

New-WtWingetPackage -PackageId 'ID' -PackageFolder "C:\temp\IntunePackages\" -EA 0 -InstallerContext User -PackageScript -Version latest

Do you have some tipps?

Cheers

[svrooij]

What is the problem with the system context regarding to these?

WinTuner does not support portable installers (yet, send a pr ;)??), so in this case you're using the "just run winget on the target machine" mode. This is like the fallback method, for unsupported things.

Can you add the intune logs (with the private data stripped), or the contents of the install.ps1 from the package? You can "decrypt" these packages using the Unprotect-IntuneWinPackage command. If i'm correct the context (if supported by that package) should be copied to the script as well.

[SebastianK90]

Thanks for the fast reply!
When I open the install.intunwin via the recommended Unprotect-IntunWinPackage command, after I did.
New-WtWingetPackage -PackageId 'eksctl.eksctl' -PackageFolder "C:\temp\IntunePackages" -EA 0 -InstallerContext User -PackageScript -Version latest

The line is still stating "machine"
$procOutput = & $(Get-WingetCmd) "install" "--id" "eksctl.eksctl" "--source" "winget" "--silent" "--accept-package-agreements" "--accept-source-agreements" "--scope" "machine"

Don't get me wrong the deployment does work somehow but it's deployed to a path, where normal non-admin users do not have access. like this one:
C:\Program Files\WinGet\Packages\eksctl.eksctl_Microsoft.Winget.Source_8wekyb3d8bbwe

It would be nice to have somekind of override parameter to just put those portable applications to something like C:\PortableApps\eksctl.eksctl