3.4 Configuration Profiles and Assignment Filters

Configuration profile model

A device configuration profile is how Intune pushes settings to enrolled devices. Profiles are platform-specific. A Wi-Fi profile, VPN profile, certificate profile, device restriction profile, Settings catalog policy, and custom OMA-URI profile are all configuration-profile patterns, but not every platform supports every profile type. The first decision on any configuration question is platform, and the second is profile type.

Settings catalog, templates, custom settings, and ADMX

Intune commonly asks you to choose between Templates and Settings catalog. Templates group settings around a scenario such as VPN, Wi-Fi, kiosk, certificates, or domain join. Settings catalog is broader and more granular. It is the right answer when the question says you need the broadest built-in list of Windows settings, a specific CSP-backed setting, or an ADMX-backed policy without writing a custom OMA-URI.

For Windows, the Settings catalog includes many built-in administrative template (ADMX) settings. If the setting is already built in to Windows and exposed through Intune, do not import the built-in ADMX just to configure it; use Settings catalog or, when necessary, a custom profile.

Import custom ADMX and ADML files when a third-party or partner administrative template is not already available in Intune, such as a non-Microsoft browser or a line-of-business app's policy template. Once imported, those settings can be used in a device configuration policy and assigned to managed Windows devices.

Use custom settings when the setting is not otherwise available in any profile type. On Windows, that often means a custom OMA-URI that targets a CSP path. On Apple platforms, custom profiles can use Apple configuration files where the built-in UI does not expose the setting.

Assignment: users, devices, and filters

Profile assignment starts with Microsoft Entra user groups or device groups. Choose the group type based on what the setting controls:

• Use device groups for device-scoped settings, self-deploying Autopilot devices, kiosks, shared devices, and Windows Enterprise multi-session device-scope policies.
• Use user groups when the setting should follow the signed-in user and the platform supports user-scope management.
• Avoid assigning user-scope settings to device groups or device-scope settings to user groups when the platform reports them as not applicable.

Assignment filters do not replace groups. They refine a group assignment with device or app properties. For managed devices, filters can evaluate properties such as platform, manufacturer, model, OS version, operating system SKU, ownership, enrollment profile name, and similar inventory values. A policy assignment can include matching devices or exclude matching devices.

Filter evaluation happens when a device enrolls, checks in, or when policy evaluation occurs. This is useful when a group is broad but a profile should apply only to a subset, such as corporate Windows devices in Marketing, iPads in Finance, or Windows 11 devices with a supported SKU. The exam pattern is: one broad group plus a filter to narrow it, rather than creating dozens of fine-grained groups.

Windows 11 Enterprise multi-session detail

Windows 11 Enterprise multi-session is an Azure Virtual Desktop edition that allows multiple concurrent user sessions. Intune can manage it, but it is not the same as a standard physical Windows client, and several familiar tools do not apply.

Use these rules for MD-102:

• Create configuration policies for multi-session hosts with the Settings catalog.
• In the settings picker, filter OS edition to Enterprise multi-session to see supported settings.
• Device-based configuration targets device groups; user-based configuration targets user groups.
• Templates are not generally supported except supported certificate templates.
• OOBE enrollment, Windows Autopilot, and the Enrollment Status Page are not supported for Windows Enterprise multi-session.
• Some remote actions and Windows update ring policies are unsupported, so use supported Settings catalog options where available.

Scenario shortcut

If the question asks for one policy assigned to a broad group but only corporate-owned Windows 11 devices should receive it, use an assignment filter. If it asks for a third-party browser ADMX not present in Intune, import custom ADMX and ADML. If it asks for the broadest first place to find Windows settings, use Settings catalog. If it asks for Windows 11 Enterprise multi-session configuration, use Settings catalog with the Enterprise multi-session filter. Matching the requirement to one of these four moves resolves most configuration-profile questions quickly.

User scope versus device scope

Many configuration-profile mistakes come from confusing user scope and device scope. A device-scoped setting applies to the machine regardless of who signs in; a user-scoped setting follows the signed-in user where the platform supports it. If you assign a device-scoped policy to a user group, or a user-scoped policy to a device group, the platform may report the setting as Not applicable rather than failing loudly, which is hard to troubleshoot. When a scenario describes a setting that should apply to a kiosk, a shared device, or a self-deploying Autopilot machine with no fixed user, assign to a device group.

When the setting should travel with a person across their devices, assign to a user group on a platform that supports user-scope management.

Filters, groups, and conflicts

Groups decide the broad audience; filters narrow it; and when two profiles set the same setting differently, Intune reports a conflict and the setting may not apply predictably. Resolve conflicts by consolidating overlapping profiles rather than stacking more filters. Remember the precedence rules that appear elsewhere in Intune as well: device-targeted assignments often take precedence over user-targeted ones for the same policy area, and an explicit exclude can override an include.

On the exam, if a profile that should apply does not, check three things in order: the platform and profile type are correct, the assignment targets the right group, and no filter or conflicting profile is silently excluding or overriding the setting. This ordered check mirrors how a real endpoint administrator diagnoses a misapplied profile, and it is exactly the reasoning MD-102 rewards.