Windows Autopilot enrollment failures with Hexnode and Intune device importSolved

For Windows Autopilot enrollment to work reliably, the device must be known to Microsoft Autopilot before the user starts the out-of-box experience. The usual workflow is:

1. Obtain the device hardware hash CSV from the device vendor or extract it from the device.
2. Upload the device information in Microsoft Intune admin center under Windows enrollment > Devices.
3. Create and assign a Windows Autopilot deployment profile in Intune.
4. Ensure automatic MDM enrollment is configured for the correct Microsoft Entra tenant/domain.
5. Make sure the user signing in during OOBE exists in Microsoft Entra ID and is allowed to enroll devices.
6. Complete the out-of-box setup using the user’s Entra credentials.

If the device is not imported into Autopilot/Intune or no deployment profile is assigned, Autopilot will not process the device as expected. This can make enrollment appear inconsistent, especially if some devices were previously imported and others were not.

Regarding Okta and Entra ID: Okta can handle identity management, but Windows Autopilot relies on Microsoft Entra ID during provisioning. If both Okta and Entra ID are integrated with Hexnode and both sync the same users, duplicate user entries may appear in Hexnode. This is not necessarily a device enrollment failure by itself, but it can make user assignment and auditing confusing. If possible, keep one consistent source for user provisioning into Hexnode or make sure user records are aligned across systems.

For existing devices, enrolling through the Hexnode enrollment URL or installer is a valid alternative. Once the Windows device is enrolled and managed, Hexnode can still apply policies, apps, and management actions. The main difference is the provisioning experience: Autopilot is intended for pre-provisioned, out-of-box enrollment, while the installer/enrollment URL is better suited for devices that are already set up.

That explains a lot. We had devices showing in the managed devices list, but not all of them were present in the Autopilot/Intune device list. We also didn’t have a proper deployment profile assigned for all devices. If I get the vendor to send the Intune/Autopilot CSV and upload that before the laptop is unboxed, should that be enough for the next device test?

Yes, that is the right direction. Before testing with a new laptop, confirm the following:

• The device hardware hash CSV is uploaded successfully in Intune.
• The device appears under Windows Autopilot devices.
• A deployment profile is assigned to the device or to a group containing the device.
• The profile assignment status has completed before the device is powered on for OOBE.
• The Microsoft Entra tenant/domain used for MDM enrollment is the intended one.

If the device has already gone through OOBE before being imported into Autopilot, you may need to reset the device to test the full Autopilot flow. For devices that are already in use, the Hexnode enrollment URL or installer can be used instead of wiping, depending on your deployment requirements.

One more question: if we keep both Okta and Entra ID connected, should every user exist in Okta, Entra, and Hexnode? Or should we remove one of the integrations to avoid duplicates?

For Autopilot, the user must exist in Microsoft Entra ID because Windows provisioning and automatic MDM enrollment are handled through Microsoft’s enrollment flow.

If Okta is your primary identity provider, users may still be synchronized into Entra ID depending on your identity architecture. Hexnode can also receive user information from integrated identity providers. When the same user is imported from both Okta and Entra ID, duplicate records can appear if the identities are not matched or consolidated.

Best practice is to keep the identity flow consistent:

• Use Entra ID as the required identity source for Windows Autopilot enrollment.
• Use Okta for authentication or identity workflows only where needed. –
• Avoid syncing the same users into Hexnode from multiple sources unless the setup is intentionally designed that way.
• If duplicate user entries already exist, clean them up carefully and standardize the source used for future user imports.

The duplicate entries do not automatically mean the Windows device is unmanaged, but they can cause confusion when assigning users, policies, or app catalogs.