Microsoft has finally given IT administrators a supported, first‑party way to remove selected preinstalled Microsoft Store apps from Windows 11 devices: a new device‑level policy in Windows 11, version 25H2 that lets Enterprise and Education organizations pick which inbox Store packages to deprovision centrally via Group Policy, Microsoft Intune (Settings Catalog) or MDM/CSP.
For years, organizations have used brittle scripts, custom images, or third‑party “debloat” tools to strip consumer‑focused inbox apps from corporate images. Those approaches were fragile: package family names changed, provisioning behavior differed across builds, and major feature updates could re‑provision apps, requiring repeat work. Windows 11 version 25H2 addresses this operational pain by introducing an ADMX‑backed Group Policy and a corresponding Configuration Service Provider (CSP) that explicitly remove selected default Microsoft Store packages from the system at the device level.
This policy is delivered as part of the Windows 11 25H2 servicing/enablement rollout and is available to devices running Windows 11 Enterprise and Education, version 25H2 (or later). The policy is off by default and must be explicitly enabled and configured.
<data id="WindowsCalculator" value="true"/>
<data id="Photos" value="true"/>
<data id="MSTeams" value="false"/>
(Where value="true" requests removal for that package on the device.) Always obtain the official XML template from your management console or Microsoft documentation for the 25H2 build in your environment before pushing payloads.
However, this is not a silver bullet. Early community testing and pilot reports highlight UI artifacts (dead Start tiles), the device‑level scope that complicates cleanup for existing profiles, and the need to validate ISV/agent compatibility. These are practical, solvable issues — but they require the same disciplined pilot and ring deployment cadence IT teams use for any platform change. Treat Release Preview/early availability as your validation window and proceed with measured rollout.
Source: Windows Report Preinstalled Microsoft Store Apps Can Now Be Removed With New Policy
Background
For years, organizations have used brittle scripts, custom images, or third‑party “debloat” tools to strip consumer‑focused inbox apps from corporate images. Those approaches were fragile: package family names changed, provisioning behavior differed across builds, and major feature updates could re‑provision apps, requiring repeat work. Windows 11 version 25H2 addresses this operational pain by introducing an ADMX‑backed Group Policy and a corresponding Configuration Service Provider (CSP) that explicitly remove selected default Microsoft Store packages from the system at the device level. This policy is delivered as part of the Windows 11 25H2 servicing/enablement rollout and is available to devices running Windows 11 Enterprise and Education, version 25H2 (or later). The policy is off by default and must be explicitly enabled and configured.
What the policy does — the essentials
- Scope: Device‑level removal (not a per‑user uninstall). This means the setting prevents apps from provisioning for new or future users on the device and attempts to remove existing installations and local app data where possible.
- Applicable editions: Windows 11 Enterprise and Windows 11 Education, version 25H2 and later. Pro and Home are not the targeted management surfaces for this policy.
- Deployment surfaces: Group Policy (ADMX), Microsoft Intune Settings Catalog, and the MDM CSP at the OMA‑URI:
./Device/Vendor/MSFT/Policy/Config/ApplicationManagement/RemoveDefaultMicrosoftStorePackages. - When enforcement runs: During OOBE (first provisioning), when a user signs in after an OS upgrade, or when the policy itself is updated — aligning removal with normal provisioning and upgrade flows.
- Cleanup behavior: The system deprovisions the selected packages and removes local app data during the enforcement events. Event logging is available for verification (see “How to verify” below).
Which apps can be removed today
Microsoft shipped the policy against a curated list of inbox Microsoft Store packages intended to cover common consumer/out‑of‑box apps that enterprises often want removed. Examples of supported apps include:- Calculator, Paint, Notepad, Photos, Camera, Snipping Tool, Sound Recorder, Windows Media Player, Windows Terminal
- Microsoft Teams, Microsoft 365 Copilot / Microsoft Copilot (consumer), Microsoft Clipchamp, Microsoft Photos, Microsoft News, MSN Weather
- Microsoft Sticky Notes, Microsoft To Do, Microsoft Solitaire Collection, Outlook for Windows
- Xbox Gaming App and related Xbox components (Xbox Identity Provider, Xbox Speech to Text Overlay, Xbox TCUI)
- Feedback Hub, Quick Assist, Windows Camera, and other inbox Store experiences
How to configure the setting (practical walkthrough)
Group Policy (ADMX)
- Open Group Policy Editor on a management machine or domain controller.
- Navigate to: Computer Configuration → Administrative Templates → Windows Components → App Package Deployment.
- Locate "Remove default Microsoft Store packages from the system" and set it to Enabled.
- In the policy options, select the checkboxes for each inbox Store app you want removed (the UI enumerates the supported packages).
- Apply the policy to the target OU or machines and allow Group Policy to refresh; removal executes during the next applicable enforcement event (OOBE, upgrade, or sign‑in).
Microsoft Intune (Settings Catalog) — recommended for cloud managed fleets
- In the Microsoft Intune admin center create a Device configuration profile (Platform: Windows 10 and later → Settings catalog / Administrative Templates).
- Add the setting path: Administrative Templates → Windows Components → App Package Deployment → Remove default Microsoft Store packages from the system.
- Set the policy to Enabled and toggle the listed apps to True to remove them (or False to keep).
- Assign the profile to device groups. The underlying CSP OMA‑URI used for custom payloads is the same one used for direct MDM configuration.
Direct CSP / OMA‑URI payload (custom)
- OMA‑URI: ./Device/Vendor/MSFT/Policy/Config/ApplicationManagement/RemoveDefaultMicrosoftStorePackages
- Data type: String (ADMX‑backed policy requires a SyncML/XML style payload)
- Example payload entries (true = remove, false = keep) can be sent in the XML body; Microsoft published sample XML fragments showing common package IDs and their enable/disable flags. Administrators who prefer the custom route can deploy a SyncML payload to Intune or other MDMs that accept OMA‑URI configuration.
Example: a minimal CSP/XML fragment (illustrative)
Microsoft’s documentation and examples show how each package maps to a data id and a boolean value. The exact package names/IDs must be validated in your management UI prior to deployment; example entries look like:<data id="WindowsCalculator" value="true"/>
<data id="Photos" value="true"/>
<data id="MSTeams" value="false"/>
(Where value="true" requests removal for that package on the device.) Always obtain the official XML template from your management console or Microsoft documentation for the 25H2 build in your environment before pushing payloads.
How to verify removal and troubleshoot
- Event log: The appx deployment events are logged under Applications and Services Logs → Microsoft → Windows → AppxDeployment-Server → Operational. A successful removal logs Event ID: 762 with text starting “RemoveDefaultPackages uninstall override policy successfully removed package.” Use this to confirm cleanups.
- User verification: Sign in with a test user after policy application and confirm the selected apps are not present for that device. Some UI remnants (dead Start menu icons) have been observed in early flights and may require additional cleanup actions.
- Reinstallation: To reinstall a removed app, clear the policy selection for that app (set to false or remove the policy), sync the device, and reinstall the app from the Microsoft Store or redeploy via your management tool.
Why this matters — operational benefits
- Reduces operational overhead: Replaces fragile scripts and imaging workarounds with a supported, central control that survives updates and provisioning events. This reduces time spent maintaining gold images and manual cleanup steps.
- Cleaner out‑of‑box experience: Devices provisioned under an explicit policy come up with a controlled app footprint, easing helpdesk noise and aligning OS images to corporate standards.
- Security posture: Fewer unneeded inbox apps can reduce attack surface and lower the number of components that must be monitored and updated. Paired with the fact that Windows 25H2 ships with up‑to‑date Store apps in the image, admins don’t need to remove and reinstall to get the latest versions.
Real‑world caveats and risks — what to pilot before broad rollout
- Not all provisioning artifacts are removed instantly. Community pilots have reported leftover Start menu shortcuts or dead tiles after deprovisioning, requiring additional cleanup scripting in some environments. Plan to validate Start/All apps lists as part of your pilot.
- Scope is device‑level; existing user profiles may retain app state. The policy targets device provisioning; behavior for already configured user profiles can vary. If you must clean existing profiles, include user profile remediation steps (or plan re‑provisioning) in your rollout.
- Dependency and integration risk. Some apps may act as default handlers for file types or protocols. Removing a default handler may degrade user experience if not replaced with an alternative handler. Microsoft’s documentation flags such scenarios as not recommended for removal without validation.
- Third‑party agents and ISV compatibility. Some security, backup, and management agents interact with or expect specific inbox experiences. Test critical ISV agents (EDR, backup, imaging, printing) on pilot devices before mass rollout. Community notes highlight vendor lag or script incompatibilities when platform changes are activated.
- Multi‑user session devices are not supported. Devices that support multi‑user sessions are explicitly called out as unsupported for this policy, so validate device types in your inventory.
- Policy vs. GPO vs. Intune conflicts. Avoid applying overlapping removal policies from multiple management surfaces to the same device (for example both an Intune policy and a local GPO). Conflicting settings increase troubleshooting complexity.
Recommended rollout plan (practical, step‑by‑step)
- Inventory: Build a list of devices, images, and critical apps. Include whether devices are Entra/Azure AD Joined, Hybrid, or on‑prem domain joined.
- Pilot ring (5–10%): Select representative hardware families (laptops, desktops, Copilot‑enabled devices if relevant) and create a pilot scope that includes users from helpdesk, engineering, and a typical knowledge worker.
- Validate end‑to‑end: Test Autopilot/OOBE flows, first sign‑in after upgrade, and policy updates. Check event logs (Event ID 762) and confirm UI cleanliness.
- Revertability: Document and test the reinstallation path for any removed app by clearing the policy and redeploying from the Store. Ensure rollback handles home‑grown imaging and restore scenarios.
- Measure and expand: Collect telemetry on helpdesk tickets, user complaints, and any compatibility issues. Expand rings only when pain points are resolved.
Integration with provisioning and image management
- Windows Autopilot: This policy works cleanly with Autopilot provisioning flows; administrators can run the setting as part of Autopilot/ESP to remove inbox apps prior to user sign‑in and deliver a cleaner user experience. It is not strictly dependent on Autopilot, however — Group Policy or Intune policy enforcement will apply during supported enforcement events.
- Sysprep / Reset validation: Microsoft’s guidance recommends running Sysprep and Reset scenarios in lab validation after the policy is applied to ensure removed packages remain unavailable following image customization or Push Button Reset. Plan to validate these paths as part of your image lifecycle.
FAQs IT teams will ask
- Will this remove apps for existing users?
The policy is device‑level and primarily prevents provisioning and attempts to remove packages for the device; existing user profiles can retain state depending on timing and how the app was installed. Test existing‑profile cleanup in your pilot. - Can I re‑enable an app later?
Yes — clear the policy selection for that app (de‑select), sync your management tool, and reinstall the app from Microsoft Store or redeploy it through your management pipeline. - Is this available for Home or Pro?
No — the supported target is Windows 11 Enterprise and Education, version 25H2 and later. Use care if attempting registry hacks or unsupported workarounds; they are not recommended for managed fleets. - How will I know the removal succeeded?
Check the Appx deployment operational event log (Event ID 762) and perform a sign‑in validation on a test account.
Final appraisal — strengths, limitations and what to watch
Policy‑based removal of default Microsoft Store packages is a meaningful manageability win. It replaces fragile, ad‑hoc techniques with an ADMX‑backed, centrally controllable mechanism that integrates with Intune and Group Policy. For organizations that have spent months maintaining scripts and imaging workarounds, the policy reduces maintenance burden and improves image hygiene.However, this is not a silver bullet. Early community testing and pilot reports highlight UI artifacts (dead Start tiles), the device‑level scope that complicates cleanup for existing profiles, and the need to validate ISV/agent compatibility. These are practical, solvable issues — but they require the same disciplined pilot and ring deployment cadence IT teams use for any platform change. Treat Release Preview/early availability as your validation window and proceed with measured rollout.
Conclusion
Windows 11 version 25H2’s new Remove default Microsoft Store packages from the system policy is a long‑requested capability for enterprise administrators: it offers a supported, centralized way to deprovision a curated list of inbox Store apps during provisioning and upgrades. Organizations gain cleaner device images, lower operational overhead, and a repeatable, auditable way to control out‑of‑box app surface area. The tradeoffs are predictable — test the policy in pilots, validate reinstallation and recovery paths, and confirm ISV compatibility before broad deployment. When applied with care, this policy makes 25H2 a compelling platform upgrade for IT teams seeking simpler deployments, tighter control, and less out‑of‑box clutter.Source: Windows Report Preinstalled Microsoft Store Apps Can Now Be Removed With New Policy
