Forum Discussion
Device Enrollment
Hi Simone,
The devices are Surfaces (ARM) and are not joined to our on-prem AD. These devices are only used to connect to our virtual environment.
We are running into issues during the OOBE joining the devices to AAD. With Windows 11, you have to bypass the OOBE in order to get to the section for AAD.
We see the device listed in AAD and see the device assigned to our AutoPilot and other groups but the user profile does not appear to be created. For example, if I use my account (AccountA) to join AAD during the OOBE, once the device finishes and reboots, I cannot login using my account (AccountA).
We have also tried perfroming an AAD join after OOBE has completed but this is "hit and miss". We would like to avoid using Company Portal.
Hi barryallen , thanks for the extra context.
For ARM Surface devices (not on-prem AD joined) and wanting to avoid Company Portal, the cleanest approach is Autopilot user-driven + Microsoft Entra ID Join + automatic Intune enrollment.
From what you describe (device object appears in Entra/Autopilot groups, but no user profile is created and the user can’t sign in after reboot), two things are usually the root cause:
- Windows edition mismatch (Home vs Pro/Enterprise)
Windows Home does not support Microsoft Entra join during OOBE, and can behave like it “registers” the device but won’t complete a proper Entra join/sign-in flow. Please confirm the Surfaces are running Windows 11 Pro (or higher) (Autopilot supported editions are https://learn.microsoft.com/en-us/entra/identity/devices/device-join-out-of-box). - Automatic enrollment not enabled for the user (MDM user scope)
If MDM automatic enrollment isn’t enabled (or the user isn’t in scope / not licensed), the join flow can be inconsistent and you end up with a device object but no proper managed sign-in experience.
Check in Intune: Devices > Enrollment > Windows > Automatic enrollment and set MDM user scope to All (or a group containing these users).
Quick validation on an affected device (after OOBE):
- Run dsregcmd /status and verify AzureAdJoined : YES. If it’s NO and only WorkplaceJoined is YES, you’re ending up with registration, not a true Entra join.
If you confirm the Windows edition + paste the dsregcmd /status “Device State” section from a failing device, I can tell you immediately whether this is edition limitation or enrollment scope/config.