App packaging & delivery

Getting one app installed is easy. Getting a whole catalogue installed reliably, detected correctly, assigned by entitlement and kept patched is where most Intune builds quietly fall apart.

Why this matters

App delivery is where an Intune build stops being configuration and starts being someone's working day. Every administrator has the war stories: a Win32 app the console marks as failed even though it installed fine, because the detection rule checked a path the vendor moved in an update; a finance package assigned to an ad-hoc device group so nobody can say who is actually entitled to it; a fleet of third-party apps still running whatever version was current on the day the estate was built.

The two pains that come up most consistently are exactly those: misconfigured detection rules and unpatched third-party software. The first generates helpdesk tickets indefinitely; the second is an audit finding waiting to happen. And in a zero-touch world the stakes are higher still — a required app that never reports as installed can leave a brand-new device stranded mid-provisioning.

What a good build does

Decolla treats app delivery as a pipeline, not a pile of one-off packages. Installer folders go through a generic ingest pipeline and come out as properly formed Win32 (.intunewin) apps — install command, uninstall command and detection logic all defined from the start, rather than bolted on after the first failure.

Where an application is available through winget or the Microsoft Store, the build can use the newer Store-backed app type instead of hand-packaging. But this is an explicit either/or: Store-backed delivery conflicts with debloat items that remove or unpin the Store, so Decolla surfaces that decision up front and records it in the written plan rather than letting it resurface later as a mystery failure.

Assignment follows a licence-group model — each paid product maps to an Entra ID group, so installation tracks entitlement and nobody has to reverse-engineer an ad-hoc device group to work out who should have what. For keeping it all current, the catalogue includes wiring in a third-party patching service such as Patch My PC or Scappman, so applications stop ageing from the day of the build. Every item lands in the itemised plan with a delivery and reversibility class, and Decolla can roll back its own changes item by item.

Where it bites people

Two failure modes come up again and again.

• Detection rules. Intune judges success by the detection rule, not the installer's exit code. A rule pinned to an exact version number or a hardcoded file path breaks the moment the vendor ships an update: the console fills with failures for apps that are actually installed, retries churn, and on a fresh enrolment a required app that never reports as installed can stall provisioning entirely. Detection logic that survives vendor updates matters more than the install command itself.
• The Store conflict. Store-backed and winget deployments depend on Store plumbing being present on the device. If the debloat baseline has removed or deprovisioned the Store, those installs fail quietly on every new device. Decolla forces that decision into the open before anything runs, so the two halves of the build never fight each other.

What's in this section (7 items)

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