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