Microsoft shipped its April 2026 non-security preview update for Windows 11, and the headliner for IT administrators is a new dynamic policy that controls removal of built-in Store apps. Available on Windows 11 Enterprise and Education editions running version 24H2 or 25H2, the update introduces a CSP-backed setting that lets you define an evolving blocklist of AppX and MSIX packages the operating system will silently uninstall and keep off managed devices. The change marks a shift away from brittle post-imaging scripts and custom provisioning packages toward a declarative, policy-driven model that stays effective across feature updates and in-place upgrades.

Tucked inside KB5039327 (the April 2026 optional cumulative update for Windows 11 24H2 and 25H2), the feature piggybacks on the existing ApplicationManagement policy area. A new OMA-URI path—./Device/Vendor/MSFT/Policy/Config/ApplicationManagement/RemoveDefaultApps—accepts a semicolon-delimited list of package family names. When the device checks in with MDM or processes Group Policy, the Windows App Runtime removal engine evaluates the list, compares it against the current set of provisioned and installed default apps, and wipes any matches that aren’t pinned by a conflicting policy or marked as system-critical. The behavior is additive: you can update the list at any time, and the next sync will catch newly blacklisted titles without requiring a re-provisioning or reimage.

Why this matters now, three and a half years into Windows 11’s lifecycle, is because default Store apps have multiplied. The inbox now includes Clipchamp, Dev Home, the new Outlook for Windows, Microsoft Teams (free), Copilot, Microsoft 365 Copilot companion, and a rotating cast of consumer-focused widgets—many of which aren’t welcome on task-worker or kiosk systems. Until this update, the only officially supported path to strip them from a running Enterprise image was a combination of the “AppLocker” CSP, logon scripts calling Remove-AppxPackage, or the blunt instrument of Get-AppxPackage -AllUsers | Remove-AppxPackage in a deployment task sequence. All of those approaches break when Microsoft refreshes an app’s package family name during a feature update or introduces an entirely new default app in a cumulative release. With the new policy, admin intent persists because the OS re-evaluates the removal list on every sync cycle and after every OS upgrade.

Admins will notice the removal engine respects a lightweight priority model. System-component packages—things like the Start menu, the Settings app, or the Windows Security experience—cannot appear in the list; the configuration service provider will reject them with error 0x87D1FDE8 (Not Applicable). Provisioned apps that are part of a feature-on-demand package (e.g., the Quick Assist FOD) can be blocked only if the underlying optional feature is also disabled, otherwise the CSP logs a warning and skips removal. For everything else—the candy-crush-style games, the consumer communication tools, the trialware offers—the removal takes effect within five minutes of a policy refresh, no reboot needed in most cases. The uninstall is non-recoverable from the user’s perspective; the app tile vanishes from Start, the background process is terminated, and the package is deprovisioned so new user profiles won’t find it. If you later delete an entry from the policy list, Windows will not automatically reinstall the app, but a user or a required deployment can still pull it from the Microsoft Store.

Configuring the policy through on-prem Group Policy requires the April 2026 administrative templates (ADMX/ADML), which ship inside the downloadable policy definitions pack for Windows 11 24H2 and later. After copying the updated files to your central store, navigate to Computer Configuration > Administrative Templates > Windows Components > App Privacy > Remove Default Windows Apps. Set the policy to Enabled, and in the options pane enter the semicolon-delimited list. A typical entry for a task-worker machine might read: Microsoft.Clipchamp_8wekyb3d8bbwe;Microsoft.OutlookForWindows_8wekyb3d8bbwe;Microsoft.MicrosoftOfficeHub_8wekyb3d8bbwe;Microsoft.BingWeather_8wekyb3d8bbwe;Microsoft.XboxApp_8wekyb3d8bbwe. Each string must match the PackageFamilyName exactly—wildcards aren’t supported, and case is ignored. To obtain the correct names, you can query a reference machine with Get-AppxPackage | Select-Object -ExpandProperty PackageFamilyName or browse the per-machine AppX manifest folder.

For Intune and other MDM environments, the OMA-URI based approach offers even more agility. Create a custom device configuration profile on the Windows platform, choose the ./Device/Vendor/MSFT/Policy/Config/ApplicationManagement/RemoveDefaultApps node, pick String as the data type, and paste the semicolon-delimited list. You can target the profile at device groups and layer it with filters to exclude, say, engineering workstations that need certain developer tools. Once deployed, the Intune portal will report compliance status under the “Per-setting status” blade; devices that successfully processed the list will show “Success,” while those that encounter a non-removable package will display a conflict alert. Because the CSP processes the list on every MDM sync interval (typically every 120 minutes, or on-demand with a Sync action), you can shrink or grow the blocklist mid-flight and see results the same business day.

Existing removal scripts won’t stop working, but they’ll generate policy conflict warnings if they touch the same apps. The CSP inspects the AppX deployment stack during removal attempts; if a script tries to uninstall a package that the policy already covers, the OS logs a Warning event ID 236 from source SoftwarePolicy, indicating redundant action. If you run both mechanisms, the policy takes precedence—the app stays removed even if a logon script later tries to restore it via Add-AppxPackage, unless that script runs in a higher-integrity context that overrides policy. Microsoft’s documentation recommends picking one approach and sticking with it, predicting that most shops will retire their legacy removal scripts within a year of adopting the new policy.

Feedback from the Windows Insider Enterprise community, which has been testing the feature since January 2026 preview builds, highlights a handful of edge cases. Timing is the most common gripe: during autopilot provisioning, the policy may not process until after the user signs in, leading to a brief flicker where a blocked app appears in the Start menu and then vanishes. Admins can work around this by embedding the same package list in an offline servicing package applied to the base image, ensuring the apps are never laid down in the first place. Another note concerns Store updates: if Microsoft pushes a new version of a blocked app that changes the package family name (unlikely but possible with a major redesign), the old entry in the policy becomes a no-op. The community suggests using Azure Logic Apps or a scheduled PowerShell runbook that scrapes Microsoft’s package feed monthly and alerts when a PackageFamilyName changes, then automatically updates the Intune profile.

The licensing scope is deliberately narrow. The RemoveDefaultApps CSP node requires a Windows Enterprise or Education SKU; it’s blocked on Pro, Pro for Workstations, and SE editions. Microsoft’s rationale, visible in the CSP documentation comments, is that the feature could “degrade the consumer experience” if misapplied by untrained users. Family members running Pro on a shared PC won’t see the Group Policy template, and the Intune node returns “Not Applicable” on non-eligible editions. This isn’t a technical limitation—the underlying app-removal engine exists on all SKUs—but a choice to keep the capability in the commercial bucket. It’s consistent with how Microsoft has gated other management-heavy policies, like the Start layout customization and the Edge uninstall switch.

For organisations still on Windows 10 Enterprise LTSC or Windows 11 21H2, the policy remains unavailable. The April 2026 update’s support pages explicitly state that the feature is tied to the 24H2 and 25H2 servicing stack, which underwent a significant refactor to separate policy evaluation from the App Readiness service. Admins clinging to older builds will need to accelerate their migration plans or continue with script-based removal.

Looking ahead, the policy sets the stage for a broader default-app management strategy that insiders have glimpsed in the Dev Channel. A future update, likely landing in 25H2 Moment 6 or the 26H2 feature release, will add a “permanent deprovision” option that deletes the app packages entirely from the WinSxS store, freeing up several gigabytes of disk space. Combined with the existing remove-on-demand policy, this would give IT departments three tiers of control: dynamic removal, pre-provision removal at imaging time, and deep cleanup for sealed, single-purpose devices like digital signage players or call-center terminals.

In the near term, the April 2026 update’s policy is a welcome tool that closes a long-standing gap in Windows 11 enterprise management. It eliminates the cat-and-mouse game that followed every new default app appearance and gives administrators a straightforward, supported way to enforce a clean desktop. The only remaining friction is the manual curation of PackageFamilyNames, which many admins will solve by sharing community-maintained blocklists on GitHub—turning a policy field into a crowdsourced asset, not unlike the popular DoNotSpy lists for telemetry settings.

When you decide to adopt, start by piloting the policy on a canary ring of test machines. Audit which built-in apps your users actually need (the Feedback Hub and Screen Sketch often surprise people by being essential), and craft an initial blocklist. Deploy it through your MDM of choice during a maintenance window, then monitor the MDM dashboard and Event Viewer under Applications and Services Logs > Microsoft > Windows > AppXDeployment-Server for operational logs. If everything looks clean, push the policy to broader rings and schedule a review cadence—quarterly is generally enough—to prune entries that are no longer in the base image or add newcomers that have arrived through cumulative updates. With this update, Microsoft has given enterprise admins what they’ve been asking for since the Modern App era began: a policy knob, not a script, to tame the inbox.