
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 need the Remove Default Microsoft Store Packages policy
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, and 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 GPO looks like:
Once you enable the policy and select your apps, Windows creates this registry key: HKLM\SOFTWARE\Policies\Microsoft\Windows\Appx\RemoveDefaultMicrosoftStorePackages
Each subkey corresponds to a selected app, using its package family name.
Windows 25H2 Enterprise / Education SKU
While looking at the code, this Store App feature is only going to be available for Enterprise and Education SKUs, which is a big shame, as I was also hoping that this feature would also be available for Windows Pro devices.
But…. looking further in the code, we noticed RemoveDefaultMicrosoftStorePackages_EnableOnAllOSVersions showing up
This code clearly tells me that this feature is going to be backported to earlier versions of Windows 11! Which is pretty great to notice
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.
- When a new user profile is created or if the user logs off and on again (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.
Results: Remove Default Microsoft Store Packages
To test this new Remove Default Microsoft Store Packages policy, 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 user logged in, the removal ran. You’ll see an event 762 like this in the AppxDeployment Server log, mentioning that the RemoveDefaultPackages uninstall override policy successfully removed the package.
And of course, you can spot a good summary of which apps have been removed in the AppxDeployment Eventlog (event 327). As shown below, you get a perfect, machine-readable record of which apps were targeted for removal.
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. If you want to get rid of those icons, the fix is easy… Log off and on, and the icons are gone!
What About Intune and Policy CSP?
While looking at the PolicyManager registry key, we noticed that it mentioned the application management CSP path for this policy:
Since it lives under the ApplicationManagement node, we’ll likely see a native option to configure it as a settings catalog in Intune in the future. For now, we need to use a CSP to configure it:
./Device/Vendor/MSFT/Policy/Config/ApplicationManagement/RemoveDefaultMicrosoftStorePackages
Data Type: Select String
Value: Enter the data below (“true” means remove the app)
<enabled/><data id=”WindowsFeedbackHub” value=”false”/>
<data id=”MicrosoftOfficeHub” value=”false”/>
<data id=”XboxSpeechToTextOverlay” value=”true”/>
<data id=”XboxTCUI” value=”true”/>
How the Microsoft Store App Removal really works
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. If you want all the technical details and what is happening behind the scenes, you may want to read this blog as well.
Prevent Store App Provisioning: How it works in Windows 25h2
Patch N Rant Covering Remove Default Microsoft Store Apps
If you are interested in watching the video where I discuss this feature and how it works under the hood, check out our Patch N Rant video!
Go Beyond the UI and Remove Any App with PowerShell
Right now, the only official option is through Group Policy or a CSP. But you are not limited to just what the GPO 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
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 the 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.
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.
- This policy also applies to existing users. To let the policy kick in, you need to log off and on again.
- It’s curated, only covers Microsoft’s own list, not third-party junk. (But we can change that ourselves)
- 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). Log off and on again to fix it.
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 want to get rid of the Microsoft Store apps (AKA bloatware?), once and for all, this is the most reliable option we have. No PowerShell scripts, no weird Dunning kruger cleanup script… just a build in policy that will ensure that all selected Microsoft Store App Packages will be removed for all users!