Zero-Touch Windows Enrollment: One Command, Served From a Cloudflare Worker

Provisioning a fleet of Windows laptops the manual way is a special kind of tedious: unbox, sign in, join the tenant, hope someone remembered to enroll it as corporate and not personal, discover three weeks later that half of them enrolled wrong. Microsoft’s answer is Autopilot — the device registers itself to your Intune tenant, pulls its deployment profile, and the end user just signs in. Getting a device into Autopilot in the first place, though, still involves a hardware-hash upload and a set of steps that are easy to get subtly wrong.

We published a small tool that collapses that into one command. This is how it works, the traps it is built to avoid, and — the part most one-liners skip — how to run an irm | iex supply chain without handing your fleet to whoever pushed last.

The one command

At a clean out-of-box experience (OOBE), open a shell with Shift+F10, and run one line. It:

1. Uploads the device’s hardware hash to your Intune/Autopilot tenant with a group tag.
2. Waits until the Autopilot deployment profile is actually assigned — not just uploaded, assigned.
3. Powers the machine off, ready to ship.

The end user powers on, completes the Autopilot OOBE, and lands on a managed corporate device. The person running the command signs in once at a Microsoft Graph prompt as an Intune admin — that is API authentication only; the admin account never lands on the device. The tool is tenant-agnostic and secret-free, which is exactly why it is safe to publish in the open: there is nothing tenant-specific baked in. Whoever authenticates at the Graph prompt is the tenant.

github.com/setkernel/autopilot

The enrollment trap it avoids

The single most common Windows-enrollment mistake is enrolling a device as personal when you meant corporate. It happens when someone signs into Windows during setup, or adds a work account from Settings → Access work or school. That path enrolls the device as a personal (BYOD) device, and unwinding it later means a wipe.

Corporate enrollment has to happen through the Autopilot OOBE, driven by a deployment profile. So the discipline the tool enforces is: register the hash, wait for the profile, power off — and do not sign into Windows yourself during the build. Two tenant-side prerequisites make it reliable:

• An Autopilot profile assigned to a dynamic device group whose membership rule matches the group tag (e.g. a rule on device.devicePhysicalIds). Group-tag assignment is far more predictable than “all devices.”
• Block personal enrollment in Intune’s enrollment restrictions, so a mis-step can only ever produce a corporate device.

One more sharp edge worth knowing: Windows Home cannot Entra-join or Autopilot, and a Microsoft 365 Business Premium licence does not upgrade Home to Pro. You need a real Pro or Enterprise key.

Why a Cloudflare Worker serves the script

The command is short because a tiny Cloudflare Worker serves the PowerShell script at a memorable URL, so the person at the OOBE types a short address instead of a raw GitHub path. A Worker is the right tool for this: it is a global endpoint with no origin server to run, it is free at this volume, and it is a single file to deploy. (A no-code alternative is a Cloudflare Redirect Rule pointing the short URL at the repo’s raw script — irm follows the redirect either way.)

This is the same reason we reach for Workers constantly: when you need a URL that does one small thing, everywhere, cheaply, there is rarely a reason to stand up a server for it.

Hardening an irm | iex supply chain

Here is the part that matters for a real fleet, and that most “just run this one-liner” posts wave away. irm <url> | iex executes remote code, elevated, at the most privileged moment a machine ever has — OOBE. If the URL can change what it serves, so can anyone who can push to it. Once your script is final and you have validated a clean run, pin the supply chain:

• Serve an immutable revision, not main. Point the Worker at a specific commit SHA or tag, and bump it deliberately per release. A push to main should never change what the fleet executes.
• Verify a SHA-256 in the one-liner instead of a bare pipe: download the script, check its hash against a pinned value, and only then run it. A mismatch throws.
• Pin the uploader version. If the script installs a helper from the PowerShell Gallery, require a specific validated version rather than whatever is latest today.
• Restrict the blast radius. Lock down who can push to main and who can deploy the Worker or owns the domain the short URL lives on.

None of this is exotic. It is the difference between a convenience script and something you are willing to run, as root, on every machine your business depends on.

When this is worth it

If you are provisioning more than a handful of Windows devices — onboarding, refreshes, a new office — zero-touch enrollment pays for itself in avoided re-imaging and support tickets. The tool is one piece of the managed-IT and infrastructure work we do; the interesting engineering is the tenant design around it (the dynamic groups, the enrollment restrictions, the profiles) and the operational discipline that keeps a fleet consistent.

If you are standing up or cleaning up a Windows fleet and want it done properly, tell us what you are working on — two paragraphs is enough, and we reply in writing within one business day.