Autopilot is the preferred provisioning path. It removes human variability, produces consistent enrollment outcomes, and scales without proportional IT effort. But not every device can go through Autopilot, and not every organization is ready for it. Designing a provisioning approach for those cases isn’t a fallback – it’s a real part of most deployments.
Devices end up outside Autopilot for predictable reasons. Hardware purchased through channels that don’t participate in Autopilot pre-registration. Legacy devices already in use that need to be brought into management without a full reset. Environments where the infrastructure to support Autopilot – reliable internet at first boot, correct connectivity to Microsoft endpoints – isn’t available. Each of these scenarios is common in real environments, and designing exclusively around Autopilot produces a provisioning approach that fails for a meaningful portion of the fleet.
Manual Entra ID join during OOBE is the most straightforward alternative. When a new device reaches the out-of-box experience, the user can choose to sign in with a work or school account rather than a personal Microsoft account. This triggers Entra ID join and, if automatic enrollment is configured correctly, MDM enrollment into Intune. The device ends up in a fully Entra-joined, Intune-managed state without the Autopilot provisioning flow. It’s not as consistent as Autopilot – the experience depends on what the user does during setup – but it’s a valid and commonly used path.
Manual Entra ID join works. It just depends on the user making the right choice at the right moment. At small scale that’s manageable. At large scale it becomes a support burden.
Bulk enrollment using provisioning packages is an option for environments that need to provision devices at scale without Autopilot and without requiring individual user interaction. Windows Configuration Designer creates a provisioning package that can be applied to a device during or after setup to join it to Entra ID and trigger MDM enrollment. This approach is particularly useful for shared devices, kiosk deployments, or environments where devices are provisioned centrally by IT before being distributed to users.
Enrolling existing devices already in use is a different problem from provisioning new ones. For devices already Entra-joined but not yet Intune-enrolled, automatic enrollment can be triggered through the Settings app. Hybrid-joined devices can be enrolled into Intune while maintaining their domain join. Devices running as local accounts need to be either reset and properly set up, or joined to Entra ID through work account settings – which registers the device rather than joining it, with the limitations that registration implies.
The goal of any provisioning approach – with or without Autopilot – is a device in a known, consistent managed state. The path matters less than the outcome. Design for the outcome and choose the path that reaches it reliably at your scale.
Consistency is harder to achieve without Autopilot but achievable with deliberate process. A documented provisioning checklist, clear user guidance, and post-enrollment verification that the device is compliant and receiving the right policies compensates for what Autopilot provides automatically. The verification step matters as much as the provisioning step – a device that enrolled incorrectly is a problem that’s easier to catch immediately than after the user has been working on it for a week.
Intune Deployment Guide · Phase 4: Provisioning
‹ Previous: [4.1.3] Hardware Hash Registration
Next: [4.3] Co-Management ›
