Troubleshooting practice questions

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.

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.

Deploy a line-of-business app

Why it fails: Deploying a line-of-business app installs software through the Intune management extension; it is configuration delivery, not a remote action against a device. It is tempting because app deployment is performed in the Intune admin center and is the correct choice when you need to distribute required applications to Windows 11 endpoints.

Create a VPN profile

Why it fails: A VPN profile is a configuration payload delivered by Intune, so it provisions settings rather than performing a remote action on a device. It is tempting because VPN profiles are created in the Intune admin center and target Windows 11 devices, making them the right choice when you need to distribute connection settings, not act remotely.

Assign a compliance policy

Why it fails: Compliance policies are assigned to users or device groups to evaluate settings and report state; they do not push configuration or execute remote actions on a device. Assignment targets devices, not live sessions. It is tempting because compliance results drive Conditional Access, which is a legitimate governance scenario, but not remote management.

Ensure the device is running Windows 10 Enterprise.

Why it fails: Kiosk mode assigned to a device group works on Windows 10 Pro as well as Enterprise, so edition is not the blocker. Enterprise licensing matters for Assigned Access multi-app configurations on older builds, but checking it first ignores the more likely assignment or sync fault.

Run the Policy Manager tool on the device.

Why it fails: Policy Manager is a legacy on-premises Group Policy tool and does not diagnose Intune-delivered configuration profiles. It suits troubleshooting domain-joined devices receiving GPOs, whereas Intune kiosk failures are investigated through device configuration status, assignment scope and MDM diagnostic logs.

Check the device's notification area for a policy update prompt.

Why it fails: Windows does not surface policy update prompts in the notification area; Intune policies arrive silently via the MDM channel during scheduled check-ins. Notification-area prompts relate to Windows Update or toast notifications, so this check yields nothing about why the kiosk profile failed to apply.

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.

The user's license status.

Why it fails: Licence status governs Intune enrolment and policy delivery, not the OS build number evaluated by the minimum-OS compliance rule. It is tempting because unlicensed users do hit compliance errors, and checking licensing would be right when a device fails to enrol or receive any policies at all.

The compliance policy is assigned to the device.

Why it fails: An unassigned policy would leave the device without any compliance state, yet it is explicitly marked Noncompliant, proving assignment occurred. It is tempting because assignment gaps commonly cause unexpected results, and verifying assignment would be correct when a device shows 'Not evaluated' rather than Noncompliant.

The device is connected to the internet.

Why it fails: Internet connectivity affects check-in timing, but the device already reported Noncompliant, so the OS version data reached Intune. It is tempting because stale check-ins cause outdated compliance states, and connectivity would be the right first check when a device shows no recent sync at all.

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 does not have internet connectivity.

Why it fails: The device has already reconnected, so connectivity is restored; 0x800f0831 reflects a servicing-stack or prerequisite failure rather than a download problem. Lack of internet access is tempting because offline devices cannot fetch updates, and would be the cause if the device were still disconnected.

The device does not have enough disk space.

Why it fails: Error 0x800f0831 indicates a missing prerequisite or superseded update in the servicing stack, not insufficient storage; disk exhaustion surfaces as 0x80070070. Low disk space is tempting because it commonly blocks Windows updates, and would be the cause if free space fell below the update's requirement.

The update is superseded and no longer applicable.

Why it fails: Superseded updates would not show as 'Failed to install'.

The user's password has expired.

Why it fails: SCEP certificate authentication validates a device certificate, not user credentials, so an expired password cannot block this Wi-Fi association; the user's other networks still work. Password expiry matters where PEAP-MSCHAPv2 or EAP-TTLS uses domain credentials, which is a different authentication method entirely.

The Wi-Fi profile is not assigned to the user's device.

Why it fails: An unassigned profile would leave no corporate SSID configured on the device, but the stem states a Wi-Fi profile is assigned and deployed. Assignment gaps are the cause when Intune shows no profile targeting the device group, not when a profile is present but authentication fails.

The device's Wi-Fi adapter driver is outdated.

Why it fails: An outdated driver would prevent all Wi-Fi connectivity, yet the user joins other networks successfully, so the adapter functions. Driver updates address hardware or firmware faults affecting every SSID; here the failure is scoped to one network requiring a valid SCEP-issued certificate.

The device does not have internet connectivity to download the app.

Why it fails: The stem states the device has been online for 24 hours, so connectivity exists and content download is possible; this contradicts the premise directly. It tempts because offline devices do stall deployments, but that scenario would show the device as inactive, not online with a Pending app.

The device's certificate for Intune is expired.

Why it fails: An expired Intune certificate breaks device check-in entirely, so the device would show as non-compliant or inactive rather than reporting a Pending app. It tempts because certificate renewal does fix enrolment faults, but that scenario affects all management traffic, not a single LOB deployment.

The device requires a restart to complete previous updates.

Why it fails: A pending restart delays some policy processing but does not hold a required LOB app in Pending for 24 hours; Intune would still deliver the content. It tempts because restarts do resolve stuck deployments, yet that scenario usually shows other policies also unapplied, not one app pending.

The device does not have a compliant operating system version

Why it fails: The exhibit would identify the actual failing setting; a generic OS version statement does not match the specific policy named in the output. It is tempting because OS version is a frequent compliance rule, and would be correct if the output flagged a minimum operating system build as the failure.

The device is not running a supported version of Windows 10

Why it fails: The Graph output would show a specific compliance policy setting failing, not an unsupported Windows build, so this misreads the exhibit. It is tempting because OS version is a common compliance rule, and would be correct if the output flagged a minimum build requirement as the failing setting.

The device has a third-party antivirus installed

Why it fails: Third-party antivirus alone does not cause non-compliance unless a policy requires a specific antivirus state; the exhibit would name that setting. It is tempting because antivirus status is a common compliance rule, and would be correct if the output showed the antivirus requirement failing.

Use a PowerShell script to install the app on failed devices.

Why it fails: Scripts might help but logs are needed to diagnose first.

Create a new device group and assign the app again.

Why it fails: Group membership is not the issue.

Re-assign the app to the device group.

Why it fails: Re-assigning won't resolve the underlying installation error.

Confirm that the user is assigned a Microsoft Entra ID P1 license.

Why it fails: Entra ID P1 licensing governs conditional access and autopilot-related features, not the MDM enrolment path itself; domain-joined devices enrolling after an update typically fail on automatic MDM enrolment configuration, such as the MDM user scope or GPO. P1 is tempting because licensing errors do block some Intune scenarios.

Verify that the BitLocker recovery key is backed up to Microsoft Entra ID.

Why it fails: BitLocker recovery key escrow is unrelated to MDM enrolment; it concerns disk-encryption key storage after a device is managed. It is tempting because it is an Entra ID device setting commonly configured alongside Intune, but the enrolment failure after a Windows update points to automatic MDM enrolment scope or policy configuration instead.

Ensure the Windows Defender Firewall allows inbound RPC traffic.

Why it fails: MDM enrolment uses outbound HTTPS to Intune, not inbound RPC, so firewall rules for RPC are irrelevant to this failure. RPC inbound rules matter for on-premises management or remote administration traffic, which is a different scenario entirely.

The device is marked as non-compliant.

Why it fails: Non-compliance is an outcome of policy evaluation, not a blocker of it; a non-compliant device still receives and applies policies. It is tempting because compliance status appears alongside policy status in the console, and conditional access blocks would be the concern if resources were inaccessible.

The device does not have a valid device certificate.

Why it fails: A missing device certificate breaks the mutual TLS channel used for MDM check-ins, but the stem states the device is enrolled and connected, so authentication is functioning. It is tempting because certificate failures do cause policy delivery errors, typically after a device is wiped or its certificate is revoked.

The device enrollment profile has expired.

Why it fails: Enrolment profiles govern initial device onboarding, not ongoing policy evaluation, and an expired profile would not leave an enrolled device showing Pending. It is tempting because expired profiles do block enrolment, which would be the cause if the device had never successfully enrolled.

Confirm that Office is updated to the latest version.

Why it fails: Office version affects add-in compatibility, but the AIP client installs its own COM add-in regardless of minor build differences. Checking updates is tempting because add-ins can be disabled after Office upgrades. The add-in must instead be enabled in the AIP client's Office integration settings and loaded in each Office app.

Verify that the user has local administrator rights.

Why it fails: The AIP add-in loads per user under Office, so local administrator rights are irrelevant to its visibility. Administrator rights matter when installing system-wide components or drivers. The add-in is registered through the user's Office profile and enabled via the AIP client's Office integration setting.

Check if the device has internet access to activate the client.

Why it fails: Internet access is needed for labelling and protection services, but the add-in's presence in the Office ribbon is determined locally, not by connectivity. Connectivity is tempting because activation failures produce errors. The add-in is registered by the client installer and enabled through Office add-in management.

The device is not Microsoft Entra ID joined

Why it fails: Entra ID join is not required for app installation.

The device has insufficient disk space

Why it fails: Insufficient space would produce a different error.

The app is not signed

Why it fails: Unsigned apps might be blocked by policy, but 'Access Denied' is different.