Windows - Software Lifecycle - Uninstall Targeted Microsoft Store Apps

What the Microsoft Store app remover does

This Automox Worklet™ removes a configurable list of Microsoft Store and UWP apps from Windows endpoints. The Worklet accepts an app allowlist/blocklist parameter named appList, walks every user profile on the machine, and strips matching AppxPackages so the apps disappear from the Start menu, Windows Search, and the per-user app library.

Stripping the per-user instance is only half the job on Windows. New user accounts inherit a separate provisioned image staged under %ProgramData%\Microsoft\Windows\AppxProvisioning, so a single Remove-AppxPackage call leaves the door open for the same bloatware to reappear at next sign-in. The Worklet also runs Remove-AppxProvisionedPackage -Online against the system image, which prevents Candy Crush Saga, TikTok, BingWeather, 3DBuilder, iTunes, Roblox, and similar apps from returning when an OEM build refresh or a new profile gets created.

The Worklet reads its target list from a single appList parameter, so you can tailor it per policy. A locked-down kiosk policy can target a long list of consumer apps. A developer fleet policy can keep WSL-adjacent UWP utilities in place while still purging Xbox, Solitaire, or the Mail and Calendar clients. Verbose logging is enabled by default during remediation so each match, removal, and miss is recorded in Automox activity output.

Why purge Microsoft Store bloatware from corporate Windows endpoints

OEM Windows 10 and Windows 11 images ship with consumer UWP apps that have no business on a managed corporate endpoint. Candy Crush Saga, TikTok, Disney Magic Kingdoms, Spotify, Roblox, and 3D Builder consume disk space, fire toast notifications during work hours, and create an audit-trail problem for any team that has to attest to installed software under SOC 2 CC6.8, the CIS Microsoft Windows 10 Enterprise Benchmark (currently v4.0.0) and Windows 11 Enterprise Benchmark sections on Microsoft Store and consumer experiences, or PCI-DSS v4.0 control 12.5.1 (component inventory). Removing them at provisioning is straightforward; keeping them removed across profile refreshes and feature updates is where most fleets quietly drift.

AppX packages re-appear for predictable reasons. A Windows feature update re-provisions Candy Crush from the cumulative image, an OEM refresh reseeds Roblox into the user profile during the OOBE pass, a new user signing in for the first time picks up iTunes from the provisioned package set. The Worklet runs Remove-AppxPackage against the configured appList for every signed-in user and Remove-AppxProvisionedPackage against the system image on every evaluation, so each of those re-provisioning events is caught on the next agent check-in, before any of them land in a quarterly software inventory report tied to CIS or PCI-DSS evidence.

How targeted Microsoft Store app removal works

1. Evaluation phase: The Worklet iterates the appList parameter and runs Get-AppxPackage -AllUsers | Where-Object { $_.Name -like "*<appname>*" } against each entry. If any wildcard match returns a package, the endpoint is flagged non-compliant with exit code 2. If every entry comes back empty, the endpoint exits 0 and remediation is skipped. The evaluation script also emits the matched PackageFullName values to stdout so the Automox console shows exactly which apps triggered the policy.

2. Remediation phase: The remediation script caches two collections up front: Get-AppxPackage -AllUsers for per-user installs and Get-AppxProvisionedPackage -Online for the system image. For each entry in appList, matching AppxPackages are removed with Remove-AppxPackage -Package $_.PackageFullName -AllUsers -Confirm:$false, and matching provisioned packages are removed with Remove-AppxProvisionedPackage -Online -PackageName $_.PackageName. Misses log a verbose message and continue. Errors are caught, logged with the failing PackageFullName, and the script exits 1 so the Automox activity record surfaces the failure instead of hiding it.

Microsoft Store app removal requirements

• Windows 10, Windows 11, or Windows Server 2016 and later (Appx PowerShell module is part of the base OS)

• PowerShell 5.1 or later for full -AllUsers support on Remove-AppxPackage

• SYSTEM or local administrator context (the default Automox agent context already satisfies this; required for Get-AppxPackage -AllUsers and Remove-AppxProvisionedPackage -Online)

• Populate the appList Worklet parameter with the target app substrings before deployment, for example: 3DBuilder, BingWeather, CandyCrushSaga, Tiktok, Spotify, iTunes, Roblox, XboxGameOverlay, MicrosoftSolitaireCollection

• Pair this Worklet with a Group Policy or Intune policy that disables "Turn off Microsoft consumer experiences" if you want to block OEM re-injection at feature-update time

• Works on both WORKSTATION and SERVER endpoint types under Automox

Expected state after Microsoft Store app removal

After remediation, every app named in appList is gone from the Start menu, Windows Search, the Settings > Apps list, and the per-user app library across all profiles on the endpoint. Get-AppxPackage -AllUsers | Where-Object Name -like "*<appname>*" returns no rows for any of the targeted package names. Get-AppxProvisionedPackage -Online | Where-Object DisplayName -like "*<appname>*" likewise returns nothing, which means a newly created Windows user account on the same machine will not have the bloatware re-staged on first sign-in.

For audit evidence, capture the remediation script's stdout (matched PackageFullName lines plus removal confirmations) and the post-run output of Get-AppxPackage -AllUsers and Get-AppxProvisionedPackage -Online. The next Automox evaluation cycle reports the endpoint as compliant without applying remediation again, because the evaluation phase finds no matches. The endpoint remains compliant across reboots and ordinary patch cycles. The only common path back to non-compliant is a Windows feature update that re-stages a consumer app, at which point the next evaluation run flags the endpoint and the Worklet strips it again with no admin intervention.