Policy-based in-box app removal is a Windows feature that uninstalls preinstalled Microsoft Store apps and other MSIX/APPX packaged apps on managed devices. It has two halves: a static list of apps Microsoft predefined, and a dynamic removal list where you name any app by its package family name (PFN). The dynamic list is the interesting half, because it covers apps that never appear in the checkbox list.
Until recently the only way to configure that dynamic list from Intune was a custom OMA-URI profile with a hand-written XML payload, plus a one-time registry touch on every targeted device. Microsoft has since documented a settings catalog path instead. You pick the setting, paste your PFNs one per line, and assign the profile.
This guide walks through the whole flow: eligibility, finding the PFN, building the policy, assigning it safely to a pilot ring, and verifying the removal on a real device.
Before you start
What you will learn
- You'll learn how to find an app's package family name, add it to the dynamic app removal list in an Intune settings catalog policy, assign that policy to devices, and confirm the app is gone.
- Preinstalled Store apps show up on every new device and generate help desk noise, support questions, and compliance findings. Policy-based removal deletes them at provisioning and blocks reinstallation for as long as the policy applies.
Requirements
- You need access to the Microsoft Intune admin center with permission to create and assign device configuration profiles, plus a Windows 11 test device that is MDM-enrolled and has the app installed so you can read its package family name.
- Windows 11, version 24H2 or newer, Enterprise or Education edition, MDM-enrolled and targeted through device groups. Multi-session environments aren't supported.
- Intune Administrator (Microsoft Entra role)
- Policy and Profile Manager (Intune built-in RBAC role)
Good to know
- About 20 minutes, plus a sign-out and sign-in on the test device.
- Written against Microsoft's policy-based in-box app removal documentation, May 2026 revision.
Quick answer
In the Microsoft Intune admin center, create a settings catalog policy for Windows 10 and later. Under Administrative Templates\Windows Components\App Package Deployment, enable the setting that removes Microsoft Store apps with a dynamic list, then paste one package family name per line. Assign it to a device group. Windows removes the apps at provisioning or at the next user sign-in, and blocks them from reinstalling while the policy is assigned.
Microsoft Intune admin center > Devices > Manage devices > Configuration > Create > New policy > Windows 10 and later > Settings catalog > Administrative Templates\Windows Components\App Package DeploymentGet-AppxPackage *Notepad* | Select-Object PackageFamilyNameStep-by-step tutorial
7 stepsConfirm the devices are eligible
Rule out the version and edition problems that make this policy silently do nothing.
Check three things before you build anything.
- Windows version. Devices must run Windows 11, version 24H2 or newer.
- Edition. Only Enterprise and Education editions support policy-based in-box app removal. Pro and Home don't.
- Enrollment and targeting. Devices must be MDM-enrolled, and the policy has to be assigned to device groups, not user groups. It's a device-level policy.
Multi-session environments aren't supported, so leave your Azure Virtual Desktop and Windows 365 multi-session hosts out of scope.
Get-ComputerInfo | Select-Object WindowsProductName, OsDisplayVersion, WindowsEditionIdGet-ComputerInfo | Select-Object WindowsProductName, OsDisplayVersion, WindowsEditionIdIf the edition is Pro, this policy isn't the tool for the job. Removing the app with an Intune remediation script or a Win32 app wrapper is the fallback, with the caveat that neither blocks reinstallation.
Find the app's package family name
Get the exact identifier the dynamic removal list expects.
Sign in to a device that already has the app installed and open PowerShell. Run a wildcard query against the app name and read the PackageFamilyName value:
Get-AppxPackage *Notepad* | Select-Object PackageFamilyNameReplace Notepad with part of your target app's name. Copy the returned string exactly, publisher hash included. A PFN looks like Microsoft.WindowsNotepad_8wekyb3d8bbwe.
Repeat for every app you plan to remove and keep the list somewhere you can paste from later.
Get-AppxPackage *Notepad* | Select-Object PackageFamilyNameIf the query returns nothing, the app isn't installed for the current user. Try Get-AppxPackage -AllUsers *AppName* from an elevated session. Don't guess a PFN from the Store listing, since the publisher hash has to match exactly.
Create the settings catalog policy
Start a Windows configuration profile that carries the removal setting.
Microsoft Intune admin center > Devices > Manage devices > Configuration > Create > New policyIn the Microsoft Intune admin center, go to Devices > Manage devices > Configuration, then select Create > New policy.
Choose Windows 10 and later as the platform and Settings catalog as the profile type, then select Create.
Give the profile a name that says what it does and which ring it targets, for example WIN-CFG-StoreAppRemoval-Pilot. Add a description naming the apps you're removing, so the next admin doesn't have to open the settings picker to find out.
Keep this profile separate from your general baseline. App removal is the kind of policy you want to scope, filter, and roll back on its own.
Add the dynamic app removal setting
Configure the setting that carries your package family names.
Settings catalog > Administrative Templates\Windows Components\App Package DeploymentSelect Add settings to open the settings picker, then browse to Administrative Templates\Windows Components\App Package Deployment.
Microsoft documents the setting for the dynamic list as Remove Microsoft Store apps with dynamic list. The older static checkbox setting, Remove default Microsoft Store packages from the system, sits in the same category. Search for "Microsoft Store" in the picker and read the setting names carefully, because the catalog wording has changed as this policy rolled out.
Set the setting to Enabled, then enter your package family names in the dynamic list field, one per line. Leave the static app toggles alone unless you also want those predefined apps removed.
If the dynamic list field isn't there, your tenant's settings catalog may not have ingested the updated policy definition yet. Microsoft has published a custom OMA-URI fallback for that case, but it needs a one-time registry visit on each device and is really only practical for testing.
Assign the policy to a pilot device group
Limit the blast radius of an irreversible change.
Microsoft Intune admin center > Devices > Manage devices > Configuration > [your policy] > Properties > AssignmentsOn the Scope tags page, set your tags and continue. On the Assignments page, add a device group that holds a handful of test machines. User groups won't work for this policy.
If your fleet mixes older and newer builds, add an assignment filter on OS version so only devices that support the updated schema receive this profile. Keep any existing static-list policy assigned to the rest.
Review the summary and select Create.
Assignment filters based on OS version are the cleanest way to avoid the CSP schema mismatch Microsoft warns about. Consolidate the two policies only once every device is on a supported build.
Sync a test device and sign in again
Trigger the removal, which doesn't happen mid-session.
Settings > Accounts > Access work or school > [work account] > Info > SyncOn the test device, open Settings > Accounts > Access work or school, select the account, and choose Sync under Info. Wait for the sync to complete.
Removal runs at out-of-box experience, at sign-in after an OS upgrade, and at sign-in after a policy update. It does not uninstall the app from an already signed-in session. Sign out and sign back in, or create a new user profile, to make it fire.
For Autopilot devices, include this profile in the device's configuration profiles and use the Enrollment Status Page to block until device setup finishes. If the policy doesn't land in time, the apps can show up briefly until the next sign-in.
Verify the removal on the device
Prove the policy landed and did what you asked, rather than assuming it did.
Microsoft Intune admin center > Devices > Manage devices > Configuration > [your policy] > Device statusCheck three places.
Intune. Open the profile and look at Device status. A supported device should report a successful deployment. "Not applicable" points at the OS version or the assignment scope.
Registry. Confirm the device received the policy:
Get-ChildItem 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\Appx\RemoveDefaultMicrosoftStorePackages'Package list. Confirm the app is gone:
Get-AppxPackage -AllUsers | Select Name, IsPartOfSystemFor detail, open Event Viewer at Applications and services logs > Microsoft > Windows > AppxDeployment-Server > Operational.
Get-AppxPackage -AllUsers | Select Name, IsPartOfSystemUseful event IDs in the AppxDeployment-Server operational log: 606 for packages the policy removed at first sign-in after OOBE, 614 for packages it failed to remove, 762 for a blocked install attempt, 873 for a PFN rejected as a system component, 874 for a non-removable AI component, and 875 for a malformed PFN.
How to Confirm the App Removal Policy Applied Correctly
A working configuration shows up in three independent places, and it's worth checking all three before you widen the assignment.
In Intune, the profile reports success on the device. On the device, the registry key under HKLM\SOFTWARE\Policies\Microsoft\Windows\Appx\RemoveDefaultMicrosoftStorePackages exists with subkeys, which proves the policy arrived. And Get-AppxPackage -AllUsers no longer lists the package you targeted.
The blocking behaviour is the fourth signal. Ask a test user to install the app from the Microsoft Store. The install should not complete, and event ID 762 should appear in the AppxDeployment-Server operational log. That block lasts as long as the PFN stays in the list.
- Intune reports the profile as succeeded, the policy registry key holds subkeys, the app is absent from Get-AppxPackage -AllUsers after a fresh sign-in, and Store reinstallation is blocked.
- A status of "Not applicable" means the device is on an unsupported version or edition, or it isn't in the assigned device group. The app still being present after a sign-in usually means the profile was targeted at users instead of devices, or the PFN doesn't match. A grayed-out Start menu tile means the block is working as designed.
- Publisher and app name, an underscore, then the publisher hash. The whole string has to match, hash included.
- Logged in AppxDeployment-Server > Operational for each package the removal policy successfully removed.
- The dynamic list entry couldn't be parsed. Check for a stray space, a typo, or PFNs that weren't separated by a line break.
- Intune only applies this policy to supported devices, so this status points at the OS version, the edition, or the assignment scope rather than at a policy error.
Troubleshooting
The profile shows "Not applicable" in Intune
Cause: Intune only applies this policy to supported devices. The device is running an unsupported Windows version or edition, or it isn't in the assigned group.
Confirm the device runs Windows 11, version 24H2 or newer, on Enterprise or Education. Run Get-ComputerInfo | Select-Object OsDisplayVersion, WindowsEditionId on the device. If the edition is Pro or Home, this policy won't apply at all and you need a different removal method.
The app is still installed after the policy applies
Cause: Removals run at provisioning or at sign-in, not mid-session. Existing user profiles keep their apps until the user signs out and back in.
Sign out and sign back in on the test device, or create a new user profile, then check again with Get-AppxPackage -AllUsers. If it's still there, verify the profile is assigned to a device group rather than a user group, and re-check the PFN against the output of Get-AppxPackage.
The dynamic list field isn't in the settings picker
Cause: The tenant's settings catalog hasn't ingested the updated policy definition yet, so only the static checkbox options show.
Search the picker for "Microsoft Store" under Administrative Templates\Windows Components\App Package Deployment and check both setting names. If only the static list is available, use the static toggles for predefined apps and wait for the catalog to update rather than hand-building an OMA-URI profile for production. Microsoft's OMA-URI path needs a one-time registry visit on every targeted device and is documented as practical for testing only.
The policy fails to apply on some devices in a mixed fleet
Cause: Devices support different CSP versions during rollout. A device that receives a policy not matching its supported schema may fail to parse it.
Keep your existing static-list policy assigned to older devices and create a separate profile with the dynamic list for newer ones. Use assignment filters on OS version so each device receives only the profile it can parse, then consolidate once the fleet is on a supported build.
A PFN in the list is ignored and nothing is removed
Cause: The entry is malformed, points at a system component, or points at a component that isn't removable.
Open Event Viewer at Applications and services logs > Microsoft > Windows > AppxDeployment-Server > Operational. Event 875 means the PFN is malformed, so check for typos and confirm each PFN sits on its own line. Event 873 means you targeted a system component and event 874 a non-removable AI component. Neither can be removed with this policy.
A removed app won't reinstall after you take it out of the list
Cause: Deselecting an app or deleting its PFN unblocks installation but doesn't restore the package that was already removed.
Remove the PFN from the dynamic list, save, and trigger a device sync so the block is lifted. Then reprovision the app through the Microsoft Store, an ISO, or an Intune Win32 app. The local app data that was deleted with the package doesn't come back.
Frequently asked questions
Does this work on Windows 11 Pro?
No. Policy-based in-box app removal is supported only on Enterprise and Education editions of Windows 11, version 24H2 or newer. On Pro and Home, Intune shows the profile as "Not applicable" and nothing is removed.
Where do I find an app's package family name?
Run Get-AppxPackage *AppName* | Select-Object PackageFamilyName in PowerShell on a device where the app is installed. Copy the returned string exactly, including the publisher hash after the underscore.
Can I bring an app back after removing it?
Not by deselecting it alone. Removing the app's PFN from the list and syncing lifts the installation block, but you then have to reprovision the app through the Microsoft Store, an ISO, or a management tool such as an Intune Win32 app. The deleted app data is gone for good.
Why didn't the app disappear right away?
Removal runs at out-of-box experience, at sign-in after an OS upgrade, and at sign-in after a policy update. An already signed-in user keeps the app until they sign out and back in, or until a new profile is created on the device.
Can I remove Windows system components with the dynamic list?
No. The dynamic list covers MSIX/APPX packaged apps only. If you add a system component, Windows logs event ID 873 and skips it, and a non-removable AI component logs event ID 874.
Can I use this alongside a Group Policy app removal setting?
You shouldn't. Applying both an Intune profile and a GPO to the same device makes the result unpredictable, because whichever policy arrives last takes effect. Pick one management channel per device.
