Intune filters by OS version: how to control a policy pilot

A policy or application in Microsoft Intune often needs to reach only devices that already run a particular operating-system version. Creating another group for every threshold quickly makes targeting difficult to understand. In Intune service release 2608, during the week of 25 August 2026, Microsoft marked the operatingSystemVersion assignment-filter property as generally available.

The change does not automatically modify existing assignments. It gives administrators another way to include or exclude devices by an OS version or version range within a group that has already been selected. Its practical value is more precise pilot deployment, not blindly accelerating a rollout.

What changed in August 2026

Current Intune documentation states that operatingSystemVersion is generally available for managed devices and managed apps. For managed devices, it can be used with Android, iOS/iPadOS, macOS and Windows. The rule supports -eq, -ne, -gt, -ge, -lt and -le, so a filter does not have to look for one exact value.

Microsoft also says that existing assignments continue to work without changes. Availability alone is therefore not a reason to rewrite stable policies. First identify which rollout is currently limited by imprecise targeting and where the OS version genuinely determines compatibility.

A filter is not a replacement for a group

A group defines the base audience, such as all company notebooks or the users in one department. An assignment filter is evaluated against a device or app during assignment and narrows that audience. In Include mode, only matching objects receive the policy; in Exclude mode, matching objects are removed from the assignment.

Microsoft recommends filters for Intune policies and apps based on device properties. Dynamic groups remain appropriate when the same membership is needed outside Intune, for example for Conditional Access, licensing or Windows Autopilot profile assignment. The two methods can complement each other.

A practical controlled-pilot example

Consider a policy assigned to a broad group of corporate Windows devices that should initially apply only to newer builds. Microsoft provides this sample rule in its reference:

(device.operatingSystemVersion -gt 10.0.22000.1000)

The value is a documentation example, not a recommended threshold for every organization. Replace it with a version that matches the supported OS, tested application and actual inventory. A safe process is:

1. collect OS versions and verify that the Intune data is current;
2. create a clearly named filter with its purpose and owner;
3. use Preview devices and inspect expected and unexpected matches;
4. assign the policy to a small pilot group together with Include mode;
5. after check-in, review policy status, errors and devices outside the filter;
6. expand the base group only after evaluating the pilot and preparing a rollback step.

The difference between two version properties

The reference lists operatingSystemVersion and osVersion separately. The first uses comparison operators for versions; the second is a string property with operators such as exact match, startsWith or contains. Microsoft now marks osVersion as deprecated: new assignment filters cannot use it, while existing filters with that property continue to work. Mixing up the name or operator can change the resulting device set. Copy a rule from the final editor, not from an unchecked note.

A filter is evaluated when a device enrolls, checks in or a policy is otherwise evaluated. It is therefore unsafe to expect a console change to reach a device immediately when that device has been offline for a long time. During an incident or urgent rollout, track the last contact time and the deployment result.

Boundaries you need to know

• A managed device must be enrolled in Intune; a filter does not replace enrollment.
• A tenant can have up to 200 assignment filters and one filter rule is limited to 3,072 characters.
• A filter can be reused in several assignments, so editing it can affect several policies at once.
• Include and Exclude do not describe the same result; verify the filter direction before saving.
• Preview devices checks the selection, not whether an app or policy will succeed on every device.
• Supported workloads and properties differ between managed devices and managed apps.

Checklist before production deployment

• record why the OS version affects compatibility or risk;
• compare inventory with versions supported by the application vendor;
• separate pilot and production waves and define a stop condition;
• review Associated Assignments to identify every consumer of the filter;
• monitor check-in, installation failures and the number of devices outside the expected version;
• after rollout, decide whether the filter remains an operating rule or was only a temporary tool.

When specialist assistance makes sense

A filter cannot fix inconsistent inventory, unclear groups or a missing test process. As part of Microsoft cloud service management, Yenwa can map groups, Intune policies, device versions and dependencies. Through IT outsourcing, we can prepare the pilot, checkpoints and rollback process so that precise targeting does not become another unowned rule.

First confirm that the filter selects the right devices. Only then measure whether deployment actually succeeded on them.