Blog
How to enroll devices in Intune: methods, pitfalls, and automation
Learn how to enroll devices in Intune using eight Windows methods, avoid common errors, and automate Cloud PC and session host management.
Table of Contents
- Why your enrollment method determines your compliance posture
- Prerequisites that block enrollment before it starts
- Windows enrollment methods compared
- Troubleshooting Intune enrollment failures at scale
- Enrolling Cloud PCs and session hosts without touching hardware
- Where Nerdio Manager for Enterprise extends Microsoft enrollment automation
- Building an enrollment plan that ends cloud-native
- Frequently asked questions about how to enroll devices in Intune
A laptop can show up in Microsoft Entra ID as hybrid joined and healthy but never appear in Microsoft Intune. Microsoft documents multiple ways to enroll devices and we group them into eight practical Windows options: automatic MDM enrollment, three Autopilot modes plus Autopilot device preparation, manual enrollment, Group Policy, bulk enrollment, and co-management.
Which of the eight you can actually use is decided by the identity model your estate supports today rather than by preference, and that same constraint produces most of the enrollment failures that follow.
This guide is for Intune product owners and cloud desktop platform teams enrolling at enterprise scale. It covers physical fleets and Windows Cloud (Microsoft's umbrella for Windows 365 and Azure Virtual Desktop). Windows 365 delivers Cloud PCs and Azure Virtual Desktop delivers session-based desktops and apps on session hosts. Microsoft Intune manages both once they are enrolled.
Why your enrollment method determines your compliance posture
The enrollment method you choose sets the compliance posture every downstream control inherits. Enrollment writes the device into the tenant's trust chain. Intune installs an MDM certificate and registers the device in Entra ID, and the device then reports a compliance status that Conditional Access uses to decide whether it reaches corporate resources. Two Conditional Access targets, one gating the admin center and one gating enrollment itself, let you require MFA at enrollment.
An incorrect enrollment choice propagates damage downstream. A device moving from AD join to Entra join needs a full reset, and Microsoft provides no supported path between the two without one. One tenant-wide setting, "Mark devices with no compliance policy assigned as," decides whether unevaluated devices count as compliant by default. Before any of that trust chain forms, tenant administrators must license users and configure scope correctly.
Prerequisites that block enrollment before it starts
Every enrolling user needs an Intune license. Microsoft Intune Plan 1 comes with Microsoft 365 E3, E5, and E7, Enterprise Mobility + Security E3 and E5, Microsoft 365 Business Premium, and Education A3 and A5. Standalone Plan 1 runs $8.00 per user per month as of August 2026, based on US list pricing.
Beyond licensing, five tenant-side prerequisites decide whether automatic enrollment works at all. Administrators can treat them as one chain in which identity establishes who can enroll, scope authorizes enrollment, and discovery routes the request.
- Microsoft Entra ID P1 or P2. Without it, the MDM user scope setting isn't in the portal at all.
- MDM authority set to Intune. It lives under Tenant administration, Tenant status, Tenant details, and it applies even in co-management with Configuration Manager.
- MDM user scope set to All or Some. When set to None, hybrid devices join Entra ID but never enroll into Intune.
- A routable UPN. A user principal name on a non-routable domain such as .local fails enrollment outright.
- A DNS CNAME record. The record redirects EnterpriseEnrollment.yourdomain.com to enterpriseenrollment-s.manage.microsoft.com. The CNAME becomes optional once administrators configure automatic enrollment. Without the record, users type enrollment.manage.microsoft.com manually.
With authority and scope configured and identity plumbing routable, method choice becomes an architecture decision, and Intune compliance automation has a foundation. Teams running Windows 365 and Azure Virtual Desktop next to physical fleets usually end up automating per-host policy assignment too.
Windows enrollment methods compared
Microsoft's documented options group into eight practical Windows paths once you separate Autopilot's modes, and the identity model you can support narrows the list fast.
| Method | Best for | Identity path | User interaction |
| Automatic MDM enrollment | Corporate devices joining Entra ID; the foundation under other methods | Entra join or hybrid join | Sign-in only |
| Windows Autopilot (user-driven) | New corporate devices shipped straight to users | Entra join or hybrid join | User signs in at OOBE |
| Kiosks and shared devices | Entra join only | None | |
| Autopilot device preparation | Cloud-native deployments and Cloud PCs | Entra join only | User signs in; none in automatic mode for Cloud PCs |
| Manual enrollment (Company Portal or Settings, Access work or school, Connect) | BYOD, or corporate devices set up by hand | Entra registration for Company Portal; Entra join via Settings, Connect | Full manual flow |
| Hybrid estates without Configuration Manager | Hybrid join | None (background task) | |
| Bulk enrollment (provisioning package) | Device batches you physically touch | Entra join | Package applied at setup |
| Co-management | Existing Configuration Manager estates | Hybrid join or Entra join | None |
Automatic MDM enrollment is the foundation
Automatic enrollment fires when an Entra user adds a work account to a device or when a corporate-owned device joins Entra ID. Microsoft's documentation lists it as the mechanism underneath BYOD, bulk enrollment, Group Policy, Autopilot, and co-management. Configure it as follows:
- Open the Microsoft Intune admin center and go to Devices, Device onboarding, Enrollment, Windows, Automatic Enrollment.
- Set MDM user scope to All or Some. If you pick Some, select the group.
- Confirm MDM authority shows Intune under Tenant administration, Tenant status, Tenant details.
A preview setting, "Disable MDM enrollment when adding work or school account on Windows," defaults to No. Microsoft's Intune Customer Success blog recommends "Yes" with MDM user scope left at "All." Enrollment then becomes opt-in during app sign-ins.
Windows Autopilot and Autopilot device preparation
Classic Autopilot covers user-driven, pre-provisioned, self-deploying, and existing-device scenarios, the last being the only one that skips pre-registration. Self-deploying mode supports Microsoft Entra join only, so it can't serve hybrid estates. And hybrid deployments must run a build of the Intune Connector for Active Directory later than 6.2501.2000.5, since support for older connectors ended in late June 2025.
Windows Autopilot device preparation is a separate product for cloud-native scenarios. It supports Entra join only and requires Windows 11 24H2 or later (or 23H2/22H2 with KB5035942). Enrollment time grouping puts the device in a pre-defined security group during enrollment instead of waiting on dynamic group evaluation. On January 30, 2026, a policy's app limit increased to 25 apps, up from 10.
Manual, GPO, bulk, and co-management paths
For BYOD, users install Company Portal from the Microsoft Store and sign in with a work account; Intune marks these Entra registered devices as personally owned. You target hybrid-joined devices with Group Policy auto-enrollment, where a scheduled task enrolls the device in the background after an Entra-synced user signs in.
For bulk enrollment you point a provisioning package built in Windows Configuration Designer at devices you can physically touch, and it is a userless method. Its token expires after 180 days and it does not support MFA, so tenants enforcing MFA through Conditional Access must exclude the enrollment flow.
Co-management overview enrolls existing Configuration Manager clients into Intune and moves workloads over one slider at a time. Microsoft reports compliance is the workload customers switch first.
Across all eight paths the deciding variable is the identity model you can support today. Entra join opens the automated options, hybrid join limits you to Group Policy auto-enrollment, co-management, or hybrid-capable classic Autopilot, and that narrowing is exactly why the same handful of misconfigurations produces the same handful of error codes.
Troubleshooting Intune enrollment failures at scale
Most enrollment failures come down to whether the user is licensed, whether the user is in scope, and whether the device holds a Primary Refresh Token. Whichever method and identity model you land on, Intune challenges for enterprises cluster tightly around this same handful of failures.
Common enrollment error codes
The five codes below cover the majority of enrollment tickets, and each one points administrators to a specific first check.
| Error | Meaning | First check |
| 0x8018002b | MDM auto-enrollment not configured | MDM user scope; MAM scope precedence |
| 0x80180018 | License error on the user account | Intune license assignment; UPN mismatch |
| 0x80180014 | Windows MDM enrollment disabled or device type blocked | Enrollment restrictions; stale Autopilot device record |
| 0x80180013 | Device cap reached | Stale records against the 1–15 device limit |
| 0x800705B4 | Device is not TPM 2.0 capable (common on VMs) |
Microsoft Q&A identifies 0x8018002b as a commonly reported failure in hybrid environments, and the first thing to verify is whether MDM user scope includes the signing-in user. The device looks healthy in Entra ID the entire time, which is why this one usually reaches the identity team before anyone opens the enrollment blade. MAM user scope matters as much, since MAM takes precedence over MDM on personal devices and can cause enrollment failures.
Diagnosing failures with event logs and dsregcmd
Event logs and command-line diagnostics tell you whether the device ever had the credentials it needed. The DeviceManagement-Enterprise-Diagnostics-Provider Admin event log records Event ID 75 for successful auto-enrollment and 76 for failure.
On hybrid devices, dsregcmd /status must show AzureAdJoined: YES, DomainJoined: YES, and AzureAdPrt: YES. A missing Primary Refresh Token means the user never authenticated to Entra ID at sign-in, so enrollment cannot proceed.
For a previously enrolled device, remove the registry entries under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Enrollments, remove the existing enrollment scheduled task, and run gpupdate /force so the scheduled tasks get recreated.
Clearing stale records and enrollment restrictions
Stale records and misapplied restrictions block enrollment even when licensing and scope check out. Stale device records count against the per-user cap, and Microsoft warns admins that "to avoid hitting device caps, be sure to remove stale device records."
Intune renews the MDM certificate automatically and removes idle device records 180 days after that certificate expires. Enrollment restrictions have specific exceptions and don't apply to Autopilot, GPO enrollment, bulk packages, or DEM accounts, and Microsoft cautions that "enrollment restrictions are not security features."
Working these tickets can mean bouncing between two portals and Event Viewer on the device. Cloud PCs and session hosts raise the stakes further, since enrollment there happens without anyone touching hardware.
Enrolling Cloud PCs and session hosts without touching hardware
Cloud PC and session host enrollment happen without anyone touching a device, which shifts the work into the provisioning policy and the image lifecycle. Windows 365 deployment front-loads that work into the provisioning policy. Azure Virtual Desktop spreads it across the host lifecycle, which is the price of host-level control. Many enterprises run both, so both enrollment paths land in the same estate.
Windows 365 Cloud PC enrollment at provisioning
Windows 365 Enterprise handles enrollment automatically the moment the Cloud PC is provisioned. Microsoft's documented provisioning sequence creates the Cloud PC virtual machine, joins it to Entra ID, enrolls it into Intune without user credentials, and assigns the Cloud PC user as the Intune primary user.
Two configuration details shape how that sequence behaves in practice. Device type enrollment restrictions must allow the Windows (MDM) platform, or provisioning stalls before Intune enrollment completes. Microsoft also marks the device setup phase of the Enrollment Status Page as not supported for Cloud PCs, so only the account setup phase runs after first sign-in. Windows 365 Business follows a different pattern and does not enroll Cloud PCs in Intune by default.
Azure Virtual Desktop session hosts and the cloned-image constraint
Azure Virtual Desktop session hosts enroll like shared Windows clients, and image cloning creates the enrollment constraint that most bites at scale. Microsoft supports Intune management of Windows Enterprise multi-session hosts with device-based or user-based configuration, and it doesn't interfere with Azure Virtual Desktop's management of the same VM. Intune "does not support using a cloned image of a computer that is already enrolled," physical or virtual.
Replicated enrollment tokens cause sync failures, so every new session host needs a fresh enrollment. That is the constraint behind hosts that look enrolled but report the compliance state of the machine the image came from. Azure Virtual Desktop is manageable through the Azure Portal, PowerShell, and Microsoft Intune. Host pools and scaling plans live in the Azure Portal while policy lives in the Intune admin center.
The per-host policy assignment gap
Even after enrollment succeeds, assigning policy to each new host is manual work. In February 2026, with no native "Autopilot completed" attribute available for dynamic group evaluation, the documented workaround was a post-ESP PowerShell script that calls the Graph API to stamp an extension attribute, then a dynamic group keyed on that attribute.
Fresh enrollment per host and missing completion signals leave per-host policy assignment as manual work.
Where Nerdio Manager for Enterprise extends Microsoft enrollment automation
Enrollment stays Microsoft-native on every path. Intune issues the MDM certificate, Entra ID performs the join, and Windows 365 or Autopilot triggers the sequence.
Nerdio Manager for Enterprise picks up on either side of that event. It delivers apps to enrolled devices, assigns Intune policy during session host provisioning, and retains Intune reporting data well past the native retention window.
Application delivery, policy assignment, reporting, and host lifecycle
Windows 365 Enterprise Cloud PC enrollment happens automatically at provisioning. The delay shows up afterward, in app delivery and reporting.
- Application delivery
Unified Application Management deploys apps to Cloud PCs in roughly 30 seconds, compared with native Intune delivery that can take up to three hours. - Cloud PC right-sizing
Nerdio Advisor analyzes Cloud PC CPU, memory, license health, and utilization to recommend right-sizing and identify underused licenses. - Intune policy resilience
Nerdio Manager can create, back up, and restore Intune policies, including deleted policies that native Intune can't restore. - Administration efficiency
Sparta Services reported 70% to 80% efficiency gains as it accelerated its Azure Virtual Desktop growth. - Reporting depth
Intune reporting in Nerdio Manager retains 180+ days of historical data, against the 30- to 90-day retention native Intune applies to most operational reports.
Nerdio Manager auto-assigns Intune policies during session host provisioning. This replaces manual per-host assignment. An independent benchmark by Dr. Benny Tritsch measured reimaging session hosts in both consoles. The native Azure Virtual Desktop console took 4 minutes 50 seconds and 90 clicks; Nerdio Manager took 44 seconds and 10 clicks. That is an 85% time reduction with 89% fewer clicks. Ten clicks instead of ninety also leaves fewer places to mis-set a host during scale-out.
Nerdio Manager covers the Cloud PC path and the session host path in one console. Enrollment stays Microsoft-native while policy assignment, app delivery, and reporting stop being per-host manual work.
Building an enrollment plan that ends cloud-native
Entra join is the recommended identity target because it needs no on-premises connectivity. Hybrid join needs a reachable domain controller for initial sign-in, Group Policy delivery, and password changes. Microsoft recommends co-managing existing hybrid-joined devices until their refresh cycle, then provisioning replacements with Windows Autopilot and skipping imaging entirely. Group Policy analytics supports the transition from Group Policy to Intune by importing your on-premises GPOs and migrating supported settings to Settings Catalog policies.
That sequencing answers both problems this guide opened with. The hybrid-joined ghost device that never reached Intune is a scoping fix today (the immediate steps are to set MDM user scope and then watch for Event ID 75) and an Autopilot replacement at refresh. Once OEMs or administrators get hardware hashes registered and assign an Autopilot profile, users sign in and enrollment runs itself.
Whether you're untangling hybrid devices that never enrolled or provisioning Cloud PCs and session hosts by the hundred, Nerdio Manager automates the work around Microsoft's native enrollment tooling. Get a demo to see how Nerdio Manager works across your Windows 365 and Azure Virtual Desktop environment, or try it free in your Azure tenant.
Frequently asked questions about how to enroll devices in Intune
Resources
Learn more about Nerdio Manager
