The Scenario

Following a workstation migration, the PowerSyncPro Migration Agent successfully completes its runbook phases. The device joins the new target Entra ID and the user can log in with their new credentials. However, the device fails to appear in the Intune portal, or the agent logs continuously report that Intune enrollment has not succeeded.

Technical Mechanics: How PowerSyncPro Handles Enrollment

To troubleshoot enrollment failures, it is important to understand how PowerSyncPro interacts with Intune.

• No Forced Injection: The PowerSyncPro Migration Agent cannot forcibly enroll a device or "inject" a device directly into the Intune backend.
• Windows Native Triggers: Under normal operating conditions, Intune enrollment is handled natively by Windows via the scheduled task: "Schedule created by enrollment client for automatically enrolling in MDM from AAD", which executes once at user logon.
• The Hourly Retry: If the Enroll Devices to Intune option is selected in your runbook, the PowerSyncPro agent will check the enrollment status. If it detects the device is not enrolled, it will actively call DeviceEnroller.exe every hour until it sees a successful enrollment, updating the event logs on each attempt.

PowerSyncPro relies on native Windows components and the user's active session to execute this process. As a result, failures are almost always caused by misconfigurations within the target tenant's Entra ID or Intune portal blocking the device from registering.

Requirements & Root Causes

If Intune enrollment is failing, verify the following configurations in your target Microsoft 365 tenant.

1. Multi-Factor Authentication (MFA) Blocks

During the automated migration and background enrollment process, interactive MFA prompts will cause the silent enrollment to fail.

Conditional Access: You should explicitly exclude the Microsoft Intune Enrollment cloud app from MFA requirements within your Conditional Access policies (under Target resources).

If Microsoft Intune Enrollment app is missing you may need to add it via Microsoft Graph:

Connect-MgGraph -Scopes "Application.ReadWrite.All"

New-MgServicePrincipal -AppId “d4ebce55-015a-49b5-a083-c84d1797ae8c”

2. MDM vs. WIP User Scope Conflicts

In the Entra portal (under Mobility (MDM and WIP)), the user logging into the device must be included in the MDM user scope (set to All or a specific group).

3. Device Platform Restrictions (Personal vs. Corporate)

By default, Intune may block personally owned devices from enrolling. Because the automated migration process triggers the Intune registration using the logging-in user's credentials, the Intune backend initially evaluates this action as a "personal" enrollment attempt.

Therefore, your Intune Device Platform Restrictions must be configured so that Personally owned Windows devices are set to Allowed.  If your organization is unable to allow personal device enrollments, see below for an alternative using Intune Corporate Identifiers.

Alternative: Pre-register devices via Corporate Device Identifiers

Some organizations cannot enable personally owned Windows enrollments at all — even when scoped to a migration security group — due to internal security or compliance policy. For these tenants, Microsoft offers an alternative path: pre-register migrating devices with Corporate Device Identifiers in Intune before the migration runs. When the device subsequently attempts auto-enrollment, Intune matches it against the identifier list and treats the enrollment as corporate, bypassing the personal-device platform restriction entirely.

What to collect

Each Windows identifier is a single comma-separated string of Manufacturer,Model,SerialNumber, read from the device itself. Microsoft publishes a one-line snippet to retrieve the exact values Intune will attempt to match:

(Get-WmiObject -Class Win32_ComputerSystem | ForEach-Object {$_.Manufacturer, $_.Model, (Get-WmiObject -Class Win32_BIOS).SerialNumber -join ',' })

Run this on a representative device first — OEM-reported manufacturer and model strings are not always what you'd expect (e.g. "LENOVO" vs "Lenovo", or model strings that include trailing whitespace), and the match is exact.

Loading identifiers into Intune

Identifiers can be added through any of three methods, in increasing order of automation:

• CSV upload via the admin center — Devices → Enrollment → Corporate device identifiers → Add → Upload CSV file, selecting Manufacturer, model, and serial number (Windows only). Suitable for smaller batches; note Intune limits Windows identifier uploads to 10 CSV files in the admin center.
• PowerShell against Microsoft Graph — appropriate for larger fleets or where the identifier list is generated from another inventory source (CMDB, Configuration Manager, Autopilot hardware report, etc.).
• Direct Microsoft Graph API calls — for full automation as part of a pre-migration prep workflow.

For the Graph-based options, the relevant endpoint is POST /beta/deviceManagement/importedDeviceIdentities/importDeviceIdentityList, the identifier type is manufacturerModelSerial, and the calling principal requires the DeviceManagementServiceConfig.ReadWrite.All permission. Refer to the Microsoft documentation linked at the end of this section for the full schema.

Verification

After upload, confirm the identifier appears under Devices → Enrollment → Corporate device identifiers. The Status column will show Not contacted until the device enrolls, then transition to Enrolled. A status of Failed after a known enrollment attempt usually indicates a manufacturer/model string mismatch — re-run the WMI snippet on the actual device and compare character-for-character.

References

• Identify devices as corporate-owned (Microsoft Learn)
• importDeviceIdentityList action (Microsoft Learn)

4. Missing DNS Records (CNAME)

Auto-enrollment requires proper DNS routing. Ensure your domain has the correct CNAME records pointing to Microsoft's enrollment servers (enterpriseenrollment.windows.net and enterpriseenrollment-s.manage.microsoft.com). You can validate these records directly within the Intune Admin Portal under Enrollment options -> CNAME Validation.

5. Licensing Requirements

The user logging into the migrated workstation for the first time must be assigned a valid license that includes Intune (such as an EMS or Microsoft 365 Business Premium/E3/E5 license) to be allowed to enroll devices.  You can also license users with an Intune Plan 1 license to allow for Intune Enrollment.

OS Support & Requirements

Supported Editions for Intune Enrollment

• Windows 10/11 Pro
• Windows 10/11 Enterprise
• Windows 10/11 Education
• Windows 10/11 Pro Education

Enrollment Methods and Version Requirements

Azure AD Join + Automatic Enrollment

Requires Windows 10, version 1709 or later.

Hybrid Azure AD Join

Supported on Windows 10, version 1607 or later but works best with version 1709+.

Bring Your Own Device (BYOD)

Personal devices can be enrolled using the Company Portal app with Windows 10, version 1709 or later.

Diagnostics & Event Logs

When troubleshooting enrollment issues, you should check both the PowerSyncPro console and the native Windows Event Viewer on the affected workstation.

1. PowerSyncPro Agent Logs

The PowerSyncPro Agent Logs console provides centralized, high-level visibility into the hourly enrollment attempts.

• Success: If the background registration succeeds, the console will output: "Intune enrollment completed".
• Error 0x80180014 (Personal Devices Blocked): You will see Intune enrollment failed with exit code: 0x80180014 if your Intune Device Platform Restrictions are configured to block personally owned Windows devices.
• Error 0x8018002A (No MFA Token): You will see Intune enrollment failed with exit code: 0x8018002A if the Microsoft Intune Enrollment cloud app is not excluded from your Conditional Access policies, blocking the system from silently obtaining the required PRT.
  • This will clear once the user logs into Entra with MFA and gets an MFA-backed PRT and DeviceEnroller is triggered by the Migration Agent.
• Error 0x80180031 (MDM Not Configured): You will see Intune enrollment failed with exit code: 0x80180031 (MENROLL_E_MDM_NOT_CONFIGURED) when the device is missing the MDM Enrollment URLs required to reach Intune. This is most often caused by the user falling outside the MDM user scope in Entra ID, missing/misconfigured CNAME records, or the MdmEnrollmentUrl, MdmTermsOfUseUrl, and MdmComplianceUrl registry values being absent under HKLM:\SYSTEM\CurrentControlSet\Control\CloudDomainJoin\TenantInfo\<TenantID>. You can confirm the registry state by running dsregcmd /status on the workstation and reviewing the Device Management section — if the MDM URLs are blank, the device has no enrollment endpoint to call.
  • This will clear once the MDM scope, CNAME records, and tenant registry values are corrected and DeviceEnroller is triggered by the Migration Agent on its next hourly retry.

2. Native Windows MDM Logs

If the workstation has temporarily lost communication with the PSP Server, or if you need deeper OS-level diagnostics, check the local event logs on the workstation:

• Open the Windows Event Viewer and navigate to: Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider.
• Check the Admin and Enrollment logs for specific Error or Warning events generated at the time of user logon.

Microsoft Learn Resources

For deeper troubleshooting of native Windows enrollment behaviors and a full index of MDM exit codes, refer to the following official Microsoft documentation:

• Troubleshoot device enrollment in Microsoft Intune
• Troubleshoot Windows device enrollment errors in Microsoft Intune