We are trying to address vulnerabilities in Appx packages, but per-user installs and older versions associated with accounts make cleanup frustrating. They do not show up like conventional desktop applications, either. How are people handling this across managed devices?
How are you managing WindowsApps and Appx packages across shared PCs?
Asked by
24x~fifo
Answers
Start by separating installed packages from provisioned packages. An installed package can be registered for individual users, while a provisioned package is set up for new user profiles. Removing one does not automatically mean you have handled the other.
Use the Appx PowerShell commands to inventory the affected package and its user registrations, then check the provisioned package list separately. Test removal or updates on a shared device first, including what happens for an existing profile and a newly created one. Some packages are dependencies, so check what relies on them before removing them fleet-wide.
Reply to this answer
If the devices are managed, look at the Windows app removal policy available through a configuration service provider. It may be a better fit for removing supported built-in apps across the fleet than maintaining a separate removal script for every machine.
Check the policy's supported apps and Windows requirements first. It is not necessarily a fix for every Store package or every old registration.
Reply to this answer
I would be very cautious about taking ownership of WindowsApps and deleting folders. The files and package registrations are separate pieces, so deleting the files can leave the package listed without actually cleaning it up. Editing the package database directly is another risky workaround, not a normal uninstall path.
Try the supported package removal and update mechanisms first. If a particular package is stuck, collect its name, version, user registrations, and the exact error before deciding how to repair it.
Reply to this answer
Before removing a flagged package, check whether updating it resolves the finding. A shared component or codec may be needed by another app, and an old version on disk is not by itself enough to tell you which users still have it registered.
Compare the scanner finding with the package inventory, then verify the result after remediation. That gives you something concrete to investigate when the scanner still reports an older version.
Reply to this answer
The packaging model is trying to provide things like app isolation and per-user management, rather than behaving exactly like a traditional desktop installer. That can be useful, but it also means the old uninstall registry is not a complete inventory for these apps. Your reporting and cleanup process needs to account for both models.
Reply to this answer
Add your answer
Answers are reviewed before publication.
2stamps_and_a_plan:
That distinction helps with stale profiles too. Check which users still have a registration before assuming an old package can simply be removed.