Free tool
Autopilot Advisor
Which scenario for which population, and how many technicians?
Describe your device populations — situations, not machines — and the tool names the Autopilot scenario that suits them: V1 or V2, pre-provisioned or not. It crosses the two decision axes, proof of ownership and where the time goes, then works out what each scenario costs in visits, technicians and months. When two of your answers cannot both be true, it says so instead of deciding for you.
No sign-up, no cookie: what you enter stays in your browser and is gone when you close the tab — none of it leaves. Only the visit itself is counted, by a cookieless audience measurement that does not identify you, described in the legal notice.
The project
These three numbers turn a scenario into a calendar. Leave one empty and the tool will say what it cannot work out yet, rather than inventing a value.
Your device populations
A population is a set of machines that share one situation: the same kind of hardware, the same proof requirement, the same time constraint. A physical fleet and a farm of VMs are never one population, which is exactly why they will not get the same scenario.
The plan
The visit durations used here are ranges drawn from comparable deployments, adjusted by your answers. They do not replace a pilot: over twenty to thirty machines the real duration commonly differs by half either way, depending on the image, the network and the number of blocking applications. Measure first, size the team second.
A decision aid, not an architecture recommendation. The tool reasons on what you declare; it sees neither your tenant, nor your deployment profiles, nor your enrolment restrictions. Have the result confirmed by a pilot before turning it into a workload plan.
The strategy
Autopilot: the possible scenarios
None of these scenarios is better in the abstract. Each answers a different population, and a real estate runs two or three of them at once — which is exactly where the trouble starts.
Two decision axes, and nothing else
Everything happens where two independent questions cross. The first: how the device proves it belongs to the company — through its hardware hash captured before first boot (V1), or through nothing at all (V2), which has to be compensated for. The second: where the configuration phase happens — at a bench before delivery, or entirely in front of the user. Pre-provisioning is a V1 option; V2 is designed for user-driven provisioning, with no bench step.
| Scenario | Device identity | Where the time goes | Target population |
|---|---|---|---|
| S1 — V1 + pre-provisioning | Hardware hash (V1) | Bench, then 15-30 min with the user | Standard physical fleet |
| S2 — V1 without pre-provisioning | Hardware hash (V1) | Entirely with the user (2-4 h) | Low volumes, urgent cases |
| S3 — V2, user-driven | None — BYOD allowed for the group | Entirely with the user, no bench step | VMs, narrow named population |
| S4 — V2 + serial number | Manually imported serial number | Entirely with the user, prior import | VMs or exceptions needing proof |
S1 — V1 + pre-provisioning (bench exchange)
The machine is fully prepared at the bench before delivery. It is the only scenario whose visit duration barely depends on what the image contains.
Advantages
- The shortest user visit — 15 to 30 minutes.
- Parallelises at the bench, independently of user availability.
- Compatible with a hybrid join if one is still needed.
- The hash provides proof of ownership with no additional configuration.
Drawbacks
- Requires a complete logistics flow: receiving, bench, stock, transport.
- Pre-provisioning is impossible on a Shared profile — no consequence in self-deploying mode.
- The number of technicians remains the limiting factor as soon as volume rises.
S2 — V1 without pre-provisioning
Same profile, no bench: wipe and reconfiguration entirely in front of the user.
Advantages
- No bench logistics to organise.
- Keeps proof of ownership through the hash.
- Compatible with strict BYOD restrictions.
Drawbacks
- Long visit: 2 to 4 hours, and the person is tied up from start to finish.
- One technician on one machine at a time: no parallelism.
- At volume, this line alone decides the calendar.
S3 — V2, user-driven preparation
A V2 strategy assigned to a group of users. No bench step: the device registers itself at sign-in.
Advantages
- Nothing to pre-provision: suits VMs, whose hash changes on every recreation.
- Automatic naming — prefix plus a random part.
Drawbacks
- No native proof of ownership: these machines are treated as personal by default.
- Letting them through means allowing BYOD for the group — a broad risk for a narrow population.
- No hybrid join possible.
- Impossible to pre-provision: the visit cannot be shortened by a bench.
S4 — V2 + imported serial number
A variant of S3 that restores proof of ownership without going back to the V1 hash.
Advantages
- The BYOD block stays on for everybody: no gap opened for a whole group.
- Suits a named, restricted population — identified VMs, service accounts.
Drawbacks
- A manual process in its own right: creation, serial number collection, import, and only then enrolment.
- Adds 10 to 20 minutes per machine, once, before any enrolment attempt.
- Does not scale: it needs a named owner per machine.
What each scenario costs in technicians
An illustration at 1 000 machines, 21 working days a month, 5 productive hours per technician per day. Replace those assumptions with your own in the tool above: the ratio between the lines does not change.
| Visit duration | Devices / day / tech. | Technician-days | Technicians for 3 months |
|---|---|---|---|
| 45 min (bench, targeted) | 6 | 167 | 3 |
| 75 min (bench, observed) | 4 | 250 | 4 |
| 2 h (no bench) | 2 | 500 | 8 |
| 4 h (no bench) | 1 | 1 000 | 16 |
ESP and restrictions: one applies, never two
Whatever the scenario, enrolment status pages and enrolment restrictions resolve BY PRIORITY. Adding a new rule for one scenario does not stop the others from continuing to apply if the priority is not reviewed — and several active scenarios at once, which is the normal state of a real estate, multiply that risk.
The habit to build: check the priority number of every ESP and every restriction before AND after any change, and document, for each active scenario, which one really applies to its population.
What remains to validate before generalising
- The deployment profile's exclusion list — it has to cover every other project — a machine matching two profiles is a situation never to create.
- TPM 2.0 attestation on shared machines — required by self-deploying mode, to be tested on the real hardware before it becomes a workload plan.
- The overlap between V1 and V2 — a user in the V2 group who receives an already-registered physical machine: to settle at the pilot, not to assume.
- The final visit figure — it depends on the image, the network and the ESP contents — to measure on 20 to 30 machines before sizing the team.