Enrolment & Autopilot

Autopilot is the reason many organisations adopt Intune in the first place — and enrolment is the layer where a new estate either works quietly or fails in front of the user. Here is how Decolla builds it, in your own tenant.

Why this matters

Enrolment is the one part of an Intune estate every user personally witnesses. Get it right and a sealed-box device becomes a working, compliant machine without IT touching it. Get it wrong and the failures are public: an Enrollment Status Page stuck in front of a new starter, a laptop handed over half-built because nothing blocked device use until the core apps landed, personal devices appearing in the console because the default restrictions were never tightened, and an estate full of DESKTOP-XXXXXXX names that makes every future helpdesk call slower.

None of these are exotic problems. They are the default outcome of a tenant where enrolment was switched on rather than designed — and unlike most Intune mistakes, they surface one device at a time, in front of users, for months.

What a good build does

Decolla configures the enrolment path in your own Intune and Autopilot tenant — from hardware-hash registration through OOBE — with the Graph scopes it needs published before you connect anything. The pieces you would expect are there as discrete, reviewable items: a deployment profile named from your prefix; a single canonical ESP configuration that blocks device use until apps land, with your core LOB app IDs wired into the block list rather than left at all assigned apps; enrolment restrictions that keep personally-owned devices out; and a structured naming convention built from site, asset and form factor.

Before anything runs, you get a written, itemised plan: what each item delivers, how it is applied, and its reversibility class, with anything irreversible flagged. Afterwards, Decolla can roll back its own changes item by item — it does not pretend to rewind things it did not do.

Where it bites people

Two examples worth knowing about.

• The ESP block list rots. Blocking device use until required apps install is the right instinct, but left at all assigned apps it makes OOBE hostage to every app in the estate. Pinned to a selected list, it quietly drifts instead: supersede or replace an application and the block list still references the old app ID, so the ESP stops tracking the one app you actually cared about. That is why Decolla treats ESP tuning and app-block wiring as one canonical item, not two settings maintained separately until they disagree.
• Naming templates truncate. Windows computer names are capped at 15 characters. A serial-number template that looks fine on paper overruns on long serials, truncates, and can collide. A convention has to be designed to fit — site code, asset reference, form factor — not just switched on and discovered later.

What's in this section (9 items)

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