Uninstall/Reset/Repair Tasks

[DrusTheAxe]

Proposal: Uninstall/Reset/Repair Tasks

Summary

Provide an uninstall hook for custom activity equivalent to windows.preinstallConfigTask
and windows.updateTask.
Also potentially provide similar support for 'repair' and 'reset' operations.

Microsoft-internal task 34863092

Rationale

Packaged apps have the opportunity to have code run when a package is installed or updated via the
windows.preinstallConfigTask or windows.updateTask but have no equivalent option when a package
is uninstalled.

Applications can write data outside locations known by and managed by the Deployment stack (e.g.
locations under HKLM). Processes running in an AppContainer have constrained access to the system
so data is readily handled by Windows when a package is deregistered but MediumIL and elevated
processes can (and often do) write outside these managed locations. As a package can be removed
without the package's direct involvement a mechanism is needed to enable these apps to remove
data written to places or ways unknown to the Deployment stack.

'Reset' needs similar support. A 'reset' operation is functionally equivalent to
packageManager.RemovePackageAsync(p, RemovalOptions.PreserveApplicationData) but the package
package directory is not deleted followed by packageManager.AddPackageAsync(p). As this is
similar to but not exactly 'uninstall + install' the work performed by an uninstall task
may be inappropriate. Although an uninstall task could have a parameter indicating
Reason=<Remove|Reset> a separate specific task is simpler and more developer friendly.
In addition, the currently install/update task model is a separate task and
appxmanifest.xml schema.

A 'repair' operation is functionally equivalent to packageManager.RegisterPackageAsync(p) for a
package already registered to a user. However, register operations also occur for a loose file
package so there's no clear task to invoke for 'repair' scenarios. A windows.repairTask solves
this ambiguity.

Uninstall tasks must occur after a deregisteration operation is requested but before any
deregistration work can be performed. Thus, uninstall tasks are blocking operations. Similarly,
repair tasks are blocking operations. These should be time bound to prevent unconstrained delays
e.g. an uninstall task running for an hour would be a poor user experience.

Reset tasks are non-blocking to the Deployment pipeline. This occurs after Deployment work is
completed like a windows.updateTask. The latter have no time constraints imposed by Deployment
so reset tasks shouldn't need any Deployment imposed time constraints.

Scope

Capability	Priority
Support a windows.uninstallTask invoked when a package is deregistered for a user	Must
Support a windows.repairTask invoked when a package is repaired for a user	Must
Support a windows.resetTask invoked when a package is reset for a user	Must
Time bound windows.uninstallTask execution	Should
Time bound windows.resetTask execution	Should

Important Notes

Links to related discussions:

• Discussion: Adding support for new features to MSIX manifests #16
• Does Windows App SDK need better support for periodic background tasks? #2322

Open Questions

N/A

[riverar]

[from rationale] As a package can be removed without the package's direct involvement a mechanism is needed to enable these apps to remove data written to places or ways unknown to the Deployment stack.

MSIX guarantees a clean uninstall, so what data are you referring to here? Sounds like if there's untracked data as suggested, this is a MSIX bug.

I'm very concerned this is being requested for a partner to pop open a web browser for some tracking, analytics, exit survey, and/or other generally unwanted behavior.

[DrusTheAxe]

MSIX guarantees a clean uninstall, so what data are you referring to here?

Packaged apps can run MediumIL and elevation which can (and do) color outside the lines. For example, some unpackaged apps have extensibility or integration models requiring regkeys or files be written in places not managed by the Deployment stack. Apps running at >=MediumIL can write to these locations, but have no reliable mechanism to remove that data when their package is removed.

Sounds like if there's untracked data as suggested, this is a MSIX bug.

There's a lot of data across Windows (the OS and ecosystem) which isn't managed by MSIX that some apps need to modify. Some of these are impossible for MSIX to properly manage without breaking impact to these unpackaged apps so either there's zero unpackaged apps (only packaged) or we need a way to support these older mechanisms. The former doesn't seem likely anytime soon 😋 so this is a necessity for healthy systems.

I'm very concerned this is being requested for a partner to pop open a web browser for some tracking, analytics, exit survey, and/or other generally unwanted behavior.

Can a BackgroundTask pop open a web browser to engage in these activities today? That's what windows.preinstallConfigTask and windows.updateTask work today, they activate a manifested background task. Can a background task be defined imperatively (no manifest) and pop open a web browser?...

These uninstall/repair/reset tasks wouldn't enable these actions any more than possible today.

Also, this has been requested by other teams before (via other channels). The need/priority hasn't risen 'above the line' to act on it so far, but times and needs can change... This enhancement request is vFuture/backlog, noted to gather feedback and consideration in planning cycles yadda yadda all the usual reasons. Feedback is welcome - on all facets: functionality, restrictions, need, ...

[riverar]

The existing windows.preinstallConfigTask and windows.updateTask tasks seem to be targeting OEMs/MOs (akin to a rescap). Do you know if that's enforced? If so, should this task also have the same restrictions?

[DrusTheAxe]

The existing windows.preinstallConfigTask and windows.updateTask tasks seem to be targeting OEMs/MOs (akin to a rescap). Do you know if that's enforced?

windows.preinstallConfigTask is restricted to provisioned (and inbox) packages. OEMs often provision packages but so do others (eg enterprises). Anyone can declare it, but it's only acted on if the package is provisioned (or inbox).

Anyone can provision a package via PackageManager.ProvisionPackageForAllUsersAsync(), the Powershell cmdlet Add-AppxProvisionedPackage or dism.exe if they have admin privilege. At that point you p3wn the machine anyway so there's no added threat.

windows.updateTask has no such constraint. Any package can declare it and it'll be invoked when a user's registered packaged is updated. No provisioning required, not any capability as I recall.

If so, should this task also have the same restrictions?

What do you think?

[dongle-the-gadget]

I think that there should also be an option for the uninstall action to run as administrator. Either by having something like RunAsAdmin="true" or allowing the uninstall app to elevate itself on launch.

As for the restrictions, I feel like runFullTrust (and allowElevation for the 'run uninstaller as admin' scenario) should be enough.

[DrusTheAxe]

https://task.ms/34863092

[andy-schmidt]

This looks awesome, we really could use this functionality. This is a definite improvement over using the customInstallActions restricted capability. See also MicrosoftDocs/winrt-related#194

What is the status on development of this feature?