-
Notifications
You must be signed in to change notification settings - Fork 1.5k
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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
Usage with System Account #548
Comments
@beirbones can you share more specifics about your scenario? I'd love to understand what you're hoping to be able to do. I'll also look into the issue with the system account. |
+1 for this. Currently, in my Windows Virtual Desktop environment, I've a "choco upgrade all -y" that runs as system daily, and upgrades the supported 3rd party stuff. |
The problem comes from our current release vehicle, which is inside an MSIX package. The system cannot register packages for use (that I know of). We would need to investigate if this is indeed possible, and if not, how we would enable the scenario without it. |
So has there been any further consideration to altering the usage of the MSIX package as the release vehicle? Being able to execute this as the "system" account is a critical component to making this useful in a corporate (aka managed) environment. Otherwise it's just additional work to create a software repository so that users can install their own applications, subsequently requiring them to have local administrative privileges on their machines. |
@jorgytim we have discussed the ability to filter/restrict results by |
The reason I reference the MSIX is that in a previous comment it was said that the release vehicle (MSIX) is what's limiting the ability to install WinGet for use by the system account (all users vs. user-specific package). This is the biggest drawback right now to Winget is that it is deployed on a per-user basis, therefore cannot be accessed by the system account. In order for managed environments to be able to call Winget (by service, scheduled task, or other mechanism) to automatically install packages, use of the system account is critical. As someone had previously mentioned, deploying this to regular users and having them need to elevate to install packages makes such a great toolset unusable for businesses that have worked so hard to secure their endpoints. Plus the ability to "push" software to a machine via Winget would be a huge win (aka, ability to setup a scheduled task to download/install packages), and currently it's user-driven due to the lack of ability to deploy this to the machine. |
@jorgytim On a sightly offensive note , I really do wonder how big brains think inside Microsoft since 2012. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Not necessarily an issue but will there be any support for Winget to be run by the system account? I've been testing out it's usage currently so that we can use it within Intune prior to the full release for testing purposes. Unfortunately when run as the System account Winget can't be detected and run by it.
Perhaps this is an issue on my end but will this ever been something that will be usable in future?
Side note: I think this is absolutely fantastic and I'm looking forward to where this will go. I believe it will make Application management for Enterprises infinitely better.
The text was updated successfully, but these errors were encountered: