MD-102 common mistakes
MD-102 · Understand the traps and how to avoid them.
Selects Windows Autopilot as the deployment method for a device that has never been registered (hardware hash never imported), or picks the self-deploying profile for a device that does not meet its prerequisites.
Autopilot appears in the portal as just another deployment profile, so candidates treat it as a generic Windows enrollment option and skip the 'device identity must exist first' step and the profile-type prerequisites (TPM 2.0, no user assignment, supported Windows version for self-deploying; assigned user needed for user-driven).
What to do instead
Confirm the device is present in the Autopilot devices list (hash imported from OEM/partner or captured with the Autopilot hardware hash script) before assigning a profile. Then match profile to scenario: user-driven for assigned users, self-deploying for kiosk/shared devices with TPM 2.0 and no user, pre-provisioning only where the hardware and network support it. For devices already in use, choose an enrollment method that does not require Autopilot.
Assigns a policy to a broad group such as All devices, then cannot explain why a device still does not receive it, or cannot explain why an administrator cannot see an object in the portal.
Two filtering layers are invisible unless you deliberately check them: group assignment evaluates include and exclude with the exclusion winning, and RBAC scope tags hide objects from admins whose assigned scope tags do not match. Candidates reason from 'the device is in the group' alone.
What to do instead
Trace assignments explicitly: read the policy's include/exclude groups, verify the device or user is actually a member (dynamic group rules may take time to evaluate), confirm the object's scope tag is inside the admin's scope tags, and read the per-device or per-user status blade for that specific object before changing the policy.
Uses a compliance policy as the enforcement mechanism, for example expecting Intune to actually configure a password length or encryption requirement because it was set in a compliance policy, or expecting a configuration profile by itself to block a user from signing in.
Compliance policies and configuration profiles look almost identical in the portal and both return per-device statuses, so the distinction between evaluating a device's state and pushing a setting gets lost under time pressure.
What to do instead
State the purpose out loud before choosing: compliance policies evaluate and report state and are consumed by Conditional Access; configuration profiles and settings catalog policies apply and enforce settings. To make a setting true, deploy a configuration profile. To gate access on a setting, deploy the compliance policy plus a Conditional Access policy that uses the compliant-device grant.
Deploys two configuration profiles or settings catalog policies that set the same setting to different values and assumes one will take precedence, or reads a 'Conflict' state as a sync failure.
Intune does not resolve precedence between configuration profiles the way Group Policy does, so overlapping settings commonly end in a conflict where the value is not applied. Candidates assume the last-deployed profile wins.
What to do instead
Keep one owner per setting: consolidate overlapping settings into a single profile per platform or workload, run the per-setting status and conflicts views to identify the two conflicting policies, and where true precedence is required use the appropriate CSP mechanism or a single authoritative policy instead of duplicating settings.
Designs a compliance policy that requires encryption or a PIN, then tells the customer that noncompliant devices will be blocked, without any Conditional Access policy; or ignores the 'mark device noncompliant after N days' schedule and the grace period when predicting behavior.
The compliance policy is the visible artifact that gets built and tested, while the Conditional Access grant that actually enforces it lives in a different blade and in Entra ID, so enforcement is assumed rather than configured. The noncompliance schedule also defaults quietly.
What to do instead
Pair every access-control requirement with an explicit Conditional Access policy using the 'Require device to be marked compliant' grant, scope it to the right users, apps, and platforms, and validate in report-only mode before enabling. Set the mark-noncompliant delay and grace period intentionally and describe when a device actually loses access.
Edits a security baseline expecting the built-in baseline to change, or stacks a security baseline on top of configuration profiles that set the same security settings and assumes the baseline will override them.
Security baselines are packaged collections of settings that behave like configuration profiles. The shipped baseline cannot be edited in place, and duplicate settings across baseline and profile produce conflicts rather than a defined winner, so candidates assume baseline has special authority.
What to do instead
Treat the baseline as a profile: deploy one baseline per platform, and if customization is required create a copy of the baseline and edit the copy. Read per-setting status to find overlaps with existing profiles and remove the duplicate settings from the profiles rather than waiting for a precedence rule to apply.
Assumes an app protection policy protects corporate data on unenrolled (BYOD) devices as soon as it is assigned, and expects it to restrict apps that are neither on the supported list nor built with the Intune SDK.
App protection policies are the headline MAM artifact, so candidates stop there and forget both the Conditional Access grant that makes the policy a requirement and the app compatibility boundary.
What to do instead
Verify the app is supported (a Microsoft app on the protected list or an app built with the Intune App SDK), assign the app protection policy to the user group, and add a Conditional Access policy that requires an app protection policy for the relevant client apps so unmanaged apps are blocked. Remember MAM-WE does not enroll the device, so device-level actions and compliance do not apply.
Deploys a Win32 app without a working detection rule (or with a detection rule that checks a path the installer never creates) and treats exit code 3010 as an installation failure.
Packaging is treated as 'wrap the installer and upload it', while detection rules and return-code handling are the actual success criteria. Candidates also apply the general rule that non-zero means failure, which is wrong for Win32 apps.
What to do instead
Package with the Intune content prep tool, install in the system context unless the app genuinely needs the user context, and set return codes deliberately (0 and 3010 are success, with 3010 indicating a soft reboot). Write a detection rule - MSI product code, file version, or registry value - that only evaluates true after a successful install, then validate on a test device and check the Intune Management Extension log for the agent-side result.
Deploys a PowerShell script through platform scripts and expects it to keep re-enforcing a setting forever, or expects it to run as the signed-in user or show an interactive UI.
Scripts are reached for as a generic automation tool, and the agent's execution model - run once per device with retries, system context by default, 32-bit PowerShell unless explicitly switched, no interactivity - is not visible in the deployment wizard.
What to do instead
Use platform scripts for one-time configuration: enable the 64-bit PowerShell option where the cmdlets require it, exit with 0 on success, and do not rely on user interaction. If the setting must be continuously enforced, use a configuration profile or settings catalog setting; if it must be checked and re-fixed on a schedule, use proactive remediations with a detection script and a remediation script.
Verifies a change by opening the report immediately after deployment and concludes the policy failed because devices still show Pending or Not applicable, or treats every Not applicable result as an error to fix.
Intune is not a real-time system: a device must check in before it reports a new state, and report data lags behind that. The per-device states also carry different meanings that candidates collapse into 'failed'.
What to do instead
Trigger a device sync from the portal or Company Portal, wait for the check-in cycle, and then read per-setting status. Interpret the states: Pending means the device has not reported yet, Not applicable means the setting does not apply to that OS or edition, Error carries a CSP or policy error code to decode, and Conflict means another policy sets the same value. Use reports and Endpoint Analytics for trend and fleet view, not as instant confirmation.