search

jdhitsolutions / WingetTools

A set of PowerShell tools for working with the winget package manager.
MIT License
146 stars 14 forks source link

Update module to support running in SYSTEM context #7

Closed djust270 closed 2 years ago

djust270 commented 2 years ago

Ive added a new function "Get-WingetPath" and updated other functions where needed to explicitly state the path to the Winget executable. Calling the Winget executable works under system context, however the alias "winget" is not available to system.

jdhitsolutions commented 2 years ago

I've never considered running Winget under anything other than user credentials. I'm trying to imagine a situation where you would install applications under the system context. You'll need to provide some background. Also, any PowerShell code should use full cmdlet and parameter names, not aliases like gci.

djust270 commented 2 years ago

I am a system administrator at an MSP. I leverage Winget under the SYSTEM account through both Intune and our RMM tool to install / update software. Here is an example use case on my personal blog https://davidjust.com/post/intune-install-software-with-winget/ . The script I use through our RMM to keep certain applications updated with Winget : https://github.com/djust270/Intune-Scripts/blob/master/Winget-UpgradeSelect.ps1

There have been a few open issues on the Winget repo with others who would like Winget to be able to natively run under SYSTEM https://github.com/microsoft/winget-cli/issues/149 https://github.com/microsoft/winget-cli/issues/2145

I would be happy to remove the use of aliases and resubmit the PR. Also, I did not release who you were until after I submitted the PR. PowerShell in a Month of Lunches got me started down my coding journey 2 years ago. Now I would consider myself advanced in PS, and comfortable in Bash and Python, so thank you for helping me.

jdhitsolutions commented 2 years ago

Thanks for that background. I can see the value. I wonder if the module shouldn't simply always use the winget.exe file under C:\Program Files\WindowsApp. The winget.exe file under the user's AppData folder is a reparse point. It isn't clear what it is pointing to, but I can only assume it is the file under Program Files. If the module commands always used the Program Files file, then it wouldn't matter if you were running under system or not. Am I missing anything with this logic? And yes, please revise your code to expand aliases. The best practice is to avoid aliases in script files.

djust270 commented 2 years ago

I wonder if the module shouldn't simply always use the winget.exe file under C:\Program Files\WindowsApp

Unfortunately, access to this folder is restricted with the conditional ACE "EXISTS WIN://SYSAPPID". Attempting to access this folder under a user account results in access denied.