Ability to install/uninstall Appx Packages

[cohdjn]

Description

I see this module deals with Windows Capabilities but I didn't see anything that deals with AppX Packages. I don't know if this module is the right place for something like this but it seemed to be the closest I could find.

Proposed properties

Ensure = [Present,Absent]
Scope = ['AllUsers','PerUser']
RemoveAppxPackage = [$true,$false]
PreventReinstallFromWaaSUpgrades = [$true,$false]

Special considerations or limitations

The biggest problem might be figuring out what's safe to uninstall... unless we take the nix approach and assume people know what they're doing and just go for it (you can do an rm -rf / if you REALLY want to)? The next possible big problem is keeping current with what's per-user. I'm sure we can do a query to figure out if someone says "remove per-user Appx package X but it's not a per-user and we don't do it".

I haven't fleshed everything possible out on this but my immediate need is to remove Appx packages from newly minted Windows 10 machines along with making sure existing Windows 10 machines maintain a consistent configuration.

[PlagueHO]

Hi @cohdjn, this does seem like a resource that would be useful for installing/uninstalling desktop appx packages where appropriate. The gap is because typically DSC is used for configuration of Servers and so AppX packages aren't as commonly used there. Appx packages are also used to install packages into user scope. It also looks like the Appx commands are designed to add/remove packages to a user account - but DSC does not run under user account scope (usually).

We don't usually see DSC being used to configure Desktop OS -is this specifically to remove AppX packages?

[cohdjn]

Yes it's to remove Appx packages but it could easily be used for add them as well (RSAT comes to mind). Same general concept as WindowsFeature in that the package is either present or absent. I figure if I'm going to write something like this, it may as well handle removal and addition.

My particular use case is for deployment of new Windows 10 machines in a disconnected high-security industrial control system network. I'm trying to move my peers away from the "golden image" concept and move toward a "Next Next Finish" installation of the OS and using either GPO or DSC to install/uninstall/configure Windows 10. GPO/DSC allows us to install and maintain software but it doesn't address some of the underlying "bloatware" that comes with Windows 10 in the form of Appx packages.

[PlagueHO]

To maintain state, we would probably need to be able to add a package as well. What happens if the Add-AppXPackage and Remove-AppXPackage cmdlets are run in the same account scope that the LCM normally runs?

[cohdjn]

I'm not sure. If I understand your question correctly, authors could use PsDscRunAsCredential to change the account scope as needed. Alternatively, I'm not sure it completely matters. For example, if I want to uninstall the Weather app and install the Stocks app (just using a silly example), I don't readily see an issue with Add-AppXPackage and Remove-AppXPackage being used in the same account scope.

I feel like I'm missing something in your question? Maybe I don't really understand what you're asking?

[PlagueHO]

What I was mostly thinking was that this resource would only ever run in a user context - e.g. if it ran in the System context (what the LCM typically runs as) then it would likely fail. The exception would be for Remove-AppXPackage - which could run under System scope if -AllUsers was specified.

That really just means we'd need to document the use cases and exceptions (e.g. specifying PsDscRunAsCredential or running the whole config under a user account - as per DSC in PS7) - as I think this resource would mainly target desktop installations (rather than Windows Server).

Could we get the MOF defined here to figure out what it might look like?