Windows updates, drivers & delivery

Windows patching is where fleet health is won or lost, and it fails quietly. This page covers how Decolla configures update rings, feature-update pinning, driver and firmware policy and update delivery in your own Intune tenant — planned and approved before anything runs.

Why this matters

Windows patching fails quietly. A device can sit enrolled, show green in every console view, and still be taking update instructions from the wrong place — a leftover WSUS Group Policy, a second ring applied by an old baseline, an unpinned feature-update path. Nobody notices until an incident forces the question, and by then the honest answer is usually some of the fleet, some of the time.

Drivers and firmware are the more neglected half. Most tenants either leave them to whatever the OEM utility does when a user happens to open it, or do not manage them at all — which is how a vulnerable driver stays resident for years and a firmware bug takes out a room full of identical machines on the same day. Update governance is also the one area of Intune where two well-intentioned policies actively fight each other, so it has to be built as one deliberate set, not accumulated over time.

What a good build does

Decolla configures update governance in your own Intune tenant as one coherent set rather than accumulated toggles. The centrepiece is a single authoritative update ring, backed by an update-ring conflict guard that pins the Windows Update scan source to Windows Update, so a device never quietly defers to a WSUS server you decommissioned. A feature-update profile pins Windows to the release you have actually tested, so nothing jumps a version because a deferral quietly expired. Around that sit the delivery and timing controls: peer-to-peer sharing of update content, daytime maintenance windows for devices that cannot patch overnight, and an expedite route for the update that cannot wait.

Driver and firmware policy runs through Windows Autopatch, which requires Windows E3/E5 or Business Premium — Decolla's readiness check verifies this before the item is offered, rather than letting it fail afterwards. Where the fleet warrants it, OEM update tooling is matched to the hardware you actually own, whether that is Dell, HP, Lenovo or Surface. Every item lands in the written plan first, with its delivery method and reversibility class stated, and each of Decolla's own changes can be rolled back individually. The section is deliberately Windows-only: macOS, iOS and Android update policy live in their own platform sections, so no platform ships devices that never patch.

Where it bites people

Two failures come up again and again. The first is the dual-scan trap. A tenant migrates from WSUS or ConfigMgr, Group Policy fragments survive, and devices end up scanning two update sources at once. Intune reports the ring as applied — which it is — while the device defers to a WSUS server that no longer approves anything. Patched on paper, stale in reality, and invisible until someone audits the actual update source. A single authoritative ring with the scan source explicitly pinned to Windows Update is the only durable fix, which is why it is built in rather than left to hope.

The second is driver and firmware licensing. Intune's driver update policy runs through Autopatch, and plenty of tenants discover mid-rollout that their licence does not include it — leaving drivers to whichever vendor utility a user last opened. Checking the licence before offering the item is the difference between a plan that deploys and one that half-fails silently.

What's in this section (14 items)

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