winget - is this awesome as it seems

Been using this a while for personal use. It is able to integrate with multiple page managers giving the option to update a wide variety of software and scripts.

[-]

Leinheart@reddit

You're missing that :

Its up to the individual developers to make sure winget packages are available

And more crucially,

Natively, it only runs in user context. Which is a pain for system wide installed apps.

[-]

alpha194@reddit

There are ways to get it to run under system for large scale patch management, but they feel abit DIY. Native support for machine based would be nice but it seems Microsoft prefers user context.

[-]

All of my winget install scripts fetches the current exe of winget and sets it or updates a system variable so it can easily be ran in the system context making the installs system wide. Has worked great for a couple years now and saves me time not needing to update as many of our installers.

[-]

420GB@reddit

The PowerShell module has native support for running as SYSTEM.

[-]

BlackV@reddit

the powershell module that is not included by default still?

er.. I will say I have not checked recently to see if they changed that

[-]

lolfactor1000@reddit

If you set the winget exe as a system variable, you can execute winget in the system context via MECM or Intune.

[-]

SnooMachines9133@reddit (OP)

> up to the individual developers

Fair, but happy to take what I can for little effort.

TBH, I didn't even realized there's random MS Visual C++ Redistributables on my computer that could be updated. Not sure which game or app they're from, but surprised MS/Windows update didn't catch them.

> only runs in user context
Yea, that part seems crappy. Especially from a corporate patch management perspective.

[-]

nodiaque@reddit

User context install is a pane and should be ban. I see that as an attempt at reducing administrative install without using a service for it. But user context install, no inventory reporting, unable to preinstalled or update properly unless you start adding login script and such.

[-]

awful_at_internet@reddit

I can see some use-cases for user context installations; however, it really should be something set by system admins with configuration items like GPOs, not the software dev/installer.

As an example, having a shared-space machine install to user context would be helpful if some of your users need access to a tool not tied to your IAM. So requiring that machine group to install that software to user would be a nice safeguard.

But again, only if the sysadmin can actually control it. And the prevailing thought among Msft and Apple devs seems to be that they are the sysadmins.

[-]

nodiaque@reddit

The only thing that is needed in user context are personallisation and user file, you know like it used to be with anything under appdata or my documents. The apps could well be installed at system level using a service that allows it but run under user context. This way, it's manageable and when there's a cve, you can properly patch everyone.

[-]

awful_at_internet@reddit

Hmm. I had been thinking youd need a way to navigate user handoff where file+resource locks are concerned, but I suppose that's the part devs need to get right?

Idk, just trying to figure out why they'd have set it up the way it is. Usually theres one or two good reasons.

[-]

nodiaque@reddit

Lock aren't a problem. Most software are admin installed and many use service for update. Firefox and Adobe acrobat are 2 exemple of that, but there's many more.

[-]

fresh-dork@reddit

you can create a private repo and populate that with apps you control. use jfrog artifactory to manage that - might be able to mirror only specific things, or add internal tools and distribute it that way

[-]

Unexpected_Cranberry@reddit

Is there an officially supported way to do this now? I looked into it a while back because we needed a solution that could have a on-prem repo fully managed by us. All I found back then were hacky community things or some kind of cloud service.

[-]

Direct_Witness1248@reddit

Some apps require the older C++ or .NET libraries, e.g. companion apps for games made by modders/hobbyists. I have quite a few versions because some of those type of apps rely on the older versions. But in my experience usually these days even hobbyist apps prompt you to install the missing dependencies.

[-]

sitesurfer253@reddit

You can get around the second part with some clever powershell. Once you get the scriptblock figured out to find the path it needs for winget, things become a bit easier.

I like it, but it definitely would be better if SYSTEM could run it natively

[-]

b-scrillz@reddit

We push a scheduled task through Intune that runs Winget as system via a Powershell script to leverage it for system apps. Works great.

[-]

autojack@reddit

10 years ago it was always a pain to ensure the correct redistributals were on a computer for a certain app - we had some vendor apps that were old and would break if their certain c++ dependencies were updated - we’d have 5-8 versions on some PCs depending on the app set. Less common now but have a few of those floating around.

Not sure if it was worse or better when some would include the particular dlls they needed in their own install directories - they’d pop up randomly in vulnerability scans or pen tests.

[-]

dairyxox@reddit

It’s like a hobbyist project for a lot of the packages, so it’s not robust or reliable. You can’t really use this for widespread enterprise scenarios.

[-]

Leinheart@reddit

I tend to agree. These two limitations are, kinda disappointing, but its a fantastic tool. I use it at work all the time :)

[-]

Matt_NZ@reddit

I haven't really had any issues with "--scope machine" as a solution for this. I've started using winget with SCCM builds (especially new AVD images) and that switch hasn't failed me yet

[-]

Small_Editor_3693@reddit

Doesn’t it still start as the user so your users need local admin with —scope machine?

[-]

aretokas@reddit

Not only that, I'm pretty sure the official PowerShell module works properly everywhere now.

Not that it's hard to make Winget work in a system context for RMM or MDM scripting.

[-]

Angelworks42@reddit

It's up to the app manifest. I update my idiot users who somehow got Thunderbird installed for them using winget and configmgr.

I'd say it's biggest fault honestly is clients where Windows Store is broken enough where winget simply doesn't work.

Also for the longest time the version is winget that came with Windows pointed to a dead cdn so you essentially had to boostrap it because it's kinda unclear how often Windows store updates things, but also if you use winget in osd you'll want to have some code to update it during mini setup.

[-]

BlackV@reddit

Also for the longest time the version of winget that came with Windows pointed to a dead cdn

It was super painful at the start

[-]

cottonycloud@reddit

I kind of got it working with my MDT setup, but there’s a ton of caveats.

The built-in one with Windows 10/11 is already outdated so you need to find out how to update that. Repair-WinGetPackageManager can temporarily bork the install for Windows 10 and I couldn’t figure out why (which is fine, just install with Add-AppxProvisionedPackage)
Certificate pinning for MS Store needs to be disabled temporarily, even if not installing from there.
Some apps do not have —scope machine supported even though they are for the whole computer.
If you rely on a public manifest, shit can randomly break. Example is PowerShell 7.6 manifest was changed to default to msix installer.

[-]

BlackV@reddit

Example is PowerShell 7.6 manifest was changed to default to msix installer.

7.6? I though the official change was going to be 7.7 so maybe 7.6 preview?

[-]

AcidBuuurn@reddit

To fix winget open the Microsoft Store go to Downloads and update “App Installer”

[-]

phobug@reddit

Its up to the individual developers to make sure winget packages are available

Yes, thats always the case for every piece of software its up to a developer to provide you a package of the software. But funny enough you can package something for winget yourself.

[-]

joe-dirte-inc@reddit

In regards to "a pain for system wide installed apps", ran into this issue trying to update the Microsoft Teams app via Scheduled Tasks using the SYSTEM account, ended up using a PowerShell script to point to winget.exe in WindowsApps and --force, has been working great for over a year.

[-]

End0rphinJunkie@reddit

That second point is the real killer for enterprise mangement. Its fine for bootstrapping your own dev machine, but trying to script it system-wide usually turns into a permissions nightmare.

[-]

TimeRemove@reddit

Generally, I'd never recommend using winget upgrade --all:

Supply chain attacks are a thing, and are growing more common/popular constantly. Unfortunately, anything can register itself on winget, and the mechanism of upgrade is of differing quality. You can, and should, evaluate the upstream but if you do so you aren't then running --all, you're targeting.
Some software is licensed as minor / major licensing, with the major versions requiring a different license (i.e. feature improvements) than the minor (security updates). winget upgrade --all, will quite happily install the latest major version and put you outside of compliance/ask for a new license.

It is a blunt tool, that predictably has blunt results. It isn't winget upgrade I have concerns about, and in fact would happily recommend it, it is the --all param. It isn't "patch management" it is a "I cannot be bothered to do patch management" tool. It is a patch no-management process.

[-]

420GB@reddit

winget d designed for home users and developers, but with enough scaffolding and work you can make it work pretty well for a business and server environment

[-]

TimeRemove@reddit

Right; but not --all. That's where the scaffolding and work comes in, you have to target specific, safe, packages for automatic updates and not spam "update everything" without a care.

[-]

fuckadviceanimals69@reddit

About a year ago I went through and turned most of our intune applications into powershell scripts bundled as win32 apps that install apps via winget. It's very useful for ensuring that the latest version of an app gets installed - otherwise 6 months after deploying a win32 app I'd need to go and repackage the latest installer for all these applications.

You can also use winget for updates. If you're using intune you can set the detection script to check for a later version, and install if it finds it. That's very powerful, but I did not go that route because it didn't give us enough control. We could ensure apps didn't upgrade during working hours, and this wouldn't give us a chance to properly stage and test. But, it's an option.

Other people have mentioned it has to run in user context. That's not entirely true, but the path to winget only exists in user context. So if you're running the win32 app (again, assuming intune) in system context, the install script needs to explicitly go to winget's location. There are some great YouTube guides for this. If you're not using Intune, I see no reason why that method can't also be extended to whatever your use case is.

Not sure if any of that is your exact use case. But yes, it can bulk update your apps. Think of it like a very Microsoft-y package manager.

[-]

brothertax@reddit

I do exactly this. My detection scripts use winget to determine if the package is installed AND up to date. If it’s not up to date it’s not considered installed and allows the user to update the app at their convenience by clicking Install in Company Portal.

I have a handful of apps (Acrobat and other highly targeted apps) that upgrade when the detection script is run. It’s such a useful tool.

[-]

CaptainZippi@reddit

Every day windows gets more like Linux.

(I’ll get me coat)

[-]

digsmann@reddit

Winget is very handy, and I like it.
if you update or install apps from a local administrator account, it should update apps for other users in it too.

[-]

joerice1979@reddit

After a few years; I'd have to say not quite.

Firstly it's not always native to a new install, which is a missed opportunity. The MS Store will have it, but don't search for "app installer" as you won't find it (or couldn't the last I tried). Or run some poweshell line to get it installed, which works about 75% of the time for me.

I'm sure there is a foolproof way of getting it easily, but any such attempt quickly saps my energy for it.

The absolute killer is, though, I can never get it to run as the local admin account while in a non-admin account. There is probably a way but I've never found it.

So for home users that run as admin, it's great, or if your applications are all in userland. For any kind of business application, I've yet to make it useful, but I guess that is what RMMs are for.

Ultimately, Microsoft reinvented an old, established and fully functional wheel (apt/yum/etc) but bodged it.

[-]

SnooMachines9133@reddit (OP)

Cynical me says they didn't want to make it too easy for Windows admins as it would cut into their Intine product line.

But yea, I remember my earlier SCCM packaging days and comparing it to Linux package managers, and asking why this wss so annoying. Then again, it at least gave opportunities for jr eng (at least back then) to get their foot it.

[-]

BlackV@reddit

fairly sure intune uses winget, underneath

[-]

Sceptically@reddit

Or run some poweshell line to get it installed, which works about 75% of the time for me.

I stopped using "Install-Script -Name winget-install" and running winget-install due to it failing inexplicably (probably due to the logged in user not being an admin user) when I tried testing it more widely. I ended up deciding that it was better to just install the prereqs manually.

But winget is a nice convenience when it works.

[-]

bbqwatermelon@reddit

Wait until you get the nebulous "installed by other means" message and discover it is not bundled with where it may be most useful (windows server). The idea is novel though.

[-]

cheese-demon@reddit

looking at you PowerShell, which does this frequently for upgrades even when i installed via winget in the first place

[-]

Entegy@reddit

WinGet just plain refuses to touch PowerShell 7 and I have no idea why. I've tried so many times to have it updated via WinGet even if WinGet installed it and it just doesn't.

I've also never seen PS7 be updated by Windows Update. I finally saw a random GitHub comment from an MS developer saying that publishing updates to Microsoft Update lags by weeks from a new version's actual release.

So for PS7 I'm still installing the MSI manually every update and it sucks. WinGet won't touch it and they take too long to push it to MU in the meantime you get an outdated version warning every time you launch PS7 and security tools flag an outdated software. Sucks.

[-]

BlackV@reddit

depends how/where you installed it originally, there are differences between the store install and the msi install and the zip install

[-]

mb9023@reddit

On my pc winget install Microsoft.Powershell worked fine to update to 7.6.1 just now. It seems like as of 7.6.0 it defaults to the MSIX package which is the one installed from the Microsoft Store and Windows Update, that may or may not help you.

https://learn.microsoft.com/en-us/powershell/scripting/install/install-powershell-on-windows?view=powershell-7.6

[-]

ChrisTX4@reddit

Winget _is_ bundled with Windows Server 2025. not available on older releases though.

[-]

420GB@reddit

Only with the desktop experience option and also it does work on older releases it's just not preinstalled.

[-]

WorkLurkerThrowaway@reddit

Winget pulls packages from the publisher right? So arguably kinda pointless because servers shouldnt be hitting the internet. Unless you can setup a local cache or something to pull from.

[-]

420GB@reddit

You can set up your own internal package source

[-]

PJBthefirst@reddit

So arguably kinda pointless because servers shouldnt be hitting the internet

What do you mean servers shouldn't be hitting the internet?

Note:
I'm not a sysadmin or ops guy, and I'm not privy to what windows servers are generally used for, so please keep that in mind if this sounds snarky - I'm genuinely curious:

[-]

WorkLurkerThrowaway@reddit

In most environments a server exists to do a specific task. Outside of what is absolutely necessary for that task, it’s generally best practice to block all other traffic, especially outbound to the internet.

[-]

PJBthefirst@reddit

Oh I see what you mean now, by "hitting the Internet" you mean just having a naked server without things like IP/domain whitelisting, etc

[-]

WorkLurkerThrowaway@reddit

I mean it could have whitelisting, the point though is don’t whitelist anything that isn’t necessary. And pulling updates for 3rd party software directly to the server usually isn’t seen as necessary for the function of the server.

[-]

tobascodagama@reddit

Winget does support adding sources, like other package managers. A source is basically just an HTTP server hosting the manifests and installers, so it's easily doable if desired.

[-]

One_Target2740@reddit

Winget normally pulls package manifestos from the public repo maintained by Microsoft. Google winget repo and look for your apps under manifestos. Extremely useful when managing multiple apps, can be used in Powershell scripts and packaged as a win32 app, and allows you to maintain applications up to date with minimal effort. I've seen some Security teams frown upon it, but I don't see it as more or less harmful than downloading an executable from the vendor. Maybe I'm wrong? But I use it a lot when working on the Windows side of the fleet.

[-]

BlackV@reddit

but I don't see it as more or less harmful than downloading an executable from the vendor.

anyone can create an adobe reader package have have it install whatever (or could have)

would be the basic security issue, where downloading it from adobe.com is much harder to fake

[-]

SnooMachines9133@reddit (OP)

I'm intrigued by this line about being browned upon by security teams. I'll have to git a little more as I'm curious which environments those security teams work in and how the winget manifests differ from other repos like debian packages or pypi.

[-]

Frisnfruitig@reddit

Most enterprise environments I've worked at block winget for all users. They don't want users to be able to install anything and want full control on the endpoints. Users can install applications that have been approved and packaged by the the company, that's it.

[-]

arkaine101@reddit

I'm guessing it's because the WinGet repo doesn't host the actual binaries. It points to binaries hosted elsewhere (developers' websites, CDNs, GitHub, etc.).

[-]

BlackV@reddit

Short answer: Yes Long answer: No

[-]

BlackV@reddit

"communinty" based packages
per user winget (i.e. running as admin/system account problematic)
powershell support is secondary
enterprise support si very lacking
server OS? hello someone still have tin

[-]

AMoreExcitingName@reddit

Linux has had apt and yum for literally decades. So conceptually not new. Just somewhat new for windows.

[-]

420GB@reddit

Arguably it is conceptually new because winget is not the same thing. It's worse.

[-]

Tall-Introduction414@reddit

Further solidifying my decades-long theory, that Windows is a 50 year project to slowly recreate UNIX.

[-]

Cyhawk@reddit

slowly recreate UNIX.

Those who don't understand Unix are condemned to reinvent it, poorly.

[-]

ddesla2@reddit

cat /dev/lol

[-]

Master-IT-All@reddit

Not sure if you know the irony of that statement.

Before Windows, Microsoft was the largest distributor of UNIX.

[-]

Tall-Introduction414@reddit

Oh yeah. I know. I still have some Xenix manuals around here somewhere.

In 1984 Tandy shipped more UNIX systems than anybody, running Microsoft Xenix.

And MS-DOS, while basically a descendant of CP/M, took a lot of tricks and inspiration from UNIX (like pipes, a hierarchical filesystem, and stdin/stdout redirection).

I always thought it was an impressive feat getting UNIX running on an 8086. No real multitasking, though.

[-]

brokenpipe@reddit

It’s not that new for Windows. I’m dating myself here but I was a happy user of Cybermedia’s Oil Change in the mid 90s that would do this to my Windows 95 and later, 98, machine.

[-]

SnooMachines9133@reddit (OP)

I know. I use debian / ubuntu for my linux systems. And brew on mac. And various other package managers for npm and such. I've just never realized there was this for Windows.

[-]

gentoorax@reddit

winget, Linux has basically had this since the 90s, it's kind of amazing it's taken so long

[-]

Cyhawk@reddit

Winget and Chocolatey have been around for quite a while. Problem is its poorly maintained in some places.

[-]

gentoorax@reddit

Something like apt has been around much longer than both Chocolatey and winget by decades.

[-]

Cyhawk@reddit

Oh i know. Windows is 20 years behind nix in terms of features and security, always has been.

[-]

ZeeroMX@reddit

I've had many troubles to even update PowerShell via winget.

The last 2 or 3 updates to it I did a manual download and install, because winget said PowerShell wasn't installed or there was no updated version.

Chocolatey and scoop work better with some packages like PS, but hey are not available by default in windows.

That and the fact that until windows 2025 winget wasn't available in windows server versions.

[-]

Elavia_@reddit

I stopped using it after it updated an app I didn't install with it, to a version I didn't have the license for, with no easy way to rollback.

[-]

The82Ghost@reddit

Aside from WinGet, you should look at Chocolatey, does the same but works better, also if you're planning on using it in a business environment: do not use the public repositories! Just host your own so you are in control of what versions are available. You do not want to install an update to find out the update has a bug or was compromised.

[-]

TKInstinct@reddit

I love it, it's made my life so much easier.

[-]

ImUrFrand@reddit

you should try a spin on a linux machine, besides just apps, updates also cover drivers, kernels, configs...

you don't even need to reboot.

[-]

unavoidablefate@reddit

Not available natively on Windows Server before 2025, but that can be fixed.

[-]

pc_load_letter_in_SD@reddit

Use this for all your machines you manage....

https://github.com/Weatherlights/Winget-AutoUpdate-Intune

[-]

BlazeReborn@reddit

You beauty.

I'll have a look at that later.

[-]

JustMeClinton@reddit

Microsoft Intune for Device Management. PMPC Cloud for Third Party Updates.

[-]

joshghz@reddit

It doesn't always work properly, and there's a component it needs to download before it works.

There's a script I've used in my environment called WingetAutoUpdate that can be configurable through GPO, which was handy.

I use it a lot for myself, personally, but in a managed environment there's a lot of other tools that do it better for the most part.

[-]

--TYGER--@reddit

I used to keep a script of winget commands to install all my tools on a new PC, but it's only like 75% reliable.

The big flaw in its design is that it depends upon external providers to provide the installer binaries on specific URLs. While winget (Microsoft?) has to keep the core command line app up to date to point at those installer binaries.

I've since switched to chocolatey which has been more reliable.

[-]

AcidBuuurn@reddit

If you use the .json file and the import command it is over 90% reliable.

[-]

ddesla2@reddit

Environment variables?

[-]

Chungus-Galactic@reddit

Winget is probably better than nothing, and you can run it as System if your script includes the path to the executable.

BUT, packages are often not current and there’s no real reporting. It’s not a replacement for a real patch management solution.

[-]

jmnugent@reddit

It all depends on where the App was originally installed from, yes ?.. I ran the "winget upgrade --all" today on my personal laptop and I think it offered 8 Apps that had updates. (but I have many many more than that installed) I'm sure some of them did not have availble updates. Others (for example Radiacode for my handheld radiation detector) does not ever show up there.

[-]

simonides_@reddit

Nice tool until you look at details, our company auto updates all software the users install with winget. However, as soon as the update runs it installs everything back to default.

Eg vs code no longer has open with in the right click menu. This means we spend time fixing this broken behavior.

[-]

Master-IT-All@reddit

Old school admin in me says, "What install for users!? Applications belong to the device! Company Portal Optional Apps, UNTHINKABLE! Autopilot is shit."

The new school admin in me says, "Bro, apps belong to the user, the device only needs an OS and Internet connect for identity and data. Autopilot that shit."

[-]

techguyjason@reddit

I'm a fan of Winget-AutoUpdate-aaS and we deploy and configure it in intune.

[-]

SecrITSociety@reddit

If you like the concept of winget, checkout intunepkgr 👍

[-]

PrincipleExciting457@reddit

Winget is the MS supported packer manager. I personally preferred chocolatey when I used windows. Since chocolatey is a public manager though, there is always risk of using it, but it’s mostly fine.

But yes. It basically handles packages like Linux. With chocolatey I know the app had to be installed using the manager to be updated.

It is literally as simple as running one line of code to update all of your packages though. The nifty thing is exporting the config. Next time you do a refresh, just import the config and then bam. All apps are reinstalled.

[-]

coaster_coder@reddit

We have a business version and any version is capable of consuming packages from a repository feed you host yourself. Software on windows is bad enough, we try to make managing it at least suck a little less.

[-]

olcrazypete@reddit

Sounds like you’re missing homebrew on the Mac and any package management on the Linux side that has had something like this for decades. I remember there was another windows package manager- maybe chocolate? Played with it some when messing with writing ansible for windows.

[-]

urjuhh@reddit

Software X grts new installer on same url ( lets say office download tool ), winget repo is not updated with new hash ( for a day or two or three ... ) . And there you are, winget tells you to nope. There is a setting that you can change to ignore the hash, but you cannot then run it as admin for system-wide installation. Keeping system up2date - good enough. Trying to get software on fresh system - meh...

[-]