Running Win11Debloat unattended

#Who gets the changes

Machine-wide tweaks, such as the policies under HKLM, apply to the whole PC whichever account you choose. Per-user tweaks go to the account you target. -User, -Sysprep and -AppRemovalTarget always run in text mode, without the wizard.

#Rules for unattended runs

It refuses to run as SYSTEM on its own

Intune, SCCM and most management tools run scripts as SYSTEM, which has no user profile worth changing. Win11Debloat checks for this before changing anything and stops with: Win11Debloat is running as the SYSTEM account. Use the '-User' or '-Sysprep' parameter to target a specific user.

Without -Silent, it waits forever

Without -Silent, Win11Debloat ends with Press any key to exit..., and Default mode, saved settings and config files first ask you to press Enter. In a deployment there is nobody to press it.

The exit code only reports startup failures

Win11Debloat exits with code 1 when it cannot start properly: wrong PowerShell edition, Constrained Language Mode, missing script files, an invalid config file, a missing LastUsedSettings.json, or -Sysprep on Windows 10. Once it starts applying changes, it exits with 0 at the end, even if some app removals or tweaks failed. Those failures are only in the log, as N app removal(s) failed or N feature change(s) failed. The one-liner passes the script's exit code through.

WinGet-based removals

Copilot, Edge and OneDrive are removed with WinGet, which needs winget to be available to the account the script runs as. When it cannot find WinGet it skips those three and carries on. With -User or -Sysprep, Win11Debloat also adds a RunOnce entry to the target profile, so the WinGet uninstall runs again when that account next signs in.

Domain-joined PCs

On a domain-joined PC it warns: This machine is domain-joined. Group Policy may override changes made by Win11Debloat. Your domain policies win, and they are reapplied regularly.

#Pin a release instead of using the one-liner

The one-liner always fetches the latest release, which can change between your test and your rollout. For deployments, download the release ZIP once, test it, and ship it with your package:

powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\Win11Debloat.ps1 -Sysprep -RunDefaults -Silent -LogPath "C:\ProgramData\Win11Debloat"

Release ZIPs are at https://github.com/Raphire/Win11Debloat/archive/refs/tags/<version>.zip. Our download page lists the SHA-256 hashes of the current release's files, so you can check your copy.

#Examples

Imaging: before Sysprep, in audit mode

.\Win11Debloat.ps1 -Sysprep -RunDefaults -Silent

Changes the default profile and removes the default apps from the image, so every account created afterwards starts clean. Then generalize with Sysprep as usual.

Intune or another tool, running as SYSTEM

powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\Win11Debloat.ps1 -Sysprep -RemoveApps -DisableTelemetry -DisableBing -DisableCopilot -DisableRecall -Silent -LogPath "C:\ProgramData\Win11Debloat"

Create the -LogPath folder first (New-Item -ItemType Directory -Force), or the log ends up next to the script. Build the switch list with the command builder. For a detection rule, check for the log folder you set with -LogPath, or for a policy value one of your tweaks writes.

Your own exported selection

.\Win11Debloat.ps1 -Config "C:\Deploy\Win11Debloat.json" -Silent

Export the file from the wizard with ☰ → Export config. Tweaks in the file that do not fit the PC's Windows build are skipped. More on config files.

#Logs

Win11Debloat writes a transcript of everything it prints to Logs\Win11Debloat.log next to the script, or to Win11Debloat.log in the folder you give with -LogPath. That folder must already exist: if it does not, Win11Debloat quietly falls back to its own Logs folder, so create it first in your install script. Search it for failed, Error and WARNING to find what did not apply.

#Questions

Something wrong or out of date? Email hello@win11debloat.dev and we will fix it.