[Feature Request]: `winget-install.ps1` handling for user context when called from system e.g. via Intune

[ITistheworst]

The request

Some apps only function correctly if installed in user context, if you try and deploy these using winget-install.ps1, via Intune for example, you run into issues. You can get Intune to run winget-install.ps1 in the logged-in user context however this causes problems e.g.

• Visible powershell window while the installer runs
• Unable to update the log file
• Unable to add apps to the whitelist
• etc.

Could user-scope installs be handled in winget-install.ps1 similar to how the updater handles it? Allowing winget-install.ps1 to be called from system context with an additional parameter to run the actual install as user and hidden, maintaining ability to update logs and lists.

Is your feature request related to a problem?

Additional information

Here is an example of the visible PS window when running from MDM as user:

[KnifMelti]

function Add-WAUWhiteList ($AppID) and function Remove-WAUWhiteList ($AppID) was not ment to handle user installs.

It was a way to add manually installed applications via winget-install.ps1 to the WhiteList if you didn't have a centralized management of the list.
Don't use -WAUWhiteList (manage the list instead!)
The log file for installs in user context via winget-install.ps1 is created under C:\Users\%USERNAME%\AppData\Roaming\Winget-AutoUpdate\Logs

For no visibility you could use:

SCCM:

• C:\Windows\System32\conhost.exe --headless powershell.exe -NoProfile -ExecutionPolicy Bypass -File "C:\Program Files\Winget-AutoUpdate\Winget-Install.ps1" -AppIDs Postman.Postman
• C:\Windows\System32\conhost.exe --headless powershell.exe -NoProfile -ExecutionPolicy Bypass -File "C:\Program Files\Winget-AutoUpdate\Winget-Install.ps1" -AppIDs Postman.Postman -Uninstall

Intune (%systemroot%\sysnative to make it 64-bit):

• C:\Windows\System32\conhost.exe --headless "%systemroot%\sysnative\WindowsPowerShell\v1.0\powershell.exe" -NoProfile ExecutionPolicy Bypass -File "C:\Program Files\Winget-AutoUpdate\Winget-Install.ps1" -AppIDs Postman.Postman
• C:\Windows\System32\conhost.exe --headless "%systemroot%\sysnative\WindowsPowerShell\v1.0\powershell.exe" -NoProfile ExecutionPolicy Bypass -File "C:\Program Files\Winget-AutoUpdate\Winget-Install.ps1" -AppIDs Postman.Postman -Uninstall

[ITistheworst]

I can't get that conhost.exe trick to work, it just seems to fail to execute. These are my exact commands that I have configured (I also tried exactly as you have correcting only the minor typo of missing - before ExecutionPolicy):

• "%systemroot%\System32\conhost.exe" --headless "%systemroot%\sysnative\WindowsPowerShell\v1.0\powershell.exe" -NoProfile -ExecutionPolicy Bypass -File "%ProgramW6432%\Winget-AutoUpdate\winget-install.ps1" -AppIDs "Postman.Postman" -AllowUpgrade
• "%systemroot%\System32\conhost.exe" --headless "%systemroot%\sysnative\WindowsPowerShell\v1.0\powershell.exe" -NoProfile -ExecutionPolicy Bypass -File "%ProgramW6432%\Winget-AutoUpdate\winget-install.ps1" -AppIDs "Postman.Postman" -Uninstall

Looking at the log it just seems to fail to create process with this command

[Win32App] Failed to create installer process. Error code = 2

It does look like it is just the whitelist adding that is failing, which does align. For some reason I thought the logging had been moved into the main log a while back.

I appreciate that there are other ways to manage the whitelist but the installer time adding of entries is very useful in environments when you need to have some flexiblity to update ad-hoc and in test environments. It can also be a useful indicator that winget-install.ps1 was the install source for an application.

[KnifMelti]

I can't get that conhost.exe trick to work

I managed 1 time now (Win32 intunewin with Install.cmd/Uninstall.cmd and calling %systemroot% cmd.exe for both install/uninstall) but then I tried some more things and suddenly it didn't work againn (and I forgot the working version)...
...Intune with 32-bit processing, blah...

[KnifMelti]

• Visible powershell window while the installer runs
• Unable to update the log file
• Unable to add apps to the whitelist
• etc.

• The visibility is just a PS in User context - nothing dangerous and good to see something's happening while installing
• Log file as told before is written under %APPDATA%
• Apps to System whitelist can't be allowed for Users - then they could add anything...

[github-actions]

This issue is stale because it has been open for 30 days with no activity.

[ITistheworst]

I need to do a bit more testing when I get a chance I think. Is there something different about calling a script from the intunewin vs calling directly from command? Do you think that will be a requirement to make this work?

It would be preferable to avoid having to hardcode anything into the intunewin for maintainability.

[KnifMelti]

User installation:

Program
Install command
"%systemroot%\sysnative\WindowsPowerShell\v1.0\powershell.exe" -NoProfile -ExecutionPolicy Bypass -File "C:\Program Files\Winget-AutoUpdate\Winget-Install.ps1" -AppIDs "Postman.Postman"

Install script
-

Uninstall command
"%systemroot%\sysnative\WindowsPowerShell\v1.0\powershell.exe" -NoProfile -ExecutionPolicy Bypass -File "C:\Program Files\Winget-AutoUpdate\Winget-Install.ps1" -AppIDs "Postman.Postman" -Uninstall

Uninstall script
-
Installation time required (mins)
60

Allow available uninstall
Yes

Install behavior
User

System installation:

Program
Install command
"%systemroot%\sysnative\WindowsPowerShell\v1.0\powershell.exe" -ExecutionPolicy Bypass -WindowStyle Hidden -NoProfile -File "%ProgramFiles%\Winget-AutoUpdate\Winget-Install.ps1" -AppIDs 7zip.7zip
Install script
-
Uninstall command
"%systemroot%\sysnative\WindowsPowerShell\v1.0\powershell.exe" -ExecutionPolicy Bypass -WindowStyle Hidden -NoProfile -File "%ProgramFiles%\Winget-AutoUpdate\Winget-Install.ps1" -AppIDs 7zip.7zip -Uninstall
Uninstall script
-
Installation time required (mins)
60
Allow available uninstall
Yes
Install behavior
System

Detection (as x64 script):

# Change app to detect [Application ID] (case sensitive!)
$AppToDetect = "7zip.7zip"


<# FUNCTIONS #>

Function Get-WinGetCmd {

    $WinGetCmd = $null

    # Get WinGet Path
    try {
        # Get System Context WinGet Location
        $WinGetInfo = (Get-Item "$env:ProgramFiles\WindowsApps\Microsoft.DesktopAppInstaller_*_8wekyb3d8bbwe\winget.exe").VersionInfo | Sort-Object -Property FileVersionRaw
        # If multiple versions, pick most recent one
        $WinGetCmd = $WinGetInfo[-1].FileName
    }
    catch {
        # Get User context WinGet Location
        if (Test-Path "$env:LocalAppData\Microsoft\WindowsApps\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\winget.exe") {
            $WinGetCmd = "$env:LocalAppData\Microsoft\WindowsApps\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\winget.exe"
        }
    }

    return $WinGetCmd
}

<# MAIN #>

# Get WinGet Location Function
$WinGet = Get-WinGetCmd

# Set json export file
$JsonFile = "$env:TEMP\InstalledApps.json"

# Get installed apps and version in json file
& $Winget export -o $JsonFile --accept-source-agreements | Out-Null

# Get json content
$Json = Get-Content $JsonFile -Raw | ConvertFrom-Json

# Get apps and version in hashtable
$Packages = $Json.Sources.Packages

# Remove json file
Remove-Item $JsonFile -Force

# Search for specific app and version
$Apps = $Packages | Where-Object { $_.PackageIdentifier -eq $AppToDetect }

if ($Apps) {
    return "Installed!"
}

[github-actions]

This issue is stale because it has been open for 30 days with no activity.