Skip to content

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

Closed
beirbones opened this issue Aug 25, 2020 · 8 comments
Closed

Usage with System Account #548

beirbones opened this issue Aug 25, 2020 · 8 comments
Milestone

Comments

@beirbones
Copy link

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.

@ghost ghost added the Needs-Triage Issue need to be triaged label Aug 25, 2020
@denelon
Copy link
Contributor

denelon commented Aug 26, 2020

@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.

@denelon denelon added Issue-Question and removed Needs-Triage Issue need to be triaged labels Aug 26, 2020
@beirbones
Copy link
Author

Currently our business is moving from Config manager to Intune for our app deployment and generally looking after our devices due to Covid, I was hoping that by using Winget I could use it to add all of our required applications via Winget and reduce the amount of time I would spend having to package applications when a new update is released, this way I can just use Winget to always keep up to date packages and when a user with an older version requires the newest version they can reinstall using it also to update the application.

Due to a lot of applications and our security posture requiring users to be local administrators for devices for installations we can't just provide it to users as is as they won't be able to get past the UAC prompt, so when we are performing any installations we use the System Account for this. I've managed to deploy Winget via Intune by adding it's dependences in but it would always fail to install when trying to install an application, for my example I was trying to install Docker for Windows. I believe this is due to the below that when run as the System account it states it cannot execute the specified program.

Below is the image of me trying to run Winget from the System Account using Psexec.
Winget System account

Below is myself running it from a Local Administrator account via cmd.
Winget Administrator

Hope the above makes sense.

Thanks for your help with this, it would make this the ideal scenario when deploying applications via Intune.

@lansalot
Copy link

+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.

@JohnMcPMS
Copy link
Member

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.

@jorgytim
Copy link

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.
I'm looking forward to using Winget as our app delivery/update mechanism for our corporate owned fleet, but the fact that this is entirely user-driven right now keeps it from being seriously considered.

@denelon
Copy link
Contributor

denelon commented May 11, 2021

@jorgytim we have discussed the ability to filter/restrict results by InstallerType. That would enable a configuration to require MSIX. Would that address your concern? Many third-party entities prohibit modification or re-distribution of their packages.

@jorgytim
Copy link

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.

@ghost
Copy link

ghost commented May 12, 2021

@jorgytim
In MSIX tech community Ideas section,
Machine Wide Provisioning (Install for All Users) seems to be the most wanted feature but MS is reluctant.

On a sightly offensive note , I really do wonder how big brains think inside Microsoft since 2012.
They introduce "new/modern" features and in the process removes the useful ones that past techs provides/provides till this day.
and they think people will embrace their new half baked modern offerings. 🤷‍♂️🤷‍♂️

@denelon denelon closed this as completed May 14, 2021
@microsoft microsoft locked and limited conversation to collaborators May 14, 2021
@denelon denelon added this to the v1.3-Client milestone Jun 21, 2022

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants