Operations, monitoring & remediation

The build isn't finished when the device ships. This section loads your tenant with the detect-and-fix remediations, health repairs and maintenance schedules that keep a fleet healthy after day one.

Why this matters

A fleet that passes its build checks on day one and is quietly rotting by month three is the default outcome of Windows estate management, not the exception. Defender drops into an unhealthy state after a bad definition update and nobody notices until a security review. C: drives fill with Teams cache and update leftovers until feature updates start failing. A service that should be running has been stopped for weeks. None of it raises a ticket until it becomes an incident — and then the helpdesk fixes one device at a time, by hand, for a problem that exists across the whole estate.

Intune's remediation engine — paired detection and fix scripts running on a schedule — exists precisely for this. But it ships as an empty framework: it does nothing until somebody writes, tests and maintains the script pairs. Most teams never build that library, because day-2 tooling is the work that always loses to the next deadline.

What a good build does

Decolla treats day-2 operation as part of the build, not something you'll get round to. During deployment it loads pre-built, industry-tested detect-and-fix remediations into your own Intune tenant — detection logic runs on each device, and the fix fires only where detection fails. The set covers the recurring offenders: Defender health checks with automatic repair, disk-space monitoring backed by Storage Sense, and system-file repair via DISM and SFC — plus a scheduled overnight maintenance task, so routine upkeep doesn't depend on anyone remembering it.

The scoping is worth being clear about. Everything runs inside your tenant, on Microsoft's own remediation and scheduling mechanisms. Decolla doesn't sit between you and your fleet, and reporting stays where it belongs — in your Intune console and Endpoint Analytics, which the build enrols you into. Every item appears on the written plan you approve before anything runs, with its delivery method and reversibility class stated, and Decolla can roll back its own changes item by item afterwards.

Where it bites people

The classic trap is the script host. By default, the Intune Management Extension runs PowerShell in a 32-bit host, so registry writes silently land under WOW6432Node and some modules simply aren't there. Scripts report success in the console while changing nothing on the device — a fleet-wide no-op that looks green. Decolla ships the 64-bit host fix as a baseline item precisely because so many remediations are quietly undermined by it.

The second is the retry schedule. When a Win32 app or script fails, the Management Extension suppresses further attempts after repeated failures — unassigning and reassigning does nothing for up to a day. The truth is in the IME logs, which almost nobody reads, and forcing a genuine redeploy means clearing the right per-app state on the device. That is exactly what the ops toolkit in this section is for: log collection and forced redeploy as a known procedure, not folklore passed around the helpdesk.

What's in this section (11 items)

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