How to Remove Built-in Apps for Windows 11 25H2

Here at MSEndpointMGR, we have a long history of providing solutions for removing unnecessary built-in apps from Windows. @nickolaja has done several posts over the last decade on the topic of removing built-in apps, before @benw, @mauriced, and @jankeskanke did the previous post on the subject in 2022, leveraging a “cloud-source” as a reference to select apps for removal. Now that Microsoft has released a native solution in Microsoft Intune to remove default Microsoft Store packages, it’s time to take a look at the feature.

Remove Default Microsoft Built-in Apps

The Intune Settings Catalog provides a comprehensive list of device configuration settings. With the release of Windows 11 version 25H2, 36 new settings were added to the settings catalog. These settings went GA on October 23rd, 2025. One of these new settings is intended to remove default Microsoft Store packages from the system: “RemoveDefaultMicrosoftStorePackages“.

Could this be the native solution that finally replaces our long-standing community scripts? Let’s put it to the test!

Create a Settings Catalog Policy

I will create a Windows configuration policy based on the Settings Catalog. The settings I need for this are easily found by searching for “Remove Default Microsoft Store”.

By enabling the setting named “Remove Default Microsoft Store packages from the system” (1), we will get a list of applications. The Microsoft Store apps you select from the list will be automatically removed from the system (2). Any apps left unselected will remain installed. At the time of writing, there are 24 apps in the list.

The policy can now be assigned to your devices. If you fancy, you can use Intune Assignment filters to target this policy to Windows 11 25H2 or higher.

Review the Result on Computers

By reviewing the configuration policy, we can gain insights into how it is applied in the environment.

Looking at the device itself, the obvious test is to see the lack of applications targeted by the policy.

Checking the Event Viewer on a device targeted by the policy, we will also find event 762 in the Applications and Services Log – Microsoft – Windows – AppXDeployment-Server – Operational log.

Looking at the AppXDeployment log, we can also see a list of all applications that were removed.

Policy Not Applicable

You might find devices where the policy is not applicable.

These devices typically do not meet the prerequisites for the new policy setting. In the example above, the devices did not run the required Windows edition (i.e., Windows Business from the Microsoft 365 Business Premium SKU).

As it stands now, this is an Enterprise feature with no support for Pro or Business versions.

What Happens if Users Reinstall Apps?

Now that we’ve seen how the policy removes default Microsoft Store apps, the next question is: what if a user tries to reinstall one? In this section, we’ll test what happens when a user manually reinstalls an app that was previously removed by policy.

We’ll explore whether the policy actively prevents reinstallation, automatically re-removes the app, or allows it to stay. This test will help clarify how strictly the policy is enforced, and what behavior admins can expect in real-world scenarios.

One of the applications removed during my test was the “MSN Weather” app. I will test to bring this app back on the devices.

Winget Install

Using Winget, I can search for the app and try to install it with the following commands.

winget search "MSN Weather"

winget install 9WZDNCRFJ3Q2

This results in an error message: Failed to install or upgrade Microsoft Store package. Error code: 0x80073d3f.

The application was not installed on the device.

Microsoft Store Install

It’s unlikely that end users will try to install apps using Winget in PowerShell. Let’s therefore test the Microsoft Store instead. Searching the “MSN Weather” app, I find the app and can click the install button.

The app started downloading, but the installation was blocked, marked as blocked by policy.

Checking for Evidence in Event Viewer

To confirm how the policy behaves, it’s worth checking the Event Viewer for traces of app install block. In the AppXDeployment-Server log we checked earlier, I will now find a 404 event id with the same error code 0x80073D3F:

The event holds a link to a Microsoft page for more information: http://go.microsoft.com/fwlink/?LinkId=235160. This page should help diagnose and troubleshoot Windows apps, but it has no information on the error code given here.

Conclusion

This solution marks a significant step forward for supported platforms, effectively replacing earlier PowerShell-based approaches with a more streamlined, integrated approach.

While its current availability is scoped to enterprise environments and tied to feature update 25H2, there is a clear opportunity for broader accessibility. Extending support to earlier feature updates and non-enterprise scenarios would significantly enhance its impact and usability across diverse deployment landscapes.

FAQ