Microsoft ran a live Ask Me Anything session on Windows Autopilot and Intune deployment as part of Tech Community Live: Intune Edition. The session was hosted by Joe Lurie with Maggie D'Acuba (Product Manager, Windows Autopilot) and Perla Morales (Customer Acceleration Team, Intune). The questions came straight from IT admins on Tech Community and LinkedIn — real-world problems, answered by the people who build the product.
Here are the 10 things that stood out to me.
1. User-Driven is the default. Stop pre-provisioning everything.
The number one mistake Maggie sees is organisations pre-provisioning their entire device estate because they want to replicate the old Configuration Manager workflow — image it, lock it down, hand it over fully ready. That mindset doesn't belong in cloud-native.
User-driven Autopilot is the intended default. Your OEM ships the device directly to the end user. The user turns it on, signs in, and Autopilot handles the rest. No technician. No prep. No staging.
Use pre-provisioning only for specialist devices — like a CEO who needs a fully configured machine before it leaves IT hands. For everyone else, user-driven is the right call.
Self-deploying mode is reserved for userless devices: kiosks, shared workstations, Microsoft Teams Rooms.
2. Migrating from hybrid AD to cloud native requires a wipe. There is no other path.
A question came in about migrating 10,000 devices from Hybrid Azure AD Join to Entra-only. The answer was direct: you have to wipe the device and start over. There is no in-place upgrade path from hybrid to cloud native.
The practical strategy is to use your existing device refresh cycle. Every new or repurposed device goes through Autopilot cloud-native from day one. Over a five-year cycle, your estate migrates naturally without a big-bang reset project.
3. Microsoft is not bringing Hybrid Join to Autopilot Device Preparation.
Government cloud (GCC High) customers pushed back on this one — they want to stay hybrid but are limited to Autopilot Device Preparation, which only supports Entra Join.
Maggie was clear: Hybrid Autopilot was always meant as a transitional state, not a destination. It added complexity, slower setup, and extra dependencies. Autopilot Device Preparation is the North Star experience. Hybrid will not be added to it.
The classic Autopilot solution (V1) will also not be brought to government clouds. If you're in GCC High and still hybrid, Microsoft's recommendation is to use imaging to maintain existing devices and adopt Autopilot Device Preparation for all new devices going forward — Entra-only.
4. Security tools breaking your Autopilot flow? Delay them to post-desktop.
Some third-party security agents (EDR tools, AV clients) are known to break Autopilot flows. Microsoft doesn't control what those vendors build, so there's no universal fix.
The pattern that works: don't block on them during the Enrollment Status Page (ESP). Configure them to install after the desktop is reached rather than during the OOBE flow. If you're seeing unexplained Autopilot failures, your security tooling is the first place to check.
For ESP, install only what is absolutely critical — Office, Teams, VPN, and your security baseline. Everything else can follow.
5. Persona-based app delivery: device groups beat user groups during Autopilot.
The question was how to ensure the right apps land on the right device type without causing delays. Two approaches work well:
- Pre-classify devices into groups by use case (call centre, field worker, executive) and target apps at those device groups before the device reaches the user.
- Keep ESP minimal, use Company Portal for the rest. Install only the critical apps during OOBE. Everything else goes into Company Portal as Available so users can pull what they need, when they need it.
The Company Portal self-service model also reduces help desk calls — users learn to grab apps themselves rather than logging a ticket every time something isn't pre-installed.
6. Do not use dynamic groups for app deployment in Autopilot.
This was one of the most direct pieces of advice in the session. Joe Lurie put it plainly: “Don’t use dynamic groups for app deployment. Full stop.” Maggie and Perla agreed.
Dynamic group sync in Entra can take up to 24 hours. During an Autopilot provisioning flow, that delay means apps simply don't land — the device isn't in the group yet when Intune evaluates the assignment.
The only safe use of dynamic groups in Autopilot is for registration targeting — grouping devices by Group Tag or Autopilot-specific attributes. Because device records are created in advance, there's enough time for those groups to calculate before provisioning begins.
Avoid dynamic groups based on device name entirely. Device naming happens late in the Autopilot flow, so the group calculation will always lag.
7. Block personal devices with Corporate Identifiers, not just Conditional Access.
How do you prevent someone from enrolling a personally purchased device into your tenant? Three layers work together:
- Block personal devices in Intune via the device enrollment restrictions setting.
- Corporate Identifiers — upload serial numbers and manufacturer/model details so Intune knows which devices are company-owned. Supported on all major platforms including Windows. Required for Autopilot Device Preparation.
- Conditional Access — require Intune enrolment as a condition for accessing corporate apps, which prevents unmanaged personal devices from reaching your resources even if they get partially enrolled.
8. Migrating hardware hashes between tenants is manual work — plan ahead.
Mergers, tenant consolidations, dev-to-prod migrations — moving Autopilot-registered hardware hashes from one tenant to another comes up more often than you'd think. Microsoft doesn't have a native export tool for this yet.
The current approach: extract the hash from device logs, remove the device from the old tenant, and upload the hash in the new tenant. It works, it's just not elegant. If you're planning a tenant migration, account for this in your timeline.
9. Traditional imaging still wins for bare metal and feature updates.
Autopilot requires two things: a network connection and an operating system already on the device. Bare metal machines with no OS are outside its scope — you still need imaging (or at least a USB boot) to get the OS on the device before Autopilot can take over.
Feature updates during OOBE are also not recommended — too slow, not stable enough for the provisioning flow. Apply feature updates separately, after the device is enrolled and in production.
The broader point: Autopilot and imaging aren't mutually exclusive. Use imaging where it makes sense (bare metal, factory refresh), use Autopilot everywhere else.
10. Zero-touch is a myth. Minimal-touch is the reality — and that's a good thing.
A common misconception is that Autopilot means the user does nothing. User-driven Autopilot still requires the user to sign in, complete MFA, and go through the out-of-box experience. That's not zero-touch.
What Autopilot removes is the IT technician touch. All the hard decisions — policies, apps, security baselines, compliance profiles — are configured in advance by the admin. By the time the user turns on the device, all of that work is already done and waiting. The user just authenticates and gets to work.
That shift in framing matters. Set the expectation correctly with your stakeholders: Autopilot dramatically reduces IT time per device, not user time.
Watch the full session: The AMA is recorded and available on demand on the Microsoft Tech Community. Search for "AMA: Deployment Made Easy with Intune and Windows Autopilot" on the Tech Community Live: Intune Edition event page. Worth 50 minutes of your time if you're running any Autopilot deployments.