Remove pre-installed Microsoft Store apps and AppX bloatware from Windows 10 and 11 endpoints fleet-wide
This Automox Worklet™ purges pre-installed Microsoft Store apps and user-added AppX packages from Windows 10 and Windows 11 endpoints. The Worklet enumerates installed AppX packages with Get-AppxPackage -AllUsers, filters out Office, the Microsoft Store itself, extensions, and any apps you flag as exceptions, then hands the survivors to Remove-AppxPackage and Remove-AppxProvisionedPackage. Both per-user installs and the underlying provisioned image are cleaned in a single run.
Two parameters drive the script. The exceptions list tells the Worklet which Microsoft AppX packages to leave alone, and the additional-apps list adds non-Microsoft AppX names or wildcards (for example Spotify*, Disney*, *.CandyCrush*) to the removal set. Removing the provisioned package matters because Windows reinstalls AppX apps the first time a brand-new user signs in. The Worklet calls Get-AppxProvisionedPackage -Online and Remove-AppxProvisionedPackage -Online -PackageName so the next account creation on the endpoint inherits the trimmed image instead of replaying the original consumer payload.
The same script targets the long catalog of stock Windows consumer bloat: Microsoft.CandyCrushSaga, Microsoft.XboxApp, Microsoft.XboxGamingOverlay, Microsoft.SkypeApp, Microsoft.MicrosoftSolitaireCollection, Microsoft.GetHelp, Microsoft.MixedReality.Portal, Microsoft.YourPhone, Microsoft.BingNews, Microsoft.BingWeather, Microsoft.ZuneMusic, and Microsoft.ZuneVideo. Anything matching your exceptions list (Calculator, Photos, Snipping Tool, or Sticky Notes are common keepers) stays put.
Consumer AppX packages on a corporate image are a configuration problem before they are a security problem. Candy Crush, Xbox Game Bar, and the Skype consumer client run telemetry, surface notifications, and occupy menu real estate that the standard image was supposed to keep clean. They also reappear after every feature update because the provisioned package is part of the Windows install media. A one-time uninstall through Settings does not hold; the image keeps reseeding the apps on every Out-of-Box Experience and every new local profile.
AppX provisioning paths re-introduce consumer apps in ways that are hard to gate at imaging time alone. A monthly cumulative update can re-provision the Xbox app into the system image, a new user signing in for the first time picks up Disney Magic Kingdoms from the provisioned package list, and a Microsoft Store auto-update can quietly reinstall a previously removed package. The Worklet runs Get-AppxPackage and Get-AppxProvisionedPackage on every evaluation, calls Remove-AppxPackage and Remove-AppxProvisionedPackage against any DisplayName in the policy appList that reappears, and reports the per-package result through the activity log before it becomes a help-desk ticket or a CIS Benchmark 18.10.x finding.
Evaluation phase: The evaluation script runs Get-AppxPackage -AllUsers and Get-AppxProvisionedPackage -Online, then filters the results against three lists – the built-in removable-Microsoft-app set, the exceptions list you supply, and the additional non-Microsoft AppX names or wildcards you supply. Office, extensions (anything where PackageName matches Microsoft.*Extension*), and Microsoft.WindowsStore are excluded by design so the Store stays functional for end users. If any package survives the filter, the script exits non-zero with the offending package names in stdout and Automox schedules remediation.
Remediation phase: The remediation script iterates the matched packages and runs Get-AppxPackage -AllUsers -Name <package> | Remove-AppxPackage -AllUsers to strip the app from every user profile on the endpoint. It then runs Get-AppxProvisionedPackage -Online | Where-Object PackageName -like <package> | Remove-AppxProvisionedPackage -Online so the next first-run experience for any new account skips that AppX entirely. The script returns exit code 0 on a successful pass and writes the per-package result (Removed, Skipped, or Failed) to stdout for the Automox activity log.
Windows 10 (1809 or later) or Windows 11 endpoints with the AppX subsystem available – Windows Server SKUs without the Desktop Experience are out of scope
PowerShell 5.1 or later with the Appx module (Import-Module Appx -UseWindowsPowerShell on PowerShell 7)
Local administrator context for the Automox agent so Remove-AppxProvisionedPackage -Online can write to the system image
Set the exceptions variable in evaluation.ps1 and remediation.ps1 to the AppX names you want preserved (for example Microsoft.WindowsCalculator, Microsoft.ScreenSketch, Microsoft.Windows.Photos)
Set the additional-apps variable to the non-Microsoft AppX names or wildcards you want purged (SpotifyAB.SpotifyMusic, *.DisneyMagicKingdoms, *.CandyCrush*)
Pilot on a non-production endpoint first – the script removes apps per user and from the image, which is intentional but not easily reversible without reinstalling the AppX from the Store
Every matched AppX package is removed from every existing user profile on the endpoint, and the corresponding provisioned package is stripped from the Windows image. The apps no longer show up in the Start menu, in Settings > Apps > Installed apps, or in the Microsoft Store as installed. Get-AppxPackage -AllUsers returns no matching rows, and Get-AppxProvisionedPackage -Online returns nothing for the package family name. A new user account created after the run inherits the trimmed image, so a fresh OOBE no longer reseeds Candy Crush, Xbox Game Bar, or the consumer Skype client.
Subsequent Automox policy runs report the endpoint as compliant without firing remediation again, because the evaluation phase finds an empty match set. If a Windows feature update reseeds a previously removed AppX (this happens occasionally with major version jumps such as 22H2 to 23H2), the next evaluation catches the regression and the remediation re-runs, closing the loop without manual intervention. Validate on a pilot endpoint with Get-AppxPackage -AllUsers | Where-Object Name -in <yourRemovalList> and Get-AppxProvisionedPackage -Online | Where-Object DisplayName -in <yourRemovalList>; both queries should return empty.


Loading...
Consider Worklets your easy button
A Worklet is an automation script, written in Bash or PowerShell, designed for seamless execution on endpoints – at scale – within the Automox platform. Worklets deploy named-CVE mitigations within hours of disclosure, perform configuration, remediation, and install or remove applications and settings across Windows, macOS, and Linux.

AUTOMOX + WORKLETS™
Uncover new possibilities with simple, powerful automation.
By submitting this form you agree to our Master Services Agreement and Privacy Policy
By submitting this form you agree to our Master Services Agreement and Privacy Policy.
Already have an account? Log in