Intune Device Filters

原文：Intune Device Filters — theDXT (Daniel Keer)

As the end of Windows 10 starts creeping up we have to adapt some of our methods to support mixed environments with Windows 10 and Windows 11.

Most settings in Microsoft Intune aren't specific to Windows 10 or Windows 11 — some settings are specific to the version. For example, one of them is the Windows Start Menu. Windows 10 uses an XML file and Windows 11 uses a JSON file. Technically there's no impact if you deploy those settings to either version of Windows but that might not always be the case. It's a better idea to only target the intended version of Windows.

A way that I like to handle this is with Intune Device Filters. In this post, I'll show you step-by-step how to create Device Filters for Windows 10 and Windows 11 in Microsoft Intune.

Why Version Targeting Matters Now

Windows 10 reached end of support on 14 October 2025, but very few organisations were able to finish the migration before that date. The realistic outcome for most estates is a long tail: a majority of devices on Windows 11, a stubborn minority still on Windows 10 with Extended Security Updates, and a small group of devices that cannot be upgraded at all because of a line-of-business application or an old driver. Meanwhile hardware refresh cycles mean new Windows 11 machines arrive every month.

In that mixed state, per-version configuration stops being a nice-to-have. The obvious example is the Start Menu layout — a Windows 10 XML layout is meaningless on Windows 11, and the Windows 11 JSON layout does nothing on Windows 10 — but it is not the only one. Taskbar pinning, some Settings-page restrictions, and several of the newer policy CSPs behave differently across versions. Deploying the wrong artefact is usually harmless, but "usually harmless" is not a property you want in a configuration baseline, because the failure mode when it does bite is an inconsistent user experience that is hard to reproduce.

Device Filters vs Dynamic Device Groups

The traditional way to scope a policy to a version was a dynamic Azure AD device group with a rule such as (device.deviceOSType -eq "Windows"). That approach still works, but it has real costs:

• Membership is evaluated asynchronously, so a newly enrolled device can take minutes or hours to appear in the group, and the policy then takes another round of check-ins to apply.
• Group membership requires a licence for group-based assignment in some scenarios, and every group-based licence assignment counts against limits.
• A device is either in the group or not; you cannot attach several independent conditions to a single assignment and combine them at evaluation time without authoring an increasingly complicated rule.
• Dynamic groups show up in reports as separate scopes, which means more reporting objects to explain.

Assignment filters solve the same problem inside Intune itself. A filter is a reusable rule that is attached to an assignment rather than to a group, and it is evaluated by the Intune service when it decides whether a device should receive the payload. There is no directory membership to wait for, no group object to create, and because filters are referenced by assignments, one filter can be reused across dozens of policies. For version targeting specifically, filters are the better tool.

What a Filter Rule Looks Like

Filter rules use a Kusto-style syntax with a device. prefix on the property name and dash-prefixed operators:

(device.osVersion -startsWith "10.0.2")
(device.osVersion -startsWith "10.0.1")
(device.deviceName -startsWith "LAP-")
(device.osVersion -startsWith "10.0.2") -and (device.deviceOwnership -eq "Corporate")

The rule builder in the portal generates exactly this text for you, and you can switch to the raw syntax view at any time with Edit on the rule. Available properties differ by platform, but for Windows you get things like osVersion, deviceName, manufacturer, model, deviceOwnership and enrollmentProfileName. Operators include equality, starts-with, contains, ends-with and the negated forms, and you can combine them with -and, -or and -not in brackets.

The Process

• Login to Microsoft Intune admin center.
• Click on Devices.

• Click on Filters.

• Click on Create > Managed devices.

• Give your Filter a name. Like Windows 10 or Windows 11. Add a description that says what the filter is for and who owns it — filters are referenced from many assignments later, and the name alone will not be enough six months from now.
• Set the Platform as Windows 10 and later.

• Set the Property to osVersion (OS version).

• Set the Operator to StartsWith.

• Use the following Values for Windows 10 and Windows 11:
  • For Windows 10 enter 10.0.1
  • For Windows 11 enter 10.0.2

If you want to double-check your filter click on Preview. It runs the rule against the devices currently in scope and shows you which ones match, which is the fastest way to catch a typo before you assign the filter to production policies.

You can also just click Edit on the Rule syntax and paste the following:

• For Windows 10: (device.osVersion -startsWith "10.0.1")
• For Windows 11: (device.osVersion -startsWith "10.0.2")

Now you can use the newly created Device Filters in your Intune settings.

How the Version Trick Actually Works

The reason 10.0.1 and 10.0.2 are enough is that Windows version numbers are four-part and the third part is the build number, which is where the operating system generation becomes visible. Windows 10 builds are in the 10.0.1xxxx range, and Windows 11 builds are in the 10.0.2xxxx range, so a plain string comparison on the prefix separates them cleanly:

• Windows 10 21H2 / 22H2 — 10.0.19044 / 10.0.19045, matched by 10.0.1
• Windows 10 1809 LTSC — 10.0.17763, matched by 10.0.1
• Windows 11 21H2 — 10.0.22000, matched by 10.0.2
• Windows 11 22H2 — 10.0.22621, matched by 10.0.2
• Windows 11 23H2 — 10.0.22631, matched by 10.0.2
• Windows 11 24H2 and later — 10.0.26100 and above, matched by 10.0.2

This is a prefix match on a string, not a real version comparison, which is why it keeps working for future releases within the same build family: any new Windows 11 feature update is still going to be a 10.0.2xxxx build, and any security update to Windows 10 stays inside 10.0.1xxxx.

Using Filters on an Assignment

Filters are applied where you would normally choose a group. When you create or edit an assignment for an app, a configuration profile, a compliance policy, a Settings Catalog policy, a PowerShell platform script or a Windows update ring, the assignment panel lets you add an Include filter or an Exclude filter in addition to the target group.

1. Assign the policy to a group that contains both Windows 10 and Windows 11 devices — an all-workstations or all-managed-devices group is fine.
2. Under Filter, choose Include and select your Windows 11 filter. The payload now reaches only Windows 11 machines.
3. Repeat for a second assignment if you need the same policy in a different flavour for Windows 10, or use an Exclude filter when the rule is easier to express negatively.
4. Change the filter mode from None to Include or Exclude deliberately — leaving a filter attached but in None mode is a silent no-op that looks correct in the console.

One behaviour worth knowing: filters are evaluated by the service when it computes the assignment for a device, so a device that has just enrolled may take a sync cycle before it receives the filtered payload. If you are troubleshooting, force a sync from Devices > All devices and then check the device's Devices > Monitor > Assignment filters view, which reports which filters matched and which did not, with the reason.

Pitfalls and Edge Cases

• Windows Server builds share the 10.0.x pattern. Server 2019 is 10.0.17763 and Server 2022 is 10.0.20348, so a naive 10.0.2 filter would also match a Server 2022 machine if one were enrolled. In practice servers are rarely Intune-managed for these policies, but always run Preview and confirm the matched device list before you assign anything broad.
• osVersion is the reported OS version string, not a semantic version. A device that has not checked in for a long time reports its last known value, so a freshly upgraded machine can briefly belong to the old filter.
• Filters are not a substitute for a group. The assignment still needs a target group; the filter only narrows it. If the group is empty, the filter has nothing to narrow.
• Nested conditions need brackets. -and and -or do not follow the precedence you might expect from arithmetic, so bracket every clause explicitly.
• Filters apply to managed devices by type. When you create a filter you choose the device scope — managed devices, managed apps, or a platform-specific set. A managed-devices filter cannot be used on an app-scope assignment and vice versa.
• Document the mapping. "Windows 11" as a filter name does not tell a new administrator that it means 10.0.2. Keep the rule in the description.

A Filter Rule Cookbook

Filters are small enough that a handful of patterns cover almost every real deployment. These five are worth adapting rather than reinventing, and each one is short enough to paste straight into the assignment dialog.

# Windows 11 only
(device.osVersion -startsWith "10.0.2")

# Windows 10 only, excluding 21H2 which is out of support
(device.osVersion -startsWith "10.0.1") -and (device.osVersion -notStartsWith "10.0.19")

# Pilot ring: corporate-owned laptops that are not kiosks
(device.deviceOwnership -eq "Corporate") -and (device.enrollmentProfileName -ne "Kiosk-Autopilot")

# Exclude one troublesome hardware model from a driver rollout
(device.model -ne "Latitude 5420")

# All enrolled Windows devices regardless of build
(device.deviceOSType -eq "Windows")

The model and enrollmentProfileName properties are the ones most administrators forget exist. They turn a filter into a surgical tool: instead of building a new Azure AD group for the eleven machines you want to hold back, you exclude them in the rule and keep the group clean. Note the -notStartsWith case: rule operators are case-sensitive in the dialog, and a rule that silently matches nothing is nearly always a wrong-case or wrong-property mistake rather than a broken service.

Common Mistakes With Assignment Filters

• Using a filter where a group is the honest answer. If the set of machines you want is stable and enumerated, a group is easier to audit. Filters earn their keep when the membership changes on its own — a build number, an ownership flag, an enrolment profile.
• Forgetting that a filter narrows, never widens. Every assignment still needs a group. An Include filter cannot pull in a device that the group does not already contain, and an Exclude filter is the only way to subtract from it.
• Assuming Preview matches production. Preview evaluates the rule against currently reported inventory. A device that is offline, newly enrolled or has not run an inventory cycle can be absent from the preview and still match later.
• Layering filters onto a policy that already works. Adding a filter to a currently working assignment is a change to that assignment. Test in a pilot group first, then widen, rather than editing the live assignment and hoping.
• Letting filter sprawl become unmanageable. Twenty near-identical filters with names like "Win11 final v2" are worse than one well-documented filter plus a group. Review filters the same way you review groups, and delete the ones nothing references.

A useful rule of thumb: if you cannot explain the filter's intent from its description field alone, the next administrator will not be able to either. Pair the version rule with the build number it encodes — for example "Windows 11 (10.0.2x)" — and keep the full rule in the description. Screenshot-driven workflows such as silently enabling BitLocker with Intune benefit most from this discipline, because the policy that breaks silently is the one nobody documented.

Where to Go From Here

Version targeting is the highest-value use of filters, but it is not the only one. The same mechanism can separate corporate-owned from personal devices, isolate a pilot ring of early-adopter machines, exclude kiosks and shared devices, or keep a deployment away from a specific hardware model while you investigate a driver problem. Once you have the pattern in your head, most "this policy applies to some of my devices and I cannot work out which" problems resolve into a filter plus a plain group.

If you are deploying the per-version artifacts themselves, the Start Menu layout is the classic example and the XML-based equivalent is covered in Intune Deploy Windows 10 Default Start Menu, with the taskbar equivalent in Intune Deploy Default Taskbar. For the group-based alternative to filters, including the dynamic rules that make up a device-scoped targeting strategy, see Intune Dynamic Device Groups — the two approaches work well together when you use groups for broad scoping and filters for the fine detail.

If you want to read more about Intune Filters here is the Microsoft documentation about it.