Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update module to support running in SYSTEM context #7

Merged
merged 4 commits into from
Aug 15, 2022

Conversation

djust270
Copy link
Contributor

@djust270 djust270 commented Aug 12, 2022

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
Copy link
Owner

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
Copy link
Contributor Author

djust270 commented Aug 12, 2022

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 microsoft/winget-cli#149 microsoft/winget-cli#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
Copy link
Owner

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
Copy link
Contributor Author

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.

@jdhitsolutions jdhitsolutions merged commit cc3ea3d into jdhitsolutions:main Aug 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants