Usage with System Account

[beirbones]

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.

[denelon]

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

[cgerke]

I'd love to do a live demo with the winget-cli team showing them my production intune environment and how I am setting up winget usage. We are in the middle of a transition from traditional on-prem infrastructure to AAD+Intune. I could do it via Teams any time you like.

[beirbones]

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.

[denelon]

@cgerke,

The project was originally targeting developers. We decided to go open-source very early on, and we knew we would need lots of data on installers and usage to figure out what kinds of problems we would need to deal with. We also went out as a preview with very limited functionality. Of the two choices "spend a lot of time hoping we built the right thing and do a 'big bang'" style release or "build minimum capabilities and release frequently" we decided the latter.

I would have also loved to know who was going to use WinGet. We had several hypotheses, and we did some user research to invalidate a few of them. I would have also loved to know how everyone was going to want to use WinGet.

It's relatively easy to look back and say things like "we should have done x" or "we should have done y" when we did "a".

Different user groups also have different priorities. I've shared our philosophy with the Roadmap openly. In a world of infinite wants and limited resources, we need a way to prioritize the work we do.

MSIX was chosen as the release vehicle because it (the App Installer) was already part of the Windows release process, and it's the current best package format in terms of install/uninstall and the implications of degradation over time with upgrade/uninstall.

Our first "strategic" project was incorporating WinGet with the Microsoft Store so users could install those Apps/packages. There are still many improvements needed there, and we're working with the Microsoft Store on improvements. We want "better search experiences", "versioning", offline download support, etc.

The next one was Intune as a part of the solution for the retirement of the Microsoft Store for Business. As Intune runs things in the system context we needed a mechanism to enable it. We had already started working on the COM API so we could have both the CLI and native PowerShell essentially calling the same code. It was a logical next step to expose those same mechanisms to other MDM providers. We built and "in-process" COM API and that ships via NuGet. Next steps are to document that work.

We are actively looking at the usage in system context as a problem space. Many installers aren't going to work and play well like we would prefer. If we improve some of those edge cases before making system context "easier", we'll likely hear it from the customers who are more concerned about that. We're not going to make everybody happy. At least with the 👍 method we're getting data on what customers want, and we can make better informed decisions.

We're glad people care enough to complain about what we are or aren't doing. Let's continue to keep this productive, and please help us prioritize the work.

For others who read this, please use 👍 on the top-level Issue description to help prioritize work. Please don't add comments like "+1" or "me too" or "need it" or "want it". Anyone who is following those issues gets an e-mail notification, and we don't want to send that kind of traffic to their inboxes. If you have value to add like business justification (that hasn't already been added) or clarity to scope, please add it.

[PJMarcum]

It’s nice to hear that you guys understand the problems and use cases and that you value the feedback. I think Intune and ConfigMgr will be large consumers of this tool.

[cgerke]

It’s nice to hear that you guys understand the problems and use cases and that you value the feedback. I think Intune and ConfigMgr will be large consumers of this tool.

I agree, and the more they do the more manifest maintainers we will have.

[cgerke]

@cgerke,

The project was originally targeting developers. We decided to go open-source very early on, and we knew we would need lots of data on installers and usage to figure out what kinds of problems we would need to deal with. We also went out as a preview with very limited functionality. Of the two choices "spend a lot of time hoping we built the right thing and do a 'big bang'" style release or "build minimum capabilities and release frequently" we decided the latter.

I would have also loved to know who was going to use WinGet. We had several hypotheses, and we did some user research to invalidate a few of them. I would have also loved to know how everyone was going to want to use WinGet.

It's relatively easy to look back and say things like "we should have done x" or "we should have done y" when we did "a".

Different user groups also have different priorities. I've shared our philosophy with the Roadmap openly. In a world of infinite wants and limited resources, we need a way to prioritize the work we do.

MSIX was chosen as the release vehicle because it (the App Installer) was already part of the Windows release process, and it's the current best package format in terms of install/uninstall and the implications of degradation over time with upgrade/uninstall.

Our first "strategic" project was incorporating WinGet with the Microsoft Store so users could install those Apps/packages. There are still many improvements needed there, and we're working with the Microsoft Store on improvements. We want "better search experiences", "versioning", offline download support, etc.

The next one was Intune as a part of the solution for the retirement of the Microsoft Store for Business. As Intune runs things in the system context we needed a mechanism to enable it. We had already started working on the COM API so we could have both the CLI and native PowerShell essentially calling the same code. It was a logical next step to expose those same mechanisms to other MDM providers. We built and "in-process" COM API and that ships via NuGet. Next steps are to document that work.

We are actively looking at the usage in system context as a problem space. Many installers aren't going to work and play well like we would prefer. If we improve some of those edge cases before making system context "easier", we'll likely hear it from the customers who are more concerned about that. We're not going to make everybody happy. At least with the 👍 method we're getting data on what customers want, and we can make better informed decisions.

We're glad people care enough to complain about what we are or aren't doing. Let's continue to keep this productive, and please help us prioritize the work.

For others who read this, please use 👍 on the top-level Issue description to help prioritize work. Please don't add comments like "+1" or "me too" or "need it" or "want it". Anyone who is following those issues gets an e-mail notification, and we don't want to send that kind of traffic to their inboxes. If you have value to add like business justification (that hasn't already been added) or clarity to scope, please add it.

I appreciate the reply. I get it.

I really want this project to be successful for us all. It will drastically reduce resources required in enterprise packaging and opens up exciting possibilities for ci/cd scenarios with Intune.

[psmalley-ati]

To pile in on this conversation, we are trying to use winget in our RMM platform and that prefers to run all commands in the system context. It would be nice if we could get winget to work on a system wide basis so we can use it with our RMM to keep all our 3rd party applications up to date.

Right now we only use it for initial deployment.

[lansalot]

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

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.

[cgerke]

I guess it depends on your environment. If you are going AAD with Intune then everything is coming via the internet anyway.

Winget via Intune as “the store for business” is DO.

You can run it in system context (I’m already doing it) using a workaround.

Winget supports overrides natively for additional parameters, I don’t deploy anything with just silent either.

The fact though “system context” it’s unsupported is giving me second thoughts on using it as my primary delivery.

I was super excited about winget as I’m in the throws of moving from on-prem to cloud.

I built a nice pipeline to wrap winget installs in to win32apps that will stay auto updated.

Not so sure now though.

I really need system context supported so the wincli devs take this in to consideration. I can’t run the risk it does something weird with permissions because they are expecting it to be run by a “user” or a “user with local admin privileges“

Microsoft are pushing “zero trust” down our throats at every turn, local admin in the enterprise is a dinosaur.

[4D5A]

I am doing something similar to that. First I use a slightly modified version of this script (I added a workaround for winget asking for the geographic information the first time winget is run under the System context), and then I have template PowerShell scripts for installing, upgrading, and uninstalling applications via winget. I use an RMM to deploy and execute the scripts in the System context.

In my humble opinion, when Microsoft announced the release of winget, I was extremely excited about the possibility of having a command line package manager. First, I want to thank the Microsoft winget development team because it is awesome and I think it has the potential to be one of the greatest advancements to Windows in recent history.

I admit I made some assumptions. Those included the following:

• winget would functionally be equivalent to the linux apt package manager
• Winget would allow me to install, update, and uninstall applications
• Winget could natively run in the System context (most SMB size business orgs still rely on win32 apps and almost all of them support being deployed using an RMM that executes the installer through some form of scripting engine and in the System context)

Clearly, winget is close to meeting those expectations. It does allow us to install, upgrade, and uninstall applications. It allows us to use RMM solutions to manage packages through different scripting tools. We also have a workaround for running winget in the System context.

I would humbly request that Microsoft add the ability to run winget in the System context in a supported way.

Thank you, all.

[psmalley-ati]

Thank you for the link, I have been trying to get Winget to run in the system context so we can use it in our RMM.

[byjrack]

So it means getting the cmdlets out in addition to winget and then calling powershell I have found it is pretty reliable. Very similar pattern from Intune calls to install Store apps from the logs. Scripting the path calls is not super complicated, but it is finicky if you include parsing responses.

Now if I could get the cmdlets in the exitsing AppX that would be great, but don't know if there is a mechanism to surface those paths where pwsh can pick them up as SYSTEM.

[secprentice]

Microsoft - making this feature work will help improve the lives of IT admins and drastically improve security for their endpoints. We all use some sort of remote management system, inTune, SCCM, Altiris etc, but they all run as SYSTEM. If we could use WinGet as a normal binary, under the SYSTEM account we could easily deploy latest versions of software to our endpoints and keep software up-to date in general.

If I could use my deployment tool to run the WinGet upgrade command it would be a game changer. Every new endpoint I deploy would always be running the latest software version and I could remotely run the winget upgrade command to existing endpoints. My third party software vulnerabilities would be non-existent.

WinGet has the opportunity to improve the daily lives of IT admins, please dont fumble it. Make this feature work!

[jorgytim]

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.

[cgerke]

100%

If winget does not get support for running in System Context I will have to drop it as my organisation has adopted zero trust and my higher ups want all local administrators removed from our environment.

[denelon]

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

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]

@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. 🤷‍♂️🤷‍♂️

[secprentice]

Agreed. They are totally missing their target audience here. Its classic Microsoft.

[PJMarcum]

WinGet works in System context now. There's several blogs about this.

[jorgytim]

I wonder why this was moved to discussion from the issues list? One the release milestones there are items for machine vs. user applications, and with this the winget application itself needs to be addressed to accomplish this goal. Can we move this to a feature request and see if the community votes on having the winget package installable for "all users", as opposed to per-user?

[denelon]

@jorgytim it's a duplicate of #637, and the limitation is currently external with the installer and how MSIX works. This comment has links to the external issues: #637 (comment). The work item on the backlog was to support packages being installed either in User space or Machine space.

[denelon]

@beirbones This is a possible work around for Intune: https://docs.microsoft.com/en-us/mem/intune/apps/intune-management-extension#create-a-script-policy-and-assign-it

We tested this in a lab environment.

[beirbones]

Thanks for testing this, was the user you pushed the script down to a local admin?

I'm unsure how this changes anything, if the user isn't a local admin the install will fail unless run under system context but at that point winget can't be detected by the system account as from my above images etc.

Honestly I'd love to be wrong if you've found a way of doing this! :)

[RDMacLachlan]

Hi @beirbones,

Yes the user we had performed the test with was a local admin on the test VM. Without being a Local Admin or Power User on the device the Application installation would fail due to a lack of permissions.

Unfortunately the System Account does not register the Microsoft Desktop App Installer app which contains the WinGet tool and is therefore unaware that the WinGet tool exists.

Roy

[beirbones]

Thanks, Roy,

Yeah, unfortunately, this is the exact issue we are having, honestly, if we could get this to be usable via the system account it would be a game-changer for application management for enterprises.

Do you think this could be worked on at all or is it a flat no it's not possible?

[denelon]

@beirbones we're talking with a few different internal teams about different approaches to support this kind of a scenario. Nothing has been committed that I'm aware of.

[dougied76]

Yeah this would be huge. I have some scripts ready to go that if winget is available to the system account can unlock it's usage in configmgr.

[denelon]

I'll confirm, but I believe the user was configured as a "local admin" on the both machines. I'll ask my colleague to update this issue with more specifics here.

[tremor021]

OK, its been a year since this all discussion starter. Whats changed?

[denelon]

@tremor, the behavior of MSIX has not changed. Our plans for the future integration with Intune and unified endpoint management (UEM) solutions was recently announced.

[jorgytim]

Is there any chance then that the project team has considered changing the delivery mechanism to .msi instead of msix? Not having Winget available across the entirety of a system (not just in the user who installed it), is keeping this from being at all useful for enterprise customers. This toolset is excellent and many of us have been writing script frameworks to manage packages and repositories, but just having it available to the machine as opposed to the user is the only thing holding it back.

[denelon]

@jorgytim we're currently planning to stick with MSIX. Our desire is to follow the same guidance we provide to ISVs/Developers for packaging formats. This is likely to be a forcing function to ensure MSIX is able to meet the needs of our customers and partners. There are several ongoing discussions about the gaps and the pain related to MSIX as the Windows App package format.

[rothgecw]

Cross posting my response from Issue 367 ([https://github.com//issues/637#issuecomment-955055704]):

We have an automation tool where I work that I'd hoped to use WinGet to help manage our lab workstations. I encountered the same problem, but actually have a solution (at least for systems 20H2 and higher that have WinGet installed).

Windows Apps are actually stored under C:\Program Files\WindowsApps. In the case of WinGet, I am calling it using:

"C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.16.12653.0_x64__8wekyb3d8bbwe\AppInstallerCLI.exe" upgrade --all -h --accept-package-agreements --accept-source-agreements

Let me know if you have any questions or find this doesn't work for you. This is now a game changer for us!

[o-l-a-v]

@rothgecw

Great find. :)

I started labbing on a script that can be run from Intune in system context. I observed that it tries to update Office ProPlus too by default, so will have to add some logic for what apps to update vs. not. Maybe specify a list of apps. Will probably add some logging as well. And maybe logic for what apps must be closed. Could be combined with serviceui and toast notifications too (https://www.systanddeploy.com/2020/06/diplay-simple-toast-notification-for.html). Exciting times.

Anyways, just wanted to say thanks, and share what little I've produced so far.

Very nice work on this script. Do you have a repo somewhere for this to be posted for posterity and possibly make pull requests on?

I started some proof of concept here:

https://github.com/o-l-a-v/winget-intune-win32

The idea is to only create logic like this for apps that don't auto upgrade, or require admin to do so. PowerToys is first example, but I plan on adding Notepad++ and VS Code (device context) later. And more. :)

[abraxid]

Windows Apps are actually stored under C:\Program Files\WindowsApps. In the case of WinGet, I am calling it using:

"C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.16.12653.0_x64__8wekyb3d8bbwe\AppInstallerCLI.exe" upgrade --all -h --accept-package-agreements --accept-source-agreements

When I try this it tells me "Program 'ApplicationInstallerCLI.exe' failed to run: Access is denied"

[o-l-a-v]

Windows Apps are actually stored under C:\Program Files\WindowsApps. In the case of WinGet, I am calling it using:
"C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.16.12653.0_x64__8wekyb3d8bbwe\AppInstallerCLI.exe" upgrade --all -h --accept-package-agreements --accept-source-agreements

When I try this it tells me "Program 'ApplicationInstallerCLI.exe' failed to run: Access is denied"

What user are you running as, NT AUTHORITY\SYSTEM / S-1-5-18?

[abraxid]

I was running as Administrator... 🤔But on another device it actually works. 😅 I'll keep digging. Thanks for the quick response!

[ghathawayMIDD]

I am glad I found this post. I am attempting to get MECM to download, and update apps using Winget. I have attempted to call ".\appinstallercli.exe install notepad++.notepad++" and am not getting anything back. The path that I am currently using is - C:\Program Files\windowsapps\Microsoft.DesktopAppInstaller_1.16.13405.0_x64__8wekyb3d8bbwe. I am calling this command under the system account. When it runs - it doesn't do anything aside go to the next line.

My understanding is should be able to just call the command with similar syntax as winget. I have also tried calling it as appinstallercli.exe install --id notepad++.notepad++.

These commands work fine when running the real winget command on a test user, but not as the system account.

[djust270]

Here is the idea I had to control what software is upgraded. Get a list of installed software and index it on a hashtable to Winget package IDs specified.

# Get path for Winget executible
$Winget = gci "C:\Program Files\WindowsApps" -Recurse -File | where name -like AppInstallerCLI.exe | select -ExpandProperty fullname
# Uninstall registry key locations
$uninstallKeys = "registry::HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall", "registry::HKLM\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall"

# Build list of installed software based on uninstall keys
foreach ($key in $uninstallKeys)
{
    $SoftwareList += Get-Childitem $key | Get-ItemProperty | where displayname | select -ExpandProperty displayname
}

# Hash table to translate installed software to Winget Package IDs
$WinGetPackages = @{
'Google Chrome' = 'Google.Chrome'
'Mozilla Firefox (x64 en-US)' = 'Mozilla.Firefox'
'Microsoft OneDrive' = 'Microsoft.OneDrive' 
'Notepad++' = 'Notepad++.Notepad++'
'Microsoft Edge' = 'Microsoft.Edge'
}

# Index software displaynames in hash table
$WingetPackages = $WinGetPackages[$SoftwareList]

# Remove null values from array
$WingetPackages = $WinGetPackages | where {$_}

# Run the upgrade command for installed software only based on our package list
foreach ($Package in $WinGetPackages){
write-host "Upgrading $($Package)"
& $Winget upgrade --id $Package -h --accept-package-agreements --accept-source-agreements
}

[ghathawayMIDD]

Hello, The –accept parameters are in the command that I was using before listed below. .\AppInstallercli.exe install --id Discord.Discord --silent --accept-package-agreements --accept-source-agreements But following that parameter that you provided this is what I get. ***@***.*** Discord itself doesn’t install, but if I use the same command as winget on the local user it works fine. I am doing this via psexec -I -s powershell.exe to make sure I get on the system user. I configured it was nt authority\system via the whoami command.

[o-l-a-v]

Alright, I did not see it as I did not care to skim through all the bloat that gets added when you reply using email.

Have you checked that winget-cli.exe exists?

• winget command tool is NOT installed by installing "App Installer" in Microsoft Store #1793 (comment)

Are any logs created by winget?

• https://docs.microsoft.com/en-us/windows/package-manager/winget/troubleshooting#logs

Anything that could block winget, like exploit protection or app locker?

What version of "App Installer" and Winget ("winget --info") do you have?

[ghathawayMIDD]

Winget itself is installed. "Winget-cli" does not, but the appinstallercli.exe does.
I don't think anything is blocking winget. I don't have any security software installed in this test lab.

Any command that uses appinstallercli.exe doesn't seem to display any information. When running under the system account. I chcked to see if there was any logs being created by appinstallercli, but it wasn't in that file structure.

If i do winget --info as a normal user I get -
Windows Package Manager v1.1.13405
Copyright (c) Microsoft Corporation. All rights reserved.
Windows: Windows.Desktop v10.0.19044.1466
Package: Microsoft.DesktopAppInstaller v1.16.13405.0

[ghathawayMIDD]

[Romanitho]

What do you get if you run
AppInstallerCLI.exe --info
?

[ghathawayMIDD]

This is what I got. It looks like it ran the command, but didn't reply with anything.

PS C:> cd '.\Program Files'
PS C:\Program Files> cd windowsapps
PS C:\Program Files\windowsapps> cd .\Microsoft.DesktopAppInstaller_1.16.13405.0_x64__8wekyb3d8bbwe
PS C:\Program Files\windowsapps\Microsoft.DesktopAppInstaller_1.16.13405.0_x64__8wekyb3d8bbwe> .\appinstallercli.exe --info
PS C:\Program Files\windowsapps\Microsoft.DesktopAppInstaller_1.16.13405.0_x64__8wekyb3d8bbwe

[ghathawayMIDD]

This is the way to replicate what I am doing -

1. Open up command prompt as admin
2. PSexec -i -s powershell.exe
3. cd "C:\Program Files\windowsapps\Microsoft.DesktopAppInstaller_1.16.13405.0_x64__8wekyb3d8bbwe"
4. .\appinstallercli.exe --id Discord.Discord --silent --accept-package-agreements --accept-source-agreements

It will then not run the command from the looks of it.

[Romanitho]

can you try to install/reinstall MS Visual C++ please ?
https://aka.ms/vs/16/release/VC_redist.x64.exe
https://aka.ms/vs/16/release/VC_redist.x86.exe

[ghathawayMIDD]

That got it working. I had 2013 installed. Installing discord failed, but notepad++ installed. Thank you so much!

[ghathawayMIDD]

[damirkasper]

you replies are absolutely mangled since you are using email to interact with this thread. i think if you started posting directly it would be a lot easier to read and certain things would work like the image you attached to your email which didn't make it into the email to web translation.

[ghathawayMIDD]

Sorry about that. I have removed the email bits, and will reply from here now.

[sr1ramnarendra]

I exactly face same issue can someone please help me with if some one has proper resolution for this?

[o-l-a-v]

#962 (comment)

[4D5A]

Thank you for creating this. winget is great and I look forward to watching how it progresses!

To provide background on a somewhat different use case, where I work we use an RMM to remotely support different companies. I am looking for a way to use the RMM to run a PowerShell script (which can run either as Local System or the currently logged in user who normally is not a local administrator on the machine) to install winget. Once winget is installed, I need the Local System account to be able to execute winget commands so the RMM manage apps with winget.

[djust270]

I wrote a script that should work for you. Check my blog post https://davidjust.com/post/intune-install-software-with-winget/

[4D5A]

Thank you @djust270. I will take a look.

[PJMarcum]

For anyone following this thread, this guy wrote some really cool stuff in response to a question I posted on Reddit. https://github.com/arsscriptum/PowerShell.Reddit.Support/tree/main/john but there's still the issue of winget needing to be run in the logged on user context so I am using this module: https://github.com/KelvinTegelaar/RunAsUser so I can start the process as local system and run the "real" script as the logged on user without the user needing admin rights. But for the record allow me to say that Winget.exe absolutely sucks from the perspective of someone who has been managing devices for 20+ years.

[o-l-a-v]

Running from system context can be done much easier than that.

• Usage with System Account #962 (comment)

I've used this method successfully with Intune:

• https://github.com/o-l-a-v/winget-intune-win32

Others too:

• https://github.com/Romanitho/Winget-autoupdate

[djust270]

Also check out the WingetTools PowerShell module by Jeffrey Hicks. I made a small contribution allowing this module to run as system and works great for installing and updating applications https://github.com/jdhitsolutions/WingetTools/blob/main/README.md

Alternatively, if I designed this single script which will handle installing WinGet, Visual C++, and any package from the WinGet public repo. This can be easily packaged as a Win32 app and deployed through Intune as well. https://github.com/djust270/Intune-Scripts/blob/master/Winget-InstallPackage.ps1

[Mike61704]

How is this going to replace the Business Store for apps? You cant even run winget from a system context. Trying to run this from an RMM agent is like hitting your head against a brick wall. The package manager is awesome, but there is no way this is going to work from an enterprise managed level. No way. When you have hundreds and thousands of computers to manage, logging into each one and running winget as a users context is not scalable and very inefficient use of time. Is there any official update on if this is going to change? Sounds like the Microsoft store for business is decommissioned in a few months.

[denelon]

The integration with Intune (and available for other MDM solutions) is via a separate NuGet package exposing an in-process COM interface. Once that is GA, we will bump the version and add additional documentation. It's designed to work with system context callers.

[cgerke]

Can you point me to the documentation on this?

[denelon]

Here is the spec and we're still working on additional user documentation. There is also a sample caller.

[danielsherratt]

This isn't going to help everyone, but hopefully someone

We have been using Group policy to kick off install.cmd on startup, install.cmd containing myawesomepackage.exe /s
I then got sick of updating packages every 5mins so went to a package manager

I was using Just-Install until I recently found out it stopped, it was still working to install packages but they were out of date
just-install was great as I could run just-install.exe myawesomepackage (the exe just needed to exist, didn't need to be installed locally)

After trial and error I got this working with winget as well
I saved the below as winget-launcher.cmd
start "" "C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.18.2691.0_x64__8wekyb3d8bbwe\winget.exe" install %* --accept-package-agreements --accept-source-agreements --silent
I can then call it with winget-launcher.cmd myawesomepackage

Things I'll likely need to improve on is creating better way of calling the package instead of a hard path, version 1.18.2691 came out yesterday so I should be fine for a while

Another thing to note is Winget will only use reputable sources, so you can't create your own repo
microsoft/winget-pkgs#87961

[WesMadden]

This was pointed out to me by someone else so not my idea but you can use pushd with a wildcard. No need to keep changing the path.
pushd "C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_*_x64__8wekyb3d8bbwe"

Also instead of using a startup script, I use a scheduled task that randomizes a time to update within 8 hours daily and then specify that if the task is missed run it immediately.

[danielsherratt]

Ah thanks, Ill look at implementing that

[4D5A]

Another option is to recurse through "C:\Program Files\WindowsApps" for a directory with winget.exe. While a local administrator does not generally have permissionto access "C:\Program Files\WindowsApps", the System account does so if you need to run winget as System (for example to execute commands with an RMM), that actually works well.

Using the RMM to run the following commands locates winget.exe and creates an alias so sysget is an alias for the full name for winget.exe.

$exeFilename = get-childitem -Path "C:\program files\windowsapps\" -filter winget.exe -Recurse | %{$_.FullName} New-Alias -Name sysget -Value $exeFilename

After the alias is created, you can run the following command using your RMM to upgrade applications using winget.exe.

sysget upgrade --all -e --accept-package-agreements --accept-source-agreements

[cgerke]

I'm currently deploying win32apps via Intune and winget successfully using the following code (example installing Azure Data Studio).

#region CODE
$winget = $null
$DesktopAppInstaller = "C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_*_x64__8wekyb3d8bbwe"
$SystemContext = Resolve-Path "$DesktopAppInstaller"
if ($SystemContext) { $SystemContext = $SystemContext[-1].Path }
$UserContext = Get-Command winget.exe -ErrorAction SilentlyContinue
if ($UserContext) { $winget = $UserContext.Source }
elseif (Test-Path "$SystemContext\AppInstallerCLI.exe") { $winget = "$SystemContext\AppInstallerCLI.exe" }
elseif (Test-Path "$SystemContext\winget.exe") { $winget = "$SystemContext\winget.exe" }
else { return $false }
if ($null -ne $winget) { $winget }
# Logs $(env:LOCALAPPDATA)\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir
& "$winget" install --id "Microsoft.AzureDataStudio" --exact --silent --accept-source-agreements --accept-package-agreements | Out-String
#endregion

[byjrack]

I know my biggest use case is not "machine wide" installs, but handling any install that prompts for UAC. I would be happy if I could have Intune scope handle the elevation on behalf of the users (user, machine, elevated) vs running in SYSTEM. I have not figured out a good trick to do that without writing some custom process handling that felt too fragile.

[denelon]

The Microsoft.WinGet.Client PowerShell module (technically pre-release, but not marked that way due to limitations of the PowerShell Gallery) has the ability to run in System context. This will not work for packages that are scoped to a single user, but for machine wide installs it does.

[byjrack]

yup but currently it still requires pwsh7 as a dependency so lots of reqs to get it out there. And even as Machine you will get a number of commands with errors. 100% its something, but because its shipped independent of the MSIX, it's limitations, and its dependencies it is still a heavy lift.

Trying to bang on the wingetCOM Server a bit (which the cmdlets use) to see if it's an easier path

[secprentice]

MS has the opportunity to improve the quality of life for millions of IT admins by making Winget work as SYSTEM. As this discussion shows using it in tandem with a deployment (RMM) tool like inTune, SCCM, Altiris etc would be absolutely game changing. The current deployment method is rather unless to us.

MS, please take on the mass of feedback you have been given here and put the proper solution in place.

[secprentice]

Do you have any links please?

…

On Mon, Nov 13, 2023 at 4:01 pm, John Marcum ***@***.***(mailto:On Mon, Nov 13, 2023 at 4:01 pm, John Marcum <<a href=)> wrote: WinGet works in System context now. There's several blogs about this. — Reply to this email directly, [view it on GitHub](#962 (reply in thread)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/ALBTDDZ2WKXDTN7FKFMJVODYEI77FAVCNFSM4454EUAKU5DIOJSWCZC7NNSXTOKENFZWG5LTONUW63SDN5WW2ZLOOQ5TONJVGU3TONI). You are receiving this because you commented.Message ID: ***@***.***>

[byjrack]

I am guessing they are referring to the Powershell cmdlets which work great if you are a pwsh 7+ environment or it could be the Powershell modules out there for "common functions" like https://github.com/o-l-a-v/winget-intune-win32. Winget functions in SYSTEM if you handle the lack of PATH config by fully qualifying the location.

There are gotchas like the logs don't seem to show up and other papercuts that make use under SYSTEM annoying, but it definitely can be done.

Now remember winget the package manager is used by MS for deploying MS Store apps today (AgentExecutor -> wingetCOM) but Intune has no native support for following that same process for the Community manifest registry.

[Romanitho]

https://github.com/Romanitho/Winget-Install
https://github.com/Romanitho/Winget-AutoUpdate

[PatrickSchmidtSE]

I was shocked that even after 4 years this is still not adressed fixed. Workarounds are not working for me ( except for install ). But without search and stuff this is not applicable in our RMM tool.

This would be such a game changer, but otherwise it is not usable in that form in any bigger IT department...

[4iekurs]

SCCM compliance setting with SYSTEM rights
Discovery script -

Set-Location "C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_*_x64__8wekyb3d8bbwe"
# Define the application you want to detect
$targetApp = "Insecure.Nmap"

# Get a list of installed applications using Winget
$installedApps = .\winget.exe list --accept-source-agreements

# Check if the target application is installed
if ($installedApps -like "*$targetApp*") {
    Write-Host "True"
} else {
    Write-Host "False"
}

Remedation script -

Set-Location "C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_*_x64__8wekyb3d8bbwe"
.\winget.exe install Insecure.Nmap --force --accept-package-agreements --accept-source-agreements

SCCM Application
Installation program -

PowerShell.exe -ExecutionPolicy Bypass -NoLogo -NonInteractive -NoProfile -WindowStyle Hidden -Command "& {Set-Location 'C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_*_x64__8wekyb3d8bbwe'; .\winget.exe install Insecure.Nmap --force --accept-package-agreements --accept-source-agreements}"

Detection -

Set-Location "C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_*_x64__8wekyb3d8bbwe"
# Define the application you want to detect
$targetApp = "Insecure.Nmap"

# Get a list of installed applications using Winget
$installedApps = .\winget.exe list --accept-source-agreements

# Check if the target application is installed
if ($installedApps -like "*$targetApp*") {
    Write-Host "True"
} else {
}

[scottcopus]

@4iekurs Do these winget SCCM scripts work for you while running as system? If so do you have the SCCM application settings (like 'User Experience' or anything else) set to something specific? I'm not having any luck. The PS runs but winget doesn't. Thanks.

[byjrack]

As long as you handle the path issue given SYSTEM doesn't have winget in PATH it works for me. Are you dumping the output to a text file or something to make it easy to figure out what might be happening w your PS1 output?

[denelon]

The other area of concern in system context is to make sure the "installer" supports the machine scope. MSIX packages don't get provisioned until the user logs in, and some installers may not support machine wide, or they may have their own built-in logic to try and detect if the "user" is a member of local administrators.

You may also need to bootstrap WinGet if this is immediately after a Windows installation (before Microsoft Store updates get applied). I'd suggest using Repair-WinGetPackageManager -Latest -Force in the Microsoft.WinGet.Client PowerShell module for bootstrapping.

[denelon]

Given the Microsoft.WinGet.Client PowerShell module you can use the other PowerShell cmdlets, so you don't necessarily have to scrape text output from winget.exe.