The meeting-room machine

It is almost the same build as everything else in your estate — until it sleeps mid-presentation. Shared devices deserve their own definition, not a fork of your standard one held together by memory.

Almost the same, and that's the trap

Every estate has one: the PC bolted behind the meeting-room screen. Same Windows, same tenant, mostly the same apps as everything else you manage. Then the differences start. Nobody owns it, so it signs in as a shared or room account. It must never sleep, because it will sleep at the exact moment the room fills up. Its app list is shorter, its peripherals matter more, and a good part of your standard build — personal profile choices, laptop power behaviour, the one-user-one-device assumptions — simply doesn't apply.

It is almost your standard build. The almost is what generates the tickets.

How the fork happens

The standard build already works, so the meeting-room machine becomes the standard build plus hand edits. A power tweak applied remotely one afternoon. An exclusion group for the sleep policy. A local sign-in arrangement set up in a hurry before a quarterly review. None of it is captured as a build; all of it is rediscovered the day the device is wiped and the tweaks are gone.

The alternative is worse in a different way: duplicate the whole profile set in Intune for a handful of devices, and accept that the two copies will drift apart quietly until an audit — or a full boardroom — points out where.

Neither is a definition. Both are memory, held in people.

Variance belongs in the definition

Decolla treats the meeting-room machine as a device type, not an exception. The wizard's Discover step asks for platform, chassis, scenario and make before it shows you a single build item — and those answers change what you see next.

• Chassis drives power. A desktop wired behind a screen gets different power defaults from a laptop that lives in a bag. No-sleep behaviour becomes a deliberate, recorded choice, not a registry tweak someone remembers making.
• Scenario drives relevance. Shared-device concerns surface; personal-device items fall away. You choose from a curated catalogue of 260+ build items across 21 sections, filtered to what this device type actually needs.
• The conditional engine handles the rest. OEM tooling follows the make; drive strategy, locale and the HVCI gate are handled as decisions, including whether this is a new device or an existing one being brought under control.

Defining the variant takes minutes. What collapses is the assembly: the Library's pre-built, industry-tested policies, scripts and fixes are the items you would otherwise spend weeks piecing together yourself.

A plan you can read, a rollback you can trust

Configure ends in an itemised written plan, and nothing runs until you have read and approved it. Every line shows its delivery method and its reversibility class: automatic, reversible, or flagged as irreversible so you make that call with your eyes open.

Deployment then runs unattended in your own tenant, through your own Intune and Autopilot — the Graph scopes Decolla asks for are published in full before you connect. Two honest caveats, because you would ask: Windows and the Enrolment Status Page still run at Microsoft's pace, and Decolla does not claim otherwise. And rollback — per item or for the whole build — covers Decolla's own changes only. It will not rescue a failed Microsoft install, and it does not pretend to.

One definition, every room

When the meeting-room machine fails the day before the all-hands — and that is when it fails — the replacement is a definition you re-run, not an archaeology exercise through one colleague's memory and another's leaving do.

Decolla is a product of The Cloud Platform, a working UK IT consultancy that has rebuilt this exact machine more times than it cares to count. It is currently in private build. If your estate has one of these devices — and it does — early access is through the waitlist below.