Repository navigation
Usage with System Account #548
Description
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.
Reacted by lansalot
Activity
denelon commentedon 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.
actuallygmenzies commentedon Sep 1, 2020
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.
Below is myself running it from a Local Administrator account via cmd.
Hope the above makes sense.
Thanks for your help with this, it would make this the ideal scenario when deploying applications via Intune.
lansalot commentedon Sep 16, 2020
+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 commentedon Oct 15, 2020
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 commentedon May 10, 2021
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 commentedon May 11, 2021
Jorgy (@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 commentedon May 12, 2021
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.