Intune Enrollment Post-Migration: Requirements & Troubleshooting
A guide to verifying target tenant prerequisites and resolving auto-enrollment failures for migrated workstations.
Written by Conrad Murray
Updated at April 24th, 2026
Table of Contents
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.exeevery 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”
💡MFA-Backed PRTs and Delayed Enrollment
If the Microsoft Intune Enrollment app is not excluded from your Conditional Access MFA policies, the initial background enrollment will fail. This occurs because the system lacks the MFA-backed Primary Refresh Token (PRT) required to authorize the registration.
However, this is not a permanent failure. The PowerSyncPro Migration Agent is designed to continuously re-attempt the Intune enrollment every hour. Once the user satisfies an MFA prompt during their normal workflow—such as signing into a Microsoft 365 desktop application or setting up Windows Hello for Business (both of which generate the required PRT)—the requirement will be met. The system will then successfully enroll into Intune during the agent's next hourly retry.
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).
|
|
⚠️ WIP Precedence
If a user is included in both the MDM user scope and the Windows Information Protection (WIP) user scope, WIP takes precedence. When this happens, Windows Information Protection policies are applied, but the actual Intune MDM enrollment will be skipped entirely. Ensure the WIP user scope is set to None (or that migrating users are excluded from it) if you require full MDM enrollment.
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.
💡 The Final Enrollment State & Scoping
- Corporate Status: Even though the "Personally owned" restriction must be lifted to allow the registration to initiate, the final resulting enrollment will automatically be recorded as a Corporate enrollment in your Intune portal.
- Security Scoping: You do not need to open up personal device enrollments for your entire tenant. To maintain strict security, you can create a custom Device Platform Restriction policy that allows personal Windows enrollments and assign it only to a specific security group containing the users who are currently migrating.
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: 0x80180014if 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: 0x8018002Aif 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.
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