Moving devices from on-premises AD to Entra ID join with Intune and Autopilot

Two paths, no in-place switch

Windows cannot change a device from Active Directory domain join to Microsoft Entra ID join while keeping everything as it is. The device has to leave the domain and join Entra ID, and the user's profile is tied to the old domain account. That leaves two paths:

I have done the second path by script with pre-checks and three phases that run on their own, so users kept their familiar environment. Both paths need the same groundwork.

The groundwork

• Identities: users synchronised to Entra ID with Entra Connect, with the right UPN. Check before anything else.
• Licences and enrolment: Intune licences assigned, MDM automatic enrolment scoped to the right users.
• Apps as Win32 packages: each with a reliable detection rule, dependencies and supersedence where needed.
• Settings: Group Policy translated into the settings catalog. Group Policy Analytics in Intune shows which settings have an equivalent. Translate, do not copy: half of most GPOs are no longer needed.
• Data: Known Folder Move to OneDrive, so Desktop, Documents and Pictures are in the cloud before the device changes.
• Printers and drive mappings: inventory per device (ports, IP addresses, drivers) and rebuild them as Intune configuration. Platform scripts for drive mappings are assigned to device groups directly.
• Access to on-premises resources: Entra-joined devices can still reach file servers with single sign-on. Windows Hello for Business with cloud Kerberos trust is the simplest way to make that work.

Check the state of a device before and after:

dsregcmd /status
# Look for: AzureAdJoined : YES, DomainJoined : NO (after), AzureAdPrt : YES

Autopilot: register the devices

For the fresh-start path, devices need to be registered with Windows Autopilot. New devices can be registered by the reseller. Existing devices are registered by uploading their hardware hash, collected with Microsoft's community script for that purpose, with a group tag that later drives dynamic groups:

Connect-MgGraph -Scopes "DeviceManagementServiceConfig.Read.All"
Get-MgDeviceManagementWindowsAutopilotDeviceIdentity -All |
  Select-Object SerialNumber, Model, GroupTag, EnrollmentState, LastContactedDateTime |
  Sort-Object GroupTag, SerialNumber

A dynamic device group per group tag, for example with the rule (device.devicePhysicalIds -any (_ -eq "[OrderID]:Office-Std")), assigns the Autopilot profile, apps and settings without anyone touching group membership.

The Enrollment Status Page: where projects stall

The Enrollment Status Page (ESP) holds the user until the apps marked as blocking are installed. It is useful, and it is the most common reason Autopilot "hangs". In one project, provisioning stalled on about 40% of devices: the ESP ran into timeouts and devices had to be finished by hand. The cause was blocking app assignments and package dependencies that slowed each other down. After cleaning that up, provisioning went from about three hours to under 45 minutes.

• Mark as blocking only what the user needs in the first minutes: security agent, VPN if needed, perhaps Office. Everything else installs afterwards.
• Do not mix app types carelessly during the ESP: line-of-business MSI apps and Win32 apps installing at the same time are a known source of trouble.
• Check every detection rule. An app that installs fine but is never detected keeps the ESP waiting until the timeout.
• Assign apps to groups the device is already in at enrolment. Late group membership means late apps.
• Conditional Access that requires a compliant device can block sign-ins during setup, before the device is compliant. Test the policies against a device in provisioning.

When a device does stall, the logs are on the device: the Intune Management Extension logs under C:\ProgramData\Microsoft\IntuneManagementExtension\Logs, the event logs under Applications and Services Logs, Microsoft, Windows, DeviceManagement-Enterprise-Diagnostics-Provider, and a diagnostics package with mdmdiagnosticstool.exe -area Autopilot -cab C:\Temp\autopilot.cab. Turning the ESP off is usually not the fix.

Rolling it out

1. Pilot with IT and a handful of users with different roles and devices
2. Fix what the pilot finds, especially apps and printers
3. Move in waves by department or site, with a named contact and a rollback per wave
4. Remove the old devices from Active Directory and Entra Connect sync scope afterwards, so stale hybrid objects do not linger

Checklist

• Users synchronised with correct UPNs; Intune licences and MDM scope set
• Apps packaged as Win32 with tested detection rules
• GPOs analysed and translated into settings catalog profiles
• Known Folder Move active and complete before the device changes
• Printers and drive mappings inventoried and rebuilt in Intune
• Windows Hello for Business with cloud Kerberos trust for file server access
• Devices registered with group tags; dynamic groups per tag
• ESP with few blocking apps; provisioning time measured in the pilot
• Waves with a contact and a rollback; old AD objects cleaned up