winget support for supported Windows Server, Azure Stack HCI editions

[Karl-WE]

Description of the new feature/enhancement

Currently there seems to be zero support for winget on Server vNext based on my testings.

Proposed technical implementation details (optional)

please support following OS
Windows Server 2019 LTSC with or without Desktop Experience
Windows Server 2019 SAC
Windows Server 2022 SAC
Windows Server 2022 LTSC with or without Desktop Experience
Azure Stack HCI

usecase:
deployment of applications such as VC++ Redists (also security related) for Applications, PowerShell, .net / .net Core, MSIX Apps (Windows 10 21H2 aka Windows 11 does support them now without sideloading)
deployment of applications for RDSH / Citrix VAD
I understand MSFT promotes WVD, but it is not yet broadly deployed in Germany especially not in SMB / SME.

[doctordns]

Please do not add winget to Windows Server. Until there is good Powershell coverage, winget is not appropriate for servers. The tool is a possibly great power toy for developers, but should not be put on servers.

[Karl-WE]

I cannot agree with you @doctordns . from my experience the winget is not a tool for devs.

I have contributed a bit to the idea and discussion of supporting native powershell commandlets but this is another issue #221 and no dependency.

If one want to script server deployments of Servers with a good set of applications, what is the critical drawback except syntax and missing #121, which could be done using Powershell or WMIC.

If the metadata is handled correctly, also upgrades of existing apps work great already.

I do not have a big difference in mind between Windows Server and Windows Client since they have a very similar core OS and the only reason why this PR might not be fulfilled is the nature of LTSC and its limitations, both clients and servers.

Can you elaborate what makes it "not appropriate"

[doctordns]

We may have to differ, but in my 50 years of experience, servers are for servers not for developers to add apps to. There are some server apps that you install using an exe, but I doubt that SQL server, Exchange, or SPS are going to want their installers in the store or a separate winget repository. I think it way too early to ask the dev team to take this into server. Today.

What is WMIC (YES, a rhetorical question)? PowerShell replaced this tool a decade ago. :-)

Winget does not have support for enterprise deployment - no cmdlets, no group policies, and a UI that just ignores nearly 20 years of PowerShell. Winget is much harder to script, for example. If the team produces rich cmdlets, this point may go away. The recently posted JSON schema is a good start, but there is a long way to go.

I love the concept of Winget for developers to get all those little apps onto their dev machines, but even then there is not auditing or GP protection. Also, there is no MS Store on servers (IMHO a good thing) making it that much harder (I think).

And finally, what is the drawback? Winget is not controllable by GP or manageable with PowerShell, it does not have wonderful help and no tab completion - in short not much for the IT pro. Yet. It is still very, very early in development.

Given the lack of progress on Winget, I would wish to wait to see what the 1.0 release is like. THEN ask for winget on servers. The dev team has enough on their plate just to get this out the door. I could consider this for 2.0 once we see what 1.0 looks like.

[Karl-WE]

While I understand your point of views that you also brought up in other discussions not all of your assumptions are right.
Windows Admin Center is using WMI and or powershell to get the data. I am not saying this is good because WMI is slow yet not everything can be fetched by a commandlet. And even commandlets / modules use CIM. I am not an expert of automation and you see to have more expierence on big enterprises from your statements. Yet the integration of winget is something that should not be client only especially since the strategy is GUI less server many application have no good installers. Recently stumbled across a Sophos log collector. These apps do not need a GUI to work it is, when installed only Windows Service.

winget and packaging would be sufficient to install these.

I just want to make clear we cannot pretend all servers have GUIs and all server applications have great installers, nor each want to repackage them. Sure there are other tools like patchmypc, configmgr, yet there is no one fits all. winget is suitable for small business for sure.

as for GPOs. installing apps via winget is just a tool to install and update packages (silently) with yet few controls due the early stage. If I install Adobe Reader there is no automatic GPO included so this is a matter of the developer to do these and not related to how I install it. Infact winget is much easier than fiddling with msi and mst.

I think we both brought our pros and cons and let us see what the Windows Server team decide, I think they would have to do more on that part than the winget team just guessing.

[doctordns]

Agree that WAC can do stuff using PowerShell cmdlets (not commandlets) and WMI. There is very, very little you can't do with WMI and PowerShell. although there certainly is some (I have written three books on managing Windows Server with PowerShell and WMI (via the CIM cmdlets) and have some experience there.

As for WAC, yes, it can and does do stuff with PowerShell, but that is not easily transformed into easy to write automation. I totally agree WMI is not highly performant.

I think you make the excellent point that the command line is a better environment for repeatable automation. :-) but even then, there are "applications" that do not have any command line installer. I am thinking about the HP printer drivers, for example. Not sure what winget can do to help there, but you raise an interesting issue which is separate from the question of winget on servers.

Also, and here I may be wrong, but doesn't winget make use of the Store?

As for GPOs, suppose I do not want devs updating the server with random new shiny tools? GPOs would be a way to prevent that. You make the point that there are things I really do want to stop people installing and winget provides no protection. There is a GPO milestone so the team, rightly, is thinking about that.

Right now, the team has to concentrate on a 1.0 version and has to make a success of that at the client side. If/when that occurs, and we have good powershell support, maybe look at moving it server side.

[thuannguy]

In my organization, we usually need to develop server applications on development machines that run Windows server. Installing a new development machine using Winget is a great option for us.

[alazare619]

organizations with rds farms ctirix farms or vmware horizon farms would benefit drastically from this

[szakib]

My plan was to use winget (and some other tools) to make a script for development environment setup that would be used both by developers and build machines. It would be a great way to make sure that the environments match exactly. I could have spared quite some effort by winget exporting an initial package list from a developer's setup. I'm not doing any of this today, apparently.

@doctordns I very much disagree with you that this does not belong on servers. Yes, there are other ways to achieve the same, but this is faster, simpler, and it could also end up being better in the long run.

[Karl-WE]

organizations with rds farms ctirix farms or vmware horizon farms would benefit drastically from this

even more as we could use MSIX (with App Attach in Server 2022 LTSC) and even local repos if needed,
Winget does leverage Delivery Optmization which is ace for Azure Virtual Desktop as well as RDSH and Citrix VAD deplyoment.

[Karl-WE]

Current workaround:
https://www.andreasnick.com/112-install-winget-and-appinstaller-on-windows-server-2022.html

[alexchandel]

Please support Server 2022. The current situation is insane. The primary use case of winget is servers. As almost every commenter has said, most development and operations happen on servers.

It is truly mind-bending that time and time again, you develop such useful things, then botch the distribution so thoroughly as to render them nonexistent.

[Karl-WE]

@alexchandel I believe that @denelon and the team have problems to bring winget to Windows Server 2022, he explained the point of dependencies (technical and support) that are not in his hands (other PGs). It is likely comparable to the new RFC from the PowerShell Team to sideload PowerShell 7.x as it cannot be integrated into a GAC (SAC) or LTSC release.

Afaik the Windows Server support is still on the roadmap and so our hopes are still alive.

[denelon]

We do want to bring the Windows Package Manager to as many SKUs as reasonably possible. I don't have any timelines, but we have started discussions. It's unlikely we will go any further "down level", but I would love to be able to offer the product on every current version of Windows we can support.

[jbolduan]

We're using winget to detect versions and build packages for MECM. Without server support I essentially need a Windows 10/11 "server" to handle this. Having support for Windows Server would allow us to simply leverage existing servers and is preferred.

[mthalman]

I see no mention of Windows containers in this thread so I'll throw that in as another use case. It would be great to have a Windows Dockerfile authoring experience that mirrored Linux with its ease of adding software packages. A case could be made for including the winget CLI in the base Windows container images.

[denelon]

Docker/Container related issues:

• Build winget in a container #669
• Docker and Server installation instructions #438

[denelon]

We're using this discussion to track business requirements for Windows Server support.

[Karl-WE]

Hi all, good news.

In addition to the contributions by @ItzLevvie,

@likamrat shared a gist for winget deployment on Windows Server 2022 (and probably vNext).

This got published recently by himself via LinkedIn and I am sharing this to you with his consent.

Hope it helps you to ease things, as long it is still unsupported.

https://gist.github.com/likamrat/cae833a6e5b3461709f14c093c21c293
Cc @denelon

[AlexDev404]

A much shorter workaround for this is available.
See: https://stackoverflow.com/a/75794127/10976415

[denelon]

We've been making progress on getting support for WinGet on Windows Server. There are a couple of different fronts here. One is the update mechanism for servicing WinGet on Windows Server. This will be a long lead time workstream as it requires OS changes.

The other front is the "Repair-WinGetPackageManager" cmdlet for installing App Installer (containing WinGet) and the dependencies. This work is progressing well.

[Karl-WE]

thank you for the update on this @denelon. After some good, yet unsupported, automation how to deploy winget, I can tell it is worth the effort. It does a great job on Windows Server 2019 and 2022 / vNext.

[denelon]

Hey everyone,
WinGet is in Windows Server 2025 Preview Build 26063.
"Announcing Windows Server Preview Build 26063"