Troubleshooting Scenario Questions

1) Check enrollment logs. 2) Retry enrollment. 3) Verify user license and connectivity. 4) Verify DNS, certificate, and GPO prerequisites.

Why it fails: This is incorrect because checking logs without first ensuring basic connectivity and licensing may lead to misinterpreting errors, and retrying before verifying prerequisites can waste time.

1) Verify DNS, certificate, and GPO prerequisites. 2) Retry enrollment. 3) Check enrollment logs. 4) Verify user license and connectivity.

Why it fails: This is incorrect because you should first check the most common and simple issues (licensing/connectivity) before diving into prerequisites, and retrying too early may repeat the same failure.

1) Retry enrollment immediately. 2) Verify user license if fails. 3) Check enrollment logs. 4) Verify DNS, certificate, and GPO prerequisites.

Why it fails: This is incorrect because retrying without any troubleshooting is inefficient; you should diagnose the root cause first before attempting again.

Reissue the user's Microsoft 365 license from the admin center.

Why it fails: Licensing governs service access, not policy assignment; a licensed user with a correctly targeted device still receives policy. Reissuing is tempting when a user cannot sign in or Intune reports an unlicensed state, but the device is enrolled and reporting compliance, so licensing is not the failing dependency.

Reset the device's enrollment state via the Company Portal.

Why it fails: Resetting enrollment state removes the device's Intune and Microsoft Entra ID registration, forcing re-enrolment and wiping work data; it does not deliver the missing policy. It tempts when a device is stale or duplicated, where re-enrolment genuinely fixes sync. Here the device already reports compliance status, so the management channel is intact.

Run Invoke-Command to remotely execute gpupdate /force.

Why it fails: gpupdate /force refreshes Group Policy from on-premises domain controllers; it has no effect on Intune MDM policy, which arrives via the MDM channel and the Intune Management Extension. It tempts on hybrid-joined devices where Group Policy and Intune coexist, but the stem concerns Intune policy delivery specifically.

Recreate the Wi-Fi profile in Intune with new settings

Why it fails: Recreating the profile discards the existing configuration before any evidence is gathered, so the actual cause of the post-update failure is never identified. It is tempting because redeploying a profile is the standard remedy when Intune policy is confirmed corrupt or stale, but that diagnosis must come first.

Run the 'netsh wlan show profiles' command on affected devices

Why it fails: Listing cached profiles only confirms the SSID exists on the device; it reveals nothing about why association or authentication now fails after the update. It is tempting because netsh wlan commands are the standard way to inspect saved wireless configurations, and would be the right first step when a profile is missing or misconfigured locally.

Review Microsoft Entra ID sign-in logs for authentication failures

Why it fails: Entra ID sign-in logs record identity authentication events, not 802.1X or Wi-Fi association failures, so they cannot show why the wireless connection drops. It is tempting because Entra ID is central to Conditional Access and device compliance, and sign-in logs would be correct for diagnosing token or sign-in failures.

Check AppLocker logs in Event Viewer

Why it fails: AppLocker writes to its own AppLocker logs, a separate mechanism from WDAC; a WDAC-blocked binary records events under Microsoft-Windows-CodeIntegrity/Operational instead. It tempts because AppLocker is the older application-control feature with similar allow-list goals, but its logs never capture WDAC policy decisions.

Review Intune device management events for policy errors

Why it fails: Intune device management events report policy assignment and delivery status, not per-binary execution decisions, so a blocked app's file hash or signer never appears there. It tempts because Intune is the deployment channel, but WDAC enforcement evidence lives in the CodeIntegrity operational event log on the device.

Check Microsoft 365 Defender portal for WDAC alerts

Why it fails: The Microsoft 365 Defender portal surfaces Defender antivirus and attack detections, not WDAC CodeIntegrity block events, which are written locally to the device's event log. It tempts because Defender and WDAC both harden endpoints, yet only the CodeIntegrity log names the blocked file and policy that denied it.

The device has a VPN configuration installed.

Why it fails: A VPN configuration does not register a device with an MDM authority, so it cannot trigger the "already enrolled" error. VPN profiles merely route traffic through a tunnel. This would be relevant when troubleshooting connectivity to Intune endpoints, not enrolment conflicts. The error stems from a stale MDM enrolment record, typically in Microsoft Entra ID or Apple Business Manager.

The device is not running the latest iOS version.

Why it fails: An outdated iOS build cannot trigger an "already enrolled in another MDM" error; that message comes from a stale MDM enrolment record, either in Microsoft Entra ID or Apple Business Manager, blocking re-enrolment. Version checks matter when a device fails the minimum OS requirement for a configuration profile or compliance policy, not for duplicate-enrolment conflicts.

The user's license is expired.

Why it fails: An expired licence blocks enrolment entirely, producing a licensing or subscription error rather than the "already enrolled in another MDM" message, which Intune returns when a device record or MDM enrolment profile already exists. Licensing failures are tempting because they do halt enrolment, and would be the answer if the error cited an inactive user licence.

Configure a Conditional Access policy

Why it fails: Conditional Access does not affect policy delivery.

Reset the user's password

Why it fails: User credentials do not affect policy delivery.

Review the app protection policy assignment

Why it fails: App protection policies are for app data, not device policy delivery.

Ensure that the device has a policy to allow installation of unapproved apps.

Why it fails: Fully managed devices only install apps from the managed Play Store, so a policy permitting unapproved app installation does not govern this failure and addresses sideloading instead. That setting would be relevant when allowing users to install APKs outside the managed store, not for a managed Play Store deployment that is already approved.

Check if the device's enrollment token is still valid.

Why it fails: Enrolment tokens are consumed at enrolment; the device is already enrolled and receiving policies, so token validity cannot block an app install. Checking tokens would be correct when a new device fails to enrol or when a bulk enrolment token has expired before provisioning.

Check if the app is available in the unmanaged Play Store.

Why it fails: Fully managed devices cannot use the unmanaged Play Store, so availability there is irrelevant to this failure. Verifying unmanaged store availability would be the correct check for personally owned work profile devices, where apps come from the public Play Store rather than the managed one.

The user does not have a macOS license

Why it fails: Licensing failures block enrolment or show as unlicensed, not as a settings 'Conflict' between assigned profiles. It is tempting because licensing does gate Intune features, but the conflict status specifically indicates overlapping configuration payloads targeting the same macOS setting.

The macOS version is not supported by the profile

Why it fails: An unsupported OS build yields an applicability or error status, not 'Conflict', which arises when two profiles assign contradictory values to one setting. Version mismatch is tempting because it commonly breaks profile deployment, but Intune distinguishes inapplicability from settings collision.

The device is not connected to the internet

Why it fails: A connectivity gap produces 'Not applicable' or pending status, not 'Conflict', which Intune reports when two assigned profiles set the same setting to different values. Offline devices are tempting because they explain non-delivery, but the console would show a pending state instead.

The device is running Windows 10 Home edition.

Why it fails: Windows 10 Pro is confirmed in the stem, so Home edition cannot be the cause; Home lacks the MDM enrolment client entirely. Home edition would be the answer if the device genuinely ran Home and needed upgrading to Pro before Intune enrolment could succeed.

The device is not connected to the internet.

Why it fails: Error 0x8018000b indicates the device is already enrolled or has a stale management profile, so connectivity is not the cause; a licensed Windows 10 Pro device can reach Intune. It tempts because network loss commonly blocks enrolment, but here the MDM profile must be removed first.

The device has an expired certificate required for enrollment.

Why it fails: Error 0x8018000b signals the device is already enrolled or has a stale MDM enrolment record, not certificate expiry. Certificates matter for certificate-based authentication or Wi-Fi/VPN profiles, so an expired enrolment certificate would be the culprit in a certificate-authority renewal scenario, not this error.

The app requires a reboot to complete installation

Why it fails: A pending reboot does not by itself cause the same app to reinstall repeatedly; Intune would report the install as complete pending restart. It is tempting because reboot-dependent installs do fail detection, but the loop here stems from the installer's exit code being interpreted as failure.

The detection rule runs before the install completes

Why it fails: Detection rules are evaluated after the install completes, so a rule running early would not itself trigger repeated reinstalls; the log would instead show a detection mismatch. It is tempting because timing faults do cause loops, but the actual mechanism here is the installer returning a non-zero exit code treated as failure.

The exit code 0 is misinterpreted as failure

Why it fails: Intune treats exit code 0 as success, so it cannot be misread as failure; a zero code ends the install cleanly. It is tempting because exit-code handling does govern retries, but the loop arises when the installer returns a non-zero code that is not mapped as success, prompting reinstallation.

Step 1: Identify the cause of the prompt, Step 2: Address the root cause to prevent recurrence, Step 3: Retrieve the BitLocker recovery key, Step 4: Enter the recovery key to unlock the drive.

Why it fails: This is incorrect because you cannot address the root cause while the drive is locked; you must first unlock the drive by entering the recovery key after retrieving it.

Step 1: Retrieve the BitLocker recovery key, Step 2: Enter the recovery key to unlock the drive, Step 3: Identify the cause of the prompt, Step 4: Address the root cause to prevent recurrence.

Why it fails: This is incorrect because you should first understand why the prompt appeared before retrieving the key; otherwise, you might waste time retrieving the wrong key or miss critical context.

Step 1: Address the root cause to prevent recurrence, Step 2: Identify the cause of the prompt, Step 3: Retrieve the BitLocker recovery key, Step 4: Enter the recovery key to unlock the drive.

Why it fails: This is incorrect because you cannot address the root cause without first identifying it, and you must unlock the drive before any fix can be applied.

Ensure the devices have internet connectivity

Why it fails: Internet connectivity affects delivery of the app content, but Intune dependency resolution occurs through the management channel and fails when the prerequisite app's assignment does not target those devices. It is tempting because connectivity causes many deployment failures, and it would be correct for devices that never check in.

Verify that the app is signed with a trusted certificate

Why it fails: Code-signing trust governs whether Windows permits installation, but a dependency failure means the prerequisite app is not installed first, so signing is irrelevant here. It is tempting because unsigned apps do fail, and verifying the certificate would be correct for a standalone app rejected by Windows.

Recreate the deployment policy

Why it fails: Recreating the policy discards configuration without diagnosing why the dependency is unresolved on those devices, so the same failure recurs. It is tempting as a quick reset, and it would be correct where the policy itself is corrupted or its assignments are misconfigured.

Uninstall the app from the affected devices and reassign it as Required.

Why it fails: Uninstalling may not resolve the underlying issue and could cause data loss.

Reassign the app to the device group with a different assignment type.

Why it fails: Assignment type is already Required; changing it is not necessary.

Run gpresult /r on a device to confirm the app assignment policy is applied.

Why it fails: Group Policy is not used for Intune-managed devices.

Verify the device is compliant with compliance policies

Why it fails: Compliance policy evaluates device posture, not application delivery; a non-compliant device can still receive required apps unless a conditional access rule blocks it. It is tempting because compliance gates access, but app installation failures are diagnosed through assignment scope, group membership and Intune Management Extension logs.

Perform a factory reset on the device

Why it fails: A factory reset wipes the device and re-enrols it, destroying logs and state needed for diagnosis without addressing the assignment failure. It is tempting as a last-resort remediation, but it is a destructive action, not a diagnostic step; checking assignment status, sync status and policy conflicts comes first.

The device will be allowed to proceed because enrollment status is notStarted.

Why it fails: A notStarted enrollment status does not let the device proceed; the ESP blocks until status resolves. It is tempting because notStarted sounds like a neutral, non-blocking state, and it would be correct when describing a device that has not yet begun the enrollment status page sequence.

The device will retry enrollment automatically.

Why it fails: Autopilot does not retry a failed app installation; the enrolment error blocks OOBE until the app installs or the profile is corrected. Retry logic applies to transient network or MDM service errors, so this would fit a device that lost connectivity mid-enrolment, not one failing a required app.

The device will be blocked until retry due to pendingRetry setting.

Why it fails: Autopilot's pendingRetry setting does not block the device; it governs the retry interval for the enrollment status page. It is tempting because retry logic sounds like a blocking mechanism, and it would be correct when configuring how long the ESP waits before reattempting a failed app installation.