Windows 11 25h2: Remove Default Microsoft Store Packages:

A Native Way to Remove Default Microsoft Store Packages

This blog will focus on the new Windows 11 25h2 feature, “Remove Default Microsoft Store Packages.” It’s a long-awaited Group Policy and (eventually) Policy CSP setting that finally lets you remove a curated list of inbox Microsoft Store apps (bloatware) natively, without requiring PowerShell scripts. If you’ve ever wanted a cleaner, bloatware-free Windows deployment, this new policy is worth checking out.

Why We Needed This (And What We Had to Do Before)

For as long as Windows 10 and 11 have shipped with their full set of built-in Microsoft Store apps, there has been demand from IT and sysadmins for a clean, supported way to remove the extras. Think of Sticky Notes, Solitaire, Quick Assist, Xbox, Clipchamp, apps that most enterprises don’t want to show up for new users.

Until now, the only way was to script the removal, typically using PowerShell. I covered all the headaches of that process in this previous blog. Scripting isn’t just ugly; it’s fragile. If you remove something Windows expects, you risk breaking the OOBE flow, tripping up Autopilot, or even causing the Enrollment Status Page to hang.

What we’ve been asking Microsoft for is a native policy to quietly clear these apps during provisioning, without requiring extra scripts, detection hacks, or timing nightmares. And now, it looks like that’s finally happening! When looking at the latest insider preview, the Remove Default Microsoft Store Packages feature showed up!

The New Policy: Remove Default Microsoft Store Packages

With one of the latest Windows 11 Insider Preview Dev builds (Windows 11 25h2), a new Group Policy setting showed up under: Computer Configuration > Administrative Templates > Windows Components > App Package Deployment

The setting is called Remove Default Microsoft Store packages from the system. It lets you pick from a curated list of built-in Microsoft Store apps that should be stripped out when a new user profile is created. No, you won’t find Candy Crush or Spotify in there; this is Microsoft’s own inbox app list.

Here’s what the UI looks like:

Once you enable the policy and select your apps, Windows creates this registry key: HKLM\SOFTWARE\Policies\Microsoft\Windows\Appx\RemoveDefaultMicrosoftStorePackages

registry policy HKLM\SOFTWARE\Policies\Microsoft\Windows\Appx\RemoveDefaultMicrosoftStorePackages

Each subkey corresponds to a selected app, using its package family name.

The Remove Default Microsoft Store Packages Technical Flow:

Here’s exactly what’s happening under the hood, straight from the code (yes, we decompiled appxalluserstore.dll in IDA. Check out our video on YouTube to find out more):

The logic only runs if both Feature_RemoveDefaultMicrosoftStorePackages (57056100) and Feature_UxAccOptimization (48433719) are enabled. You can enable them using ViVeTool.

The feature (GetRemoveDefaultMicrosoftStorePackagesPolicy) checks the HKLM\SOFTWARE\Policies\Microsoft\Windows\Appx\RemoveDefaultMicrosoftStorePackages policy to determine if the policy is enabled.

GetRemoveDefaultMicrosoftStorePackagesPolicy

When a new user profile is created (as opposed to an existing one), the removal logic is triggered.
The main function (AddAllUserApplicationsToDynamicArrayForUser) starts enumerating the apps that need to be removed for that user.

For each app, the code walks through the subkeys in RemoveDefaultMicrosoftStorePackages.
If the app matches a subkey and the policy is enabled, it’s flagged for removal.
The CleanupPackageFromPerMachineStore function is called:
- Copies the registry data for the app to a “deleted” subtree
- Deletes the provisioning info for that app from the machine
- Moves the app’s files to a DeletedAllUserPackages folder

If successful, the app is unprovisioned and shouldn’t appear for new users logging in.
The logic writes telemetry to the Microsoft Windows AppXDeploymentServer Operational event log. If the policy or removal fails, you’ll see detailed errors there.

If you want to follow the process yourself, this all happens in appxalluserstore.dll and is orchestrated (and logged) by the AppXDeploymentServer provider. You can watch events in the Microsoft Windows AppXDeploymentServer Operational log.

Go Beyond the UI and Remove Any App with PowerShell

Right now, the only official option is through Group Policy. But you are not limited to just what the UI shows. As we noticed in the technical flow, Windows only looks for registry subkeys in
HKLM\SOFTWARE\Policies\Microsoft\Windows\Appx\RemoveDefaultMicrosoftStorePackages. If you add a package family name there, even if it is not in the official Group Policy list, Windows will remove that app for every new user profile.

Why? Because the code to remove the apps just puts all the packages in one big array!.
This gives you much more control. For example, if you want LinkedIn or Copilot removed, just add their package family names to the registry.

The removal process will catch anything you list, not just what shows up in the Group Policy window. So, you are also not tied to Group Policy or a CSP. Since this feature is all registry driven, you can set it with a simple PowerShell script

removeappxpackages Download

Here is what the Script will do.

Create a subkey for each package family name you want removed
Set a value called RemovedPackage to 1 in each subkey
Set Enabled to 1 at the base key

Example: To remove LinkedIn and Copilot, add these:

"7EE7776C.LinkedInforWindows_w1wdnht996qgy",  # LinkedIn
"Microsoft.Copilot_8wekyb3d8bbwe"            # Copilot

Add the PowerShell to Intune and assign it to all devices to ensure the script runs before the first user signs in, so the app removal occurs at the correct moment.

The moment that PowerShell script is executed, the LinkedIn and Copilot app will be removed and will no longer be able to be executed.

Bottom line:

This approach offers more flexibility than the UI, and you can fully automate it today using PowerShell and Intune, without needing to wait for Microsoft to add CSP or Settings Catalog support. Set your script to run before anyone logs in, and you will achieve precisely the clean deployment you want.

Results: Remove Default Microsoft Store Packages

I set both feature flags with ViVeTool and enabled the policy before Autopilot enrollment.

Sure enough, as soon as the device completed provisioning and the first user logged in, the removal ran. You’ll see an event like this in the log (Event ID 327):

RemovePackageList
Microsoft.QuickAssist_8wekyb3d8bbwe
Microsoft.Paint_8wekyb3d8bbwe
Microsoft.WindowsNotepad_8wekyb3d8bbwe

You get a perfect, machine-readable record of which apps were targeted for removal.

Remove Default Microsoft Store Packages Key requirement:
This must all be in place before the first user logs in. It doesn’t seem to do anything for existing profiles…

But… The Apps Might Still Show Up (Broken)

Here’s the catch. Even with the policy and removal process in place, you’ll often see shortcuts for removed apps still lingering in the Start menu or All apps list. Once you click on it nothing happens.. it is just stuck. The good thing? The app indeed is not launching!

Event Viewer shows a flood of deployment errors (Event ID 698, AppXDeployment-Server) with error code 0x80073D01 for the failed apps.

So, while the packages are truly unprovisioned, the UI/UX cleanup isn’t finished yet. The Start menu displays “dead” icons, and users are unable to launch the apps.

This rough edge just proves: the feature’s backend is there, but the front-end polish isn’t. Is it still in development?

What About Intune and Policy CSP?

There is a CSP path for this policy:
./Device/Vendor/MSFT/Policy/Config/ApplicationManagement/RemoveDefaultMicrosoftStorePackages

Since it lives under the ApplicationManagement node, we’ll likely see a native option to configure it in Intune in the future. However, as of now, the official Microsoft documentation hasn’t been updated, and this setting is not yet available in the Intune Settings Catalog.

No need to wait, though. As we showed above, because the policy is fully registry-driven, you can already deploy the exact same configuration using PowerShell and Intune. Just push your PowerShell script as part of Autopilot, and you’ll get the same result as Group Policy, plus the flexibility to target any inbox app. When Microsoft eventually adds CSP and Intune support, you can switch to the native method. Until then, the PowerShell approach gives you all the control you need.

How the Microsoft Store App Removal really works (or doesn’t)

If you are curious what really happens when this policy is enabled and whether apps are actually removed or just hidden, we took a closer look. It turns out it does not remove anything. Instead, it prevents the apps from being provisioned for new users. Want the technical details, the registry moves, and what is happening behind the scenes?

Prevent Store App Provisioning: How it works in Windows 25h2

Summary: This Is the Cleanest Solution…Once It’s Ready

If you want to remove default (or other) inbox Microsoft Store apps during provisioning, this new policy is the way to go.
It’s curated, only covers Microsoft’s own list, not third-party junk. (But we can change that ourselves)
It only works if you enable both feature flags and set the policy before any user signs in.
The actual removal is logged in the AppXDeploymentServer Operational log (Event 327 and errors as 698).
It leaves some UI junk behind for now (dead Start menu icons).

Still, this is the closest we’ve come to a proper, first-party solution for eliminating bloat before users see it.

Final note

If you encounter any oddities or the policy doesn’t work as expected, check those feature flags and review your logs. Please note that this is still an Insider-only feature and not yet ready for production. But for anyone tired of wrestling with PowerShell cleanup scripts, this is the most promising thing in years.