Microsoft’s Store client has quietly gained a small but practical capability: you can now uninstall apps that the Store manages directly from the Store’s Library page, and Microsoft has paired that consumer-facing tweak with a new, supported device-level policy in Windows 11 25H2 that lets administrators deprovision a curated set of in‑box Store packages across devices.
Background
For years Windows app lifecycle tasks have been split across multiple surfaces: the Microsoft Store to acquire apps, Settings → Apps to remove them, PowerShell and DISM for scripted or image-level operations, and management tools like Intune for enterprise control. That fragmentation created friction for everyday users and brittle maintenance burdens for administrators who tried to keep corporate images clean. The recent Store change and the new policy in 25H2 are modest but deliberate moves to make lifecycle operations more consistent and more auditable.
These changes arrive as part of staged preview rollouts targeting Windows Insiders and Windows 11 25H2 previews, with server-side gating on the Store client and a curated policy surface for enterprise deprovisioning. The approach is incremental: a UX refinement for consumers and a management-grade control for IT teams.
What changed in the Microsoft Store (consumer UX)
The Library uninstall: what it is
The Microsoft Store’s Library page now exposes an
Uninstall action for Store‑managed apps. The option appears in the familiar three‑dot (⁝) menu next to an installed app in Library, letting users remove the app without opening Settings → Apps. That closes a small but long-standing UX gap where users had to jump between apps to perform simple lifecycle tasks. This change mirrors how mobile app stores and many modern desktop stores let you manage installs and removals in the same surface where you discover and update software. The result is less context switching and quicker cleanup of temporary installs, trials, or apps that were installed during testing.
How it looks and how to use it
- Open Microsoft Store and choose Library from the left pane.
- Find the installed app you want to remove.
- Click the three‑dot menu next to the app and select Uninstall.
- Confirm any prompts the app or Windows shows; the removal is processed by the Store/Settings flow.
If you don’t see the option, your Store client likely hasn’t received the preview update or the feature is still gated on the server for your device. The capability first surfaced in Insider previews and is tied to newer Store client branches.
Availability and rollout
Microsoft is rolling the feature gradually via Store updates and server-side feature gates; Insiders on preview Store builds are the first to see it. Reporting around the preview family references Microsoft Store builds in the 22510.1401.x.x branch and later for Insiders, although exact version strings and rollout timing can vary by ring and locale. If you’re not in the Insider program you should expect the change to appear later when Microsoft broadens the rollout.
Why this matters for everyday users
Small UX improvements compound when they remove repetitive friction. The Store Library uninstall gives everyday users a single, familiar place to both discover and manage Store apps. That is helpful when:
- You want to quickly remove a trial or test app you launched from the Store.
- You discover an app in Library and decide you no longer need it—there’s no detour to Settings.
- You prefer a single app-management surface rather than juggling multiple control panels.
Beyond convenience, the change standardizes behavior: Store-managed apps behave more like other desktop apps in terms of control and lifecycle. That parity is valuable because it reduces cognitive load and support steps for non-technical users.
The enterprise angle: policy-based removal in Windows 11 25H2
What Microsoft added in 25H2
Windows 11 version 25H2 introduces an ADMX-backed Group Policy and MDM/Configuration Service Provider (CSP) mechanism named
Remove default Microsoft Store packages from the system. This policy allows IT admins to select a curated list of in‑box Microsoft Store apps for device-level removal during provisioning events (OOBE, first sign-in after an upgrade, or when the policy is applied). The feature is designed to give organizations a supported, auditable alternative to fragile scripts, DISM image edits, or community “debloat” hacks. Key technical constraints:
- It requires Windows 11 version 25H2 or newer.
- It is targeted at Enterprise and Education SKUs (device-level scope).
- Admin surfaces include Group Policy (ADMX), Microsoft Intune (Settings Catalog), and an MDM CSP OMA‑URI for custom MDM payloads.
What the policy actually does
When enabled, the policy attempts to uninstall the selected Store packages from the device and blocks them from provisioning for new users. The removal is device-level (not per-user) and enforcement occurs at provisioning points to keep images and new accounts free from the targeted inbox apps. Event logging is produced so administrators can verify deprovisioning outcomes. Reinstalling a removed app requires clearing the policy selection and redeploying or reinstalling the app through the Store or management tooling.
How to configure it (high-level)
- Import the Windows 11 25H2 ADMX templates in your ADMX store if needed.
- Open Group Policy Management or Local Group Policy Editor.
- Navigate to Computer Configuration → Administrative Templates → Windows Components → App Package Deployment.
- Find and enable Remove Default Microsoft Store packages from the system, then choose the apps to remove from the presented list.
- Apply and scope the policy; test on pilot devices during provisioning or the next sign-in flow.
Intune administrators can achieve the same by creating a Device configuration profile using the Settings Catalog or Administrative Templates and enabling the equivalent setting. The policy also maps to an MDM OMA‑URI for enterprises that prefer direct CSP payloads.
Practical implications and caveats
Local uninstall ≠ permanent removal on managed devices
A crucial caveat for both users and administrators:
uninstalling an app locally—whether from Settings or the Store Library—does not necessarily prevent it from being re‑provisioned by OS provisioning flows or MDM policies. Devices governed by company provisioning, OEM recovery images, or management policies may see some apps redeployed automatically unless a supported device-level policy is used. For enterprises, the 25H2 policy is the supported mechanism for persistent device-level removal; for consumers and unmanaged devices the behavior depends on provisioning and local image state.
Policy scope is curated and intentional
The new policy targets a
curated set of Microsoft Store inbox packages. It is not a universal debloat switch that removes every preinstalled OEM or third‑party component. Vendors and administrators will still need image-level controls and supplier agreements to manage OEM bundles or third-party preloads. Treat the policy as a supported tool for Microsoft’s own Store packages, not a catch-all removal mechanism.
Availability differences across SKUs and rings
While some community reports show registry or vivetool ways to unlock features earlier, official support and UI surfaces depend on Windows edition and channel. The policy and some preview features are explicitly tied to Enterprise/Education SKUs and preview channels. Home and Pro users may not see the ADMX policy in the same way—Group Policy editor availability and ADMX templates matter. Administrators should plan testing on the correct SKUs and use controlled rings to validate behavior before broad rollout.
Security, telemetry, and governance considerations
Small changes to app lifecycle and provisioning can have outsized operational and compliance effects for organizations. When adopting the 25H2 policy or encouraging end users to remove apps from the Store Library, consider the following:
- Auditability: The policy produces event logs for removals; incorporate those logs into monitoring and device inventory checks to ensure expected state.
- Reprovisioning risk: If OEM recovery images or other provisioning sources re-add packages, evaluate recovery images and OEM contracts as part of your image management plan.
- Change management: Rolling out removal policies during provisioning can affect user productivity if a widely used app is included in the curated list. Pilot widely and communicate changes to end users.
- Telemetry and privacy: Removing apps reduces attack surface and telemetry points, but administrators should also verify that removal does not break telemetry or diagnostic pipelines used for support.
How this compares to previous removal methods
Before these changes, administrators and enthusiasts used several approaches with trade-offs:
- Settings → Apps → Installed apps — user-friendly but per-machine and not ideal for provisioning.
- PowerShell (Get-AppxPackage / Remove-AppxPackage) — powerful and scriptable but fragile across OS updates and package name changes.
- DISM and image surgery — effective for image-level control but brittle and error-prone, especially after feature updates.
- Third-party debloat scripts and utilities — flexible but unsupported and risky in managed environments.
The new 25H2 policy replaces many fragile, maintenance-heavy approaches for supported Store packages by providing a first‑party, auditable, and policy-backed mechanism. That reduces long-term support costs for items in scope while leaving complex OEM and third-party scenarios to existing image management processes.
Practical guidance — for consumers, power users, and IT
For consumers and Windows Insiders
- If you’re in the Insider program and your Store client is updated (Store preview branches around 22510.1401.x.x), check Library → three‑dot menu for Uninstall. If present, try it on a non-critical app first.
- If you don’t see the option, don’t force registry hacks—wait for the Store client rollout or join controlled Insider rings on a spare test machine.
For desktop support teams and help desks
- Update internal documentation to include the Store Library uninstall as a supported step for removing Store-managed apps.
- Train agents to check provisioning policies and MDM settings before promising permanent removal on corporate devices. Local uninstalls may be reversed by provisioning flows.
For IT administrators
- Pilot the 25H2 ADMX templates and policy in a controlled ring (test/dev).
- Import the 25H2 ADMX files if your GP console does not show the new setting.
- Validate the curated app list exposed by the policy and map those apps to business requirements.
- Deploy the policy to a pilot device group, monitor the Appx deployment logs, and verify the event IDs described in the docs.
- Incorporate registry and Sysprep checks into image validation to confirm removed packages persist across common provisioning actions.
Risks, edge cases, and unknowns
- Feature gating and fragmentation: Server-side gating means identical machines may experience different capabilities during early rollouts; assume heterogeneity when piloting.
- Incomplete coverage: The curated list may not include every app customers consider bloat; organizations will still need OEM conversations for vendor preloads.
- Preview fragility: Features observed in Insider builds can change before general availability; pilot in non-production environments.
- Retention and recovery concerns: If administrators lean on new recovery tooling in tandem with removal policies, ensure backup and BitLocker key escrow strategies are in place; some new preview recovery features are destructive to post-snapshot changes.
Where claims in community reports or early previews are ambiguous—such as exact Store build numbers on all rings or the final app list exposed by the policy—treat those as
temporary, preview-era observations and validate against the final Microsoft documentation for production decisions.
Verdict: meaningful, low-risk UX fix paired with a practical enterprise control
The Store Library uninstall is the sort of incremental,
quality-of-life improvement that benefits millions of users by reducing friction for common tasks. It’s intuitive, low-risk, and aligns Windows’ Store behavior with user expectations formed on mobile and modern desktop stores.
The 25H2 policy for device-level removal of default Store packages is a more consequential engineering change for IT: it replaces brittle scripts with a supported, auditable mechanism for removing Microsoft’s own Store packages from devices during provisioning. Its scope is intentionally curated, and it complements—not replaces—image-level management and OEM agreements. For organizations, this is an unequivocal net win when used correctly in tested rings.
Final recommendations
- Consumers: Try the new Store Library uninstall if it appears in your Store; it’s a safe, fast way to remove Store-managed apps. If you rely on managed devices, understand your organization’s provisioning rules first.
- IT pros: Pilot the 25H2 ADMX/MDM policy in test rings, validate the curated app list against business needs, and update provisioning and imaging playbooks to remove brittle post-deployment scripts. Monitor Appx deployment logs for verification.
- Everyone: Treat preview-era reports and build numbers as provisional. Confirm exact behavior and supported app lists against the official Windows 11 documentation and your management tooling before making broad changes.
This pair of updates—small consumer convenience in the Store and a supported enterprise policy in 25H2—represents an evolution toward more consistent, first-party app lifecycle management on Windows. They do not solve every “bloatware” problem, but they significantly reduce the operational friction for two of the most common use cases: quick user-driven cleanups and repeatable, auditable enterprise deprovisioning.
Source: Windows Report
Microsoft Store Will Soon Let You Uninstall Apps Directly From the Library