[Bug] - Windows Apps - D - In-Box App Removal

[Aussupport]

Baseline Info (please complete the following information):

• OS: [e.g. Windows] Windows 11 25H2 Build 26200.8390
• Version: [e.g. 3.6]

Describe the bug

Remove Default Microsoft Store packages from the system. Error:65000

Noticed whatsapp/Solitaire/Linkdin/xbox and Microsoft Store not removed

To Reproduce
Add? Remove Policy

[jamiehallghs]

What version if Windows 11 are you using (Home/Pro/Enterprise)?
Believe this setting is only for Ent/Edu SKUs

[Aussupport]

Enterprise

…

On Tue, 19 May 2026, 23:52 Jamie Hall, ***@***.***> wrote: *jamiehallghs* left a comment (SkipToTheEndpoint/OpenIntuneBaseline#217) <#217 (comment)> What version if Windows 11 are you using (Home/Pro/Enterprise)? Believe this setting is only for Ent/Edu SKUs — Reply to this email directly, view it on GitHub <#217 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANT2DWGRA3YNRULHYAL7OYD43RRKXAVCNFSM6AAAAACZENJDQ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DIOBYGQ2DEMBZG4> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[Aussupport]

Do Any Update?

[stephenmedd]

We are having the same issue. My thoughts are that it maybe a bug because subscription Enterprise (E3/E5) is not treated the same as a device license. This was the cause of the 65000 error with the secure boot settings. I can test this next week by upgrading my root install.

https://patchmypc.com/blog/intune-policy-rejected-by-licensing/#subscription-activation-does-not-change-the-licensing-decision

[stephenmedd]

I put in an enterprise key last night, ran a few syncs now but no luck. This is the event log, the event ID is 404.

[rianbk]

Root cause found — it's a Settings Catalog schema gap on newer builds, not licensing.

Hit this on Windows 11 25H2, build 26200.8390, Enterprise (Settings Catalog profile from the v3.7 In-Box App Removal export). Same Error 65000, 0 succeeded. Ruling out the licensing theory up front: affected devices are confirmed Enterprise (skuFamily), and an Enterprise-key test posted earlier in this thread already showed no change — so it's not subscription/device-license related.

The actual cause, from the device-side MDM log (Event Viewer → Applications and Services Logs → Microsoft → Windows → DeviceManagement-Enterprise-Diagnostics-Provider → Admin):

Event 856:  MDM PolicyManager: ADMX ingestion given payload policy definition
            element Id not found: Id (DynamicRemovalList). Result:(0x82B00001)
Event 810:  Set policy string ... RemoveDefaultMicrosoftStorePackages ... Result:(0x82B00001)
Event 404:  CSP command failure ... RemoveDefaultMicrosoftStorePackages ... 0x82B00001

Recent 24H2/25H2 builds added the dynamic app removal list feature, so the OS-side ADMX for RemoveDefaultMicrosoftStorePackages now expects a DynamicRemovalList element. The Intune Settings Catalog definition for this policy doesn't expose that element yet (confirmable via Graph — deviceManagement/configurationSettings?$filter=rootDefinitionId eq 'device_vendor_msft_policy_config_applicationmanagement_removedefaultmicrosoftstorepackages' returns the 25 app children and no dynamic-list node). So the SC-generated payload is schema-incomplete → the whole policy is rejected with 0x82B00001 → nothing applies, and any device that had it applied on an earlier build keeps a stale block (Store apps then fail to install with 0x80073D3F).

Workaround — deploy via Custom OMA-URI instead (Settings Catalog can't supply the missing element; re-importing the SC profile produces the same broken payload):

• OMA-URI: ./Device/Vendor/MSFT/Policy/Config/ApplicationManagement/RemoveDefaultMicrosoftStorePackages
• Data type: String
• Value: your existing <data id="…" value="…"/> selections plus a trailing <data id="DynamicRemovalList" value="" />. Example mirroring the v3.7 defaults:

<enabled/><data id="WindowsFeedbackHub" value="true" /><data id="MicrosoftOfficeHub" value="false" /><data id="Clipchamp" value="false" /><data id="Copilot" value="true" /><data id="BingNews" value="true" /><data id="Photos" value="false" /><data id="MicrosoftSolitaireCollection" value="true" /><data id="MicrosoftStickyNotes" value="false" /><data id="MSTeams" value="false" /><data id="Todo" value="false" /><data id="BingWeather" value="true" /><data id="OutlookForWindows" value="false" /><data id="Paint" value="false" /><data id="QuickAssist" value="true" /><data id="ScreenSketch" value="false" /><data id="WindowsCalculator" value="false" /><data id="WindowsCamera" value="false" /><data id="MediaPlayer" value="false" /><data id="WindowsNotepad" value="false" /><data id="WindowsSoundRecorder" value="false" /><data id="WindowsTerminal" value="false" /><data id="GamingApp" value="true" /><data id="XboxIdentityProvider" value="true" /><data id="XboxSpeechToTextOverlay" value="true" /><data id="XboxTCUI" value="true" /><data id="DynamicRemovalList" value="" />

(Empty DynamicRemovalList = no extra PFNs, and avoids the "open the registry on each device" caveat from the MS docs.) Unassign the Settings Catalog profile from the targeted devices to avoid a dual-write conflict on the same node.

Verified: after deploying the OMA-URI version, HKLM\SOFTWARE\Policies\Microsoft\Windows\Appx\RemoveDefaultMicrosoftStorePackages is populated (Enabled=1, DynamicRemovalList present, per-app subkeys), Event 856/0x82B00001 stops, and the policy reports Succeeded.

Might be worth shipping an OMA-URI variant of this profile for 25H2+ until the Settings Catalog definition gains the dynamic-list element.

[SkipToTheEndpoint]

Man I love the legwork done there @rianbk!

That's given me all the necessary info to flag this to the Intune team!

[angr72]

Tnx a lot @rianbk, been struggling to figure this one out!

[Aussupport]

So remove this policy and deploy via Custom OMA-URI ?

[rianbk]

So remove this policy and deploy via Custom OMA-URI ?

Yes, thats the workaround for now.

[stephenmedd]

Looks like this has been fixed with the latest Windows/Intune updates.

[rianbk]

Worth a quick sanity check before anyone reverts, because the Intune side of this does not appear to be fixed yet.

As of 2026-07-07, querying Graph for configurationSettings filtered on rootDefinitionId eq 'device_vendor_msft_policy_config_applicationmanagement_removedefaultmicrosoftstorepackages' still returns only the root node plus the 25 per-app children, with no DynamicRemovalList element. So the Settings Catalog definition itself has not changed. A re-imported or reverted SC profile will generate the same element-less payload that failed earlier.

These definitions are served centrally rather than per-tenant, so this should be the same everywhere, but Microsoft does stage rollouts, so it is worth running that same query in your own tenant to confirm before relying on it either way.

If the policy is genuinely applying again on your side, that points to an OS-side ADMX change in a newer build (the ingestion no longer hard-rejecting a missing DynamicRemovalList) rather than Intune exposing the element. I could not confirm that half either way from the device: on a 25H2 box now on build 26200.8655 the policy applies cleanly via the Custom OMA-URI workaround (registry populated, no Event 856 / 0x82B00001), but that payload includes the element, so it cannot show how the OS would treat a payload that omits it. The only definitive test is to pilot-assign the stock Settings Catalog profile to a single device and watch for Event 856.

Until the Settings Catalog definition gains the element, the Custom OMA-URI approach applies on every build with no downside, so there is not much reason to switch back yet.

[stephenmedd]

This was our return from graph, assuming this is what you got as well?

Pulling ADMX on the OS shows it is installed now on the OS side, version 26200.8655 and 26100.8655

Select-String -Path C:\Windows\PolicyDefinitions\*.admx -Pattern 'RemoveDefaultMicrosoftStorePackages','DynamicRemovalList'

Select-String -Path C:\Windows\PolicyDefinitions\AppxPackageManager.admx -Pattern 'DynamicRemovalList'