operatingSystemVersion assignment-filter property is now generally available, giving endpoint administrators a direct way to scope an app or policy assignment to an operating-system version or build range. For Windows management, that turns a familiar deployment prerequisite—“this device must be at least this build”—into a filterable assignment condition rather than a manually maintained group rule.
The immediate story is not that every Windows rollout should acquire another filter. It is that organizations using the older osVersion property now have a clear replacement path. osVersion is deprecated: existing filters continue to work, but new assignment filters using that older property can no longer be created. That makes operatingSystemVersion the appropriate choice for new design work and a reason to plan, rather than rush, a controlled migration of legacy filters.
What operatingSystemVersion can target
The new property lets administrators create a rule around a specified OS version or build range. It supports these comparison operators:
-eq— equal to-ne— not equal to-gt— greater than-ge— greater than or equal to-lt— less than-le— less than or equal to
For managed devices, the property applies to Android, iOS/iPadOS, macOS, and Windows. For managed apps, it applies to Android, iOS/iPadOS, and Windows.
That platform coverage matters, but it should not obscure the clearest Windows use case. A broad assignment can target the intended population, while a filter decides whether an individual Windows endpoint satisfies the OS baseline needed for the app, configuration, or policy. Instead of constructing a separate group for every stage of a servicing rollout, teams can apply a condition based on the device’s reported version.
A Windows administrator might use the filter to:
- Make a new configuration available only after devices reach a defined Windows version or build baseline.
- Hold back an application that has a known dependency on a newer Windows release.
- Apply a transitional policy to devices below a selected version boundary.
- Keep a rollout group broad while filtering eligibility for devices that have completed an update phase.
These are assignment decisions, not health determinations. A qualifying version does not prove that a machine has sufficient hardware, a compatible line-of-business application stack, a stable network connection, or a successful policy-processing history. It simply makes OS level a usable targeting signal.
Why the osVersion migration deserves care
Deprecation does not mean an existing osVersion filter has stopped working. Microsoft says existing assignment filters using it continue to function. The important operational change is that administrators cannot create new filters with osVersion, so leaving old logic undocumented can create a longer-term maintenance problem.
The safest response is an inventory, not a mass edit. Identify every legacy filter, the assignments that use it, the device populations affected, and the business condition it was meant to enforce. A filter protecting a broad security configuration deserves more scrutiny than one used for a small pilot application.
Then rebuild the intent using operatingSystemVersion in a controlled test assignment. The task is not merely to substitute a property name. Teams should confirm that the selected operator and entered boundary still express the desired outcome. For example, a condition intended to admit a minimum supported build is different from one intended to isolate exactly one build family. A rule using -ge may be appropriate for the first case; an exact-match rule might be required for the second.
That distinction becomes more important as servicing plans evolve. A filter that once represented a temporary pilot boundary can become an accidental permanent eligibility gate if nobody revisits its purpose. Maintaining a short description of the deployment requirement alongside each filter helps prevent version logic from becoming opaque months later.
How filter evaluation affects rollout planning
Assignment filters are evaluated at enrollment and device check-in, and they can also be evaluated at other times, including compliance checks. The resulting state is not necessarily visible immediately: filter evaluation results can take up to 30 minutes to appear in Intune.
For administrators, the practical consequence is that a filter test should not be judged solely by an immediate change in the console. A device that has just enrolled, checked in, updated, or crossed a version threshold may need time before its recorded filter result reflects that new state. Treat the evaluation result and its timestamp as part of the evidence for whether a rule is working as expected.
There is another important distinction between assignment eligibility and endpoint state: a changed filter result does not automatically remove an app that was already installed. If an application must be removed when a device falls outside an OS range, administrators should not assume that changing filter eligibility alone performs that removal. The assignment and removal design need to be tested as a whole.
This matters especially when using version filters as a temporary gate during an update rollout. A device can move into or out of the matching range over time. The filter can influence whether the current assignment applies, but it should not be treated as a complete software-lifecycle mechanism without verifying the deployment behavior required by the organization.
Test boundaries, not just the happy path
The Filter evaluation report provides a practical way to test a new or migrated rule before it is attached to a consequential assignment. A useful test set contains at least three devices:
- A device expected to match the rule.
- A device expected not to match.
- A device at the exact version or build boundary.
For each device, inspect the evaluation timestamp and the reported Match or No match result. The boundary case is essential for rules using -gt, -ge, -lt, and -le; it exposes an incorrect operator or threshold more reliably than testing only devices well above or below the intended line.
Testing also needs to account for overlapping assignments. When assignments create competing filter paths, an exclude filter takes precedence over an assignment with no filter and over an include filter. Filters in the same mode use OR logic: multiple include filters are evaluated as alternatives, and multiple exclude filters are likewise evaluated as alternatives.
That precedence can be helpful when it is deliberate. For example, a broad Windows assignment can be paired with an exclusion for a build range that requires additional validation. It can also produce surprising outcomes when separate teams attach filters to overlapping assignments without a shared view of the targeting design.
Before rollout, administrators should therefore review assignments as a set, not as isolated rules. Ask which broad group supplies eligibility, which filters include or exclude devices, and whether a device can qualify through more than one path. The Filter evaluation report is a validation tool, but clear ownership of assignment design is what prevents precedence rules from becoming an incident response exercise.
Windows deployment patterns that benefit most
Version-aware filtering is most valuable when an OS baseline is a real technical requirement. If an application, setting, or management change works across the entire intended Windows estate, adding a version condition may only introduce complexity. If it depends on a particular release or build range, however, the filter can make the requirement visible and enforceable.
A staged Windows configuration rollout is one example. Rather than continually moving devices among manually curated groups as they update, a team can use a broad target and a filter based on the required baseline. Devices that have reached the threshold can receive the assignment; devices outside the range can remain on the existing process while update work continues.
Another use is protecting a deployment from older devices during a transition. An exclusion can prevent a known-incompatible build range from receiving a change while the organization assesses a workaround, update path, or retirement schedule. This is not a substitute for servicing governance, but it can make the temporary exception more precise than an ad hoc list of device names.
The central caution is to use values and operators that have been verified against actual enrolled Windows devices. Labels such as “current,” “supported,” or “ready” are business descriptions, not filter values. The operational rule must be expressed as a specific version or build condition and tested against the estate that will receive it.
Managed-app support has a specific mobile caveat
operatingSystemVersion is also available in managed-app scenarios, but administrators should not assume that every app-assignment model behaves like a Windows device-targeting deployment. The platform lists are useful boundaries: managed-device coverage includes Android, iOS/iPadOS, macOS, and Windows, while managed-app coverage includes Android, iOS/iPadOS, and Windows.
There is a current known issue for Available apps on Android, Android (AOSP), and iOS: operatingSystemVersion evaluations are currently inconclusive. Microsoft has not provided an ETA for a fix. This limitation is specific to those available-app scenarios and should not be generalized to the Windows device-targeting use case.
The broader lesson is to validate the assignment type, platform, and management model actually in use. A version filter can express an eligibility condition, but it does not guarantee that all app delivery, app-protection, and device-management scenarios share identical evaluation or installation behavior.
A controlled path to adoption
A practical implementation plan begins with one assignment that has an unambiguous OS requirement and a limited Windows target population. Build the operatingSystemVersion rule, test matching, nonmatching, and exact-boundary devices, and use the evaluation result, timestamp, and assignment design to investigate unexpected outcomes.
Next, migrate legacy osVersion filters in priority order. Start with filters tied to security-sensitive policies, large application deployments, or configurations that would be difficult to reverse. Keep the old filter’s documented intent alongside the new rule, then compare the expected eligible populations before altering production assignments.
Finally, review filters as part of change control rather than as one-off console settings. Record the version boundary, the operator, whether the filter is include or exclude, the assignments it affects, and the condition that will retire it. That small amount of discipline helps ensure Intune’s more granular targeting reduces group sprawl instead of creating a new layer of hidden deployment logic.
operatingSystemVersion does not replace update rings, compliance policy, endpoint monitoring, or application compatibility testing. It gives administrators a more exact way to translate a verified OS prerequisite into assignment targeting. Used with boundary testing and careful migration from osVersion, it can make Windows deployment eligibility clearer, safer, and easier to maintain.