Debloat & clean build

A device that lands on a user's desk with consumer Teams, Xbox overlays and Store promotions on it is not finished — it is half-built. Decolla treats debloat as a declared, planned stage of the build, not a script somebody remembers to run afterwards.

Why this matters

A fresh Windows install ships with a payload aimed at consumers, not at your organisation: chat clients that duplicate your work tooling, game bars and overlays, mail apps that invite staff to sign in with personal accounts, and out-of-box screens that upsell services to the person who just wants to log on. Add whatever the OEM bundled — trial antivirus being the classic — and the first week of a new device becomes ticket fuel: which Teams am I supposed to use, why is Xbox on my work laptop, what is this renewal warning?

Most teams already know this, which is why debloat scripts are one of the most-shared artefacts in sysadmin communities. The problem is not awareness — it is consistency. Hand-rolled scripts differ between engineers, rot between Windows releases as package names change, and rarely record what was actually removed on which machine. Debloat deserves the same discipline as any other build stage.

What a good build does

Decolla treats debloat as itemised, reviewable work rather than a monolithic "debloat.ps1". The Library carries pre-built, industry-tested removals — stripping consumer Teams while leaving the work client alone, removing consumer OneNote while keeping the Microsoft 365 version, quietening the OOBE and its consumer-feature prompts — each as a discrete item you select or skip.

Before anything runs, every selected item appears on a written plan showing how it will be delivered and its reversibility class, with anything irreversible explicitly flagged. Only after you approve that plan does the deployment run, unattended, in your own Intune and Autopilot tenant — Decolla configures the tenant you already own rather than interposing its own infrastructure. Afterwards, Decolla offers per-item rollback of its own changes. That scope is deliberate and honest: some removals are inherently one-way, and those are the ones flagged in the plan before you say yes.

Where it bites people

The Store paradox. The most common self-inflicted wound in this area is removing or hard-restricting the Microsoft Store on a build that also relies on Store- or Winget-backed app delivery — the delivery pipeline depends on the Store engine being intact, so ripping it out breaks your own app installs. This is a genuine either/or, and Decolla treats it as one: for a given build you either keep the engine and scope the Store work to the user-facing surface (unpinning and hiding it), or remove it and deliver applications another way. Selecting both sides at once is surfaced as a flagged conflict in the plan, not silently deployed and debugged later.

Removals that do not stay removed. Deleting a consumer app for the current user leaves the provisioned package behind, so it reappears for the next profile on the machine — and Windows updates have a history of reinstating consumer apps, with the new Outlook the best-known example. A removal that works is one that handles both installed and provisioned packages and applies a supported block where one exists; a one-time build script quietly regresses.

What's in this section (10 items)

Reversibility: auto reverses when unassigned · reverse reversible with a documented step · irreversible flagged before you approve the plan.