🚀 Autopilot – One Framework to Manage Them All
Most organisations don’t just have one type of device.
If you look closely, you can almost always split them into the same handful of categories — and each comes with its own quirks.
Once you understand those patterns, you can design an Autopilot framework that covers them all without overcomplicating your life.
🖥️ The Usual Suspects – Device Types in the Wild
After seeing enough tenants, I can almost always bucket devices into:
-
Always-on or multi-user devices
Kiosk machines, shared PCs in meeting rooms, reception areas — the kind that never really get “signed out”.
These don’t need personalisation during setup and should be ready-to-go with minimal input.
Profile: 🚀Autopilot DP - Self Deploy
Groups: -
Assigned devices
Your standard laptops/desktops.
One user, day-to-day work, no default admin rights — because fewer admin rights = fewer accidental (or deliberate) changes that break compliance.
Profile: 🚀Autopilot DP - User Driven
Group: 🛡️🪟💻⛓️Group - Autopilot Devices -
Assigned + Local Admin
Test machines, functional admins, engineers who need elevated rights without a ticket every 5 minutes.
Giving these rights by design (and documenting it) is better than having shadow admin accounts pop up later.
Profile: 🚀Autopilot DP - User Driven with Local Admin
Group: 🛡️🪟💻⛓️Group - Autopilot Devices - LocalAdmin -
Cloud-hosted endpoints
Windows 365, AVD — managed differently, often with their own golden image and update flow.
Including them in normal Autopilot onboarding can cause unwanted policies to apply.
Group: -
Special-purpose builds
Windows 365 Boot devices, IoT endpoints — different lifecycle, different update cadence, and in many cases no user-driven onboarding at all.
Group: 🛡️🪟💻⛓️Group - Autopilot Devices - IoT
🤔 Why the split matters
Different devices deserve different onboarding experiences.
By matching the deployment mode to the purpose of the device, you avoid unnecessary prompts, misconfigurations, and wasted time:
- Kiosk / Shared → Self-Deploy, no user creds at OOBE, fully locked down.
- Assigned devices → User-Driven, standard user rights, smooth first-day setup.
- Local Admin builds → User-Driven, but with admin role at build for the right audience.
- Cloud / special purpose → usually skipped from standard Autopilot flows.
Trying to force them all into the same deployment profile?
That’s how you end up with a meeting room PC asking for MFA, or a kiosk device installing Teams for “Bob from Finance”.
🛡️ Group logic is the secret sauce
The key to making this work is dynamic device groups.
If a device is in Autopilot Devices, it must have a matching Group Tag that lines up with the right dynamic group.
That group assignment is what links the device to the correct deployment profile.
Why?
- It removes guesswork — devices go straight into the correct build path.
- It avoids crossovers, like a shared PC getting a user-driven build.
- It’s fully scalable — add a new device type, add a new tag + group, and you’re done.
🕵️ The “Catch-All” group
Even with a perfect tagging process, there’s always something that slips through.
Picture this:
You get a ticket — “Hey IT, I just got my laptop back from repair, but it’s not doing the Autopilot build.”
You start digging…
- Profiles? Fine.
- Groups? Assigned.
- Assignments? Perfect.
Hours pass. Coffee supply dwindles. Sanity questionable.
And then you flip the device over and look at the serial number on the sticker: Serial X.
You check in BIOS… and it says Serial Y.
Yep — the repair centre swapped the motherboard. The Autopilot hash no longer matches, so to Intune this laptop is basically a random stranger.
Yes, even shiny Microsoft Surface devices have pulled this stunt.
That’s why we have a dynamic “is this even in Autopilot?” group:
- Checks if the OS is Windows.
- Checks if it’s missing from the Autopilot devices list.
- If yes → immediately grabs the Autopilot hash and registers it.
No more half-day detective work. No more Slack threads titled “WHY ISN’T THIS BUILDING??”.
Profile: 🚀Autopilot DP - Enroll to Autopilot
Group: 🛡️🪟💻⛓️Group - Windows Devices
📊 Device type → Deployment Profile → Group mapping
Quick reference you can actually skim during a coffee line.
| Device type | Deployment Profile | Group(s) | Why this pairing |
|---|---|---|---|
| Always-on / Multi-user (Kiosk, Shared) | 🚀Autopilot DP - Self Deploy | 🛡️🪟💻⛓️Group - Autopilot Devices - Kiosk, 🛡️🪟💻⛓️Group - Autopilot Devices - Shared | No creds at OOBE, fast, locked-down. Avoids “who owns this?” chaos. |
| Assigned devices (Standard user) | 🚀Autopilot DP - User Driven | 🛡️🪟💻⛓️Group - Autopilot Devices | Smooth day‑1, standard rights = fewer accidents, easy support. |
| Assigned + Local Admin (Test, functional admin) | 🚀Autopilot DP - User Driven with Local Admin | 🛡️🪟💻⛓️Group - Autopilot Devices - LocalAdmin | Intentional elevation for the few who need it. No shadow admins. |
| Cloud-hosted endpoints (W365, AVD) | N/A – managed separately | 🛡️🪟💻⛓️Group - Autopilot Devices - W365 Boot, 🛡️🪟💻⛓️Group - Devices - Virtual Machines | Separate lifecycle & images; keep Autopilot noise out. |
| Special-purpose builds (IoT) | N/A – special lifecycle | 🛡️🪟💻⛓️Group - Autopilot Devices - IoT | Often headless/single‑app; don’t treat like user PCs. |
| Catch‑All (Any unmanaged Windows device) | 🚀Autopilot DP - Enroll to Autopilot | 🛡️🪟💻⛓️Group - Windows Devices | Scoops up strays, fixes repair/board‑swap serial mismatches. |
🎬 Final Thoughts
Autopilot isn’t “set and forget” — it’s set, tag, watch, and adjust.
By recognising the five core device types, pairing them with the right deployment mode, and keeping a catch‑all safety net, you can:
- Keep every onboarding clean and predictable
- Reduce “Why is this device like this?” tickets
- Make Autopilot a framework, not a guessing game
Different devices. Different needs.
One framework to rule them all.