Remote support & access

Zero-touch provisioning gets a device to the desktop without anyone touching it — and the first support ticket tests whether anyone can reach it afterwards. This section covers the remote-assistance layer of the build.

Why this matters

Every MSP base image ships a remote-access tool, because the economics of device support collapse without one: the alternative is talking a user through settings screens over the phone. Autopilot-provisioned devices, by contrast, arrive with only what the build put there — and the Windows defaults are thin. Remote Desktop ships disabled, and the nearest thing to an in-box support client, Quick Assist, offers no unattended mode, no session records, and no control over who can offer help — a consumer tool, not an enterprise one.

Microsoft's own answer, Remote Help, is a paid add-on — sold standalone or as part of the Intune Suite — not part of core Intune licensing. That surprises teams who assume remote assistance comes with the management plane they already pay for. The practical consequence: the remote-assistance layer of a modern build is a deliberate decision with a licensing dimension, not a default you inherit. Fleets that skip the decision discover the gap during their first incident, which is the most expensive possible moment to discover it.

What a good build does

Decolla treats remote assistance as its own section of the catalogue, configured in your tenant during the build rather than bolted on after the first failed support call. Two capabilities cover the common cases: Remote Desktop enablement, delivered as configuration with the firewall rule and network-level authentication handled alongside the toggle, and an interactive remote-control client for attended support sessions — the AnyDesk/TeamViewer-class layer for tenants without the Remote Help add-on.

Remote Help itself is licence-tagged in the catalogue and gated by the readiness check: if your tenant does not hold the add-on licence, the plan tells you before anything runs, instead of deploying an app your technicians cannot use. As with every section, each item appears on the written plan with its delivery method and reversibility class before you approve, and Decolla can roll back its own changes per item afterwards. To be clear about scope: Decolla configures the layer; it is not itself a remote-access product and never proxies a session.

Where it bites people

Remote Help's licence failure is silent until a live call. The app deploys and installs perfectly well on an unlicensed tenant; nothing errors at deployment time. The failure surfaces mid-incident, when a technician tries to take a session and the user is told their organisation isn't licensed. Deploy-time success is exactly why the gap goes unnoticed — and why Decolla gates the item on the readiness check rather than on whether the install succeeded.

Enabling RDP is three settings, not one. The policy toggle alone does not make a device reachable: the inbound firewall rule has to be enabled for the right profile, network-level authentication should stay on, and reaching an Entra-joined device from outside the tenant has its own authentication quirks that catch experienced admins. Flip the toggle fleet-wide and call it done, and devices end up either unreachable — or reachable less safely than intended.

What's in this section (2 items)

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