Applications & agents

Apps and agents are where a provisioned device either becomes a working one or becomes a week-one helpdesk ticket. This section of the Decolla catalogue covers the Microsoft core, commodity and line-of-business apps, and the agent stack — deployed to your own Intune tenant from a plan you approve first.

Why this matters

The app payload is where a build quietly fails. Intune can report every assignment as installed while the user still cannot open the accounts package, Office is on the wrong update channel, or the RMM agent never checked in — leaving the device invisible to support from day one. These faults rarely surface during provisioning; they surface as tickets in the first week, one user at a time.

The payload is also where scope creep lives. Every department wants its application in the required set, and every addition is one more installer that can fail, conflict or block a build. Line-of-business software — CAD suites, accounts packages, site-management clients — is the hardest of it: licensing, prerequisites, and per-user versus per-machine decisions that generic packaging guidance never quite covers.

What a good build does

Decolla treats the payload as a curated catalogue of discrete, journey-ordered items rather than a heap of installers. The Microsoft core is built from your captured ODT configuration.xml — channel, SKU, excluded apps and activation mode imported as-is, so new devices match what you actually run rather than a hand-rebuilt approximation. Commodity apps, LOB titles and the agent stack (your RMM, antivirus and helpdesk tooling, installed per your configuration) sit alongside as separate items, each independently selectable.

• Community practice is baked in: the required set stays lean, and LOB titles go to self-service so one broken vertical installer cannot block every build.
• Before anything runs, every selected item appears in a written, itemised plan showing how it is delivered and its reversibility class, with anything irreversible flagged. You approve that plan first.
• Deployment then runs unattended in your own Intune/Autopilot tenant, and each change Decolla itself makes can be rolled back per item.

Decolla does not claim to make Microsoft's install machinery faster — it claims to get the payload defined correctly, so what lands is what you signed off.

Where it bites people

Stale ODT configuration. The configuration.xml exported during a rollout three years ago still says Semi-Annual channel with Access excluded — but the estate has since moved on, or a shared-computer activation flag from an old RDS build is still lurking in the file. New machines arrive subtly different from everything else, and Office starts flipping channels mid-estate. The fix is procedural: capture the configuration that is genuinely current, import it, and read the plan line for the Office item before approving — the plan exists precisely so this gets caught on paper rather than on a user's desk.

The agent stack failing silently. RMM, antivirus and helpdesk agents are routinely bolted on as afterthought scripts, and they fail in ways nothing reports: two agents each bundling their own remote-access components, or an AV install colliding with existing hardening. Worst case, the RMM agent was in the pile but never registered — and nobody notices until the machine needs remote support and cannot be reached. Decolla does not watch agent check-ins for you; what it does is make each agent a named item in the approved plan, delivered per your configuration — giving you a definitive list of what should be on every device, so checking that the RMM actually registered becomes a deliberate step against that list rather than an assumption buried in a script.

What's in this section (28 items)

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