Allow install and uninstall of Windows features\capabilities

[toxicbubble]

It would be nice to have a bridge into the Add-WindowsCapability, Add-WindowsFeature, and Add-WindowsOptionalFeature systems. Presently a particular bit of software could be in any of these three. It would be awesome to be able to do:

winget install Hyper-V
winget install RSAT
winget install Netfx3

And have it just work. Bonus points if it works on both desktop and server platforms (WindowsFeature on servers and WindowsOptionalFeature on desktops). The value of a tool like winget really comes when it can handle installations from all previous channels in one place, i.e applications can then depend on .Net3 and just let winget resolve during installation.

I would expect running this through winget to only apply to the local machine, so -online would be implied when called from winget.

Ideally it should also handle install sources correctly to allow downloading from Microsoft to get the packages, even if HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\UseWUServer is set which could otherwise cause the install to fail.

[WSLUser]

If your machine is configured to use WSUS, then the package manager must also fetch updates from WSUS. I hope I am misunderstanding in that you want winget to bypass this security feature that enterprises use for a reason.

[toxicbubble]

OK perhaps I explained that that poorly, I guess what I mean is I would love if winget could handle the sources itself. If you specifically call winget to install a piece of software, it's implied that you want to download that package anyway.

So perhaps if you do winget install RSAT, winget can download the source packages itself (verify the hashes) and use those for the install. That just makes winget 'self contained' like it would work for a traditional MSI installer. Most other packages are already downloading content to install, so I don't see this as different from that.

Add-WindowsCapability has a -Source switch to use local files already, so it should be possible?

[denelon]

This is likely to be implemented when we support dependencies.

[doctordns]

That has to include group policies or other tools to control that. IT teams are often responsible for hosts and need the ability to control user system. If winget will allow anyone to reconfigure their hosts in any way with override, then IT will declare it inappropriate and forbid its use.

This feels like more scope creep.

[denelon]

The Windows Package Manager would not be able to override Group Policies or MDM. We're also working on the definitions for the policies related to the Windows Package Manager. IT administrators will be able to control the Windows Package Manager as well. We will be sharing those policies in the very near future so they have time to understand and decide what policies to implement before GA.

[doctordns]

I have had a thought about Group Policies I'd like to see. I'd like to ensure that IT Pros have complete control over what a developer can do with winget. I accept you will not be doing cmdlets but a good set of GPO policies would be helpful and offer IT Pros more control over what developer can do on their domain joined machines.

Here is a list of Policies you might want to consider:

1. Enable Winget - enables a user to user WInget or not. If disabled, overrides all the rest.
2. Enable Winget as Admin - enables a user to use WInget but only in an elevated console - this forces a user to have to elevate to use WInget
3. Enable WInget to install only from MS Store
4. Enable WInget to install from only certain package repos - so allow to install from Chocolately but not from other external package reports. This would need an array of Package Repo URLs or similar
5. Enable WInget to get the packages but not install or update for non-admin or admin user
6. Enable Winget to update packages only for non-admin or admin user
7. Enable user to delete/remove a package
8. Enable internal package repos - take an array of UNC names
9. Enable the use of Winget to install into the Windows folder - this would enable IT Pro to stop any installation that installed into the Windows Folder or below but would allow installation into Program Files or user folders
10. Enable the use of Winget to install in Program Files or Program FIles (x86) - this would enable IT Pro to stop any installation that installed into the Program Files folders (but allow in user-specific folders)
11. Enable the user to make use of Winget Experimental features - including possibly disabling winget features to show any experimental features
12. Enable the HASH verb -enable a user to use winget hash
13. Enable the Validate verb to be used
14. Enable the installation of .ZIP packages
15. Enable the installation of .MSI packages
16. ENble the installation of .EXE packages
17. Enable the installation of .MSIX packages
18. Enable WInget on Workstations or servers or both -you might combine this with the first item

Some of these admittedly overlap but can give an Admin fine-grained control. SO enable the store, and Chocolately, but only for MSIX packages for example.

The policies should be both computer and user policy settings under Administrative Templates. That would mean creating the ADMX/ADML policy files for V1 as well. That would allow testing of these settings by just setting local registry settings in the absence of an actual GPO.

I hope this drives the discussion on what is needed for V1.

[denelon]

@doctordns would you mind adding that to #154 Support for Group Policy Management? I'll add what we're currently looking at there.

[toxicbubble]

If your machine is configured to use WSUS, then the package manager must also fetch updates from WSUS. I hope I am misunderstanding in that you want winget to bypass this security feature that enterprises use for a reason.

I guess I didn't explain it that well but what I mean is:

If I do a winget install putty then I'm telling winget I want it to download the PuTTY installer and install it for me. If I do a winget install RSAT then I expect the same. Bypassing group policies isn't the intention but I don't think failing because the RSAT packages may not be available through a WSUS instance is the best behavior (e.g. see this thread where RSAT couldn't be approved in WSUS)

Maybe it's best if winget should download the cab files itself (which are available now in the FoD ISO) from a Microsoft URL and run the install script with the -Source switches to install it. This effectively makes winget in charge of sourcing the installer content regardless if it's a exe, MSI installer, or a WindowsCapability.

[Trenly]

@denelon - does this duplicate:

• Turn Windows features on and off #556

[denelon]

This one includes server and I don't know if the initial PR for:

• Turn Windows features on and off #556

covers this issue fully.

[ryfu-msft]

For standalone enabling/disabling windows feature, this might be better to be its own command/workflow.

Something like:
winget feature --enable netfx3
winget feature --disable netfx3

[denelon]

Support for enabling WIndows Features as a dependency has been implemented in WinGet 1.7.