Repository navigation
Microsoft/OSInfo: Support minimum version assertion (>= comparison) #1521
Description
Summary of the new feature / enhancement
The Microsoft/OSInfo resource currently performs exact string matching on the version property. This means asserting version: "10.0.22621" fails on a machine running 10.0.26614 — even though the machine exceeds the minimum requirement.
For configuration authors using Microsoft/OSInfo in assertions (e.g., "this config requires Windows 11 22H2 or later"), there's no way to express a minimum version constraint.
Observed behavior
dsc resource test -r Microsoft/OSInfo --input '{"family": "Windows", "version": "10.0.22621"}'
On a machine running 10.0.26614:
inDesiredState: false
differingProperties:
- versionExpected behavior
A way to specify that version should be treated as a minimum (>=) rather than an exact match. For example:
- name: assert_min_os
type: Microsoft/OSInfo
properties:
family: Windows
minVersion: "10.0.22621"Or alternatively, support a comparison operator on the version property:
properties:
version:
minimum: "10.0.22621"Use case
WinGet Configuration files that need to assert a minimum OS version before applying resources (e.g., Dev Drive requires 22H2+, certain Windows Settings resources require specific builds). The Microsoft.Windows.Developer/OsVersion resource in WinGet DSC v2 supported MinVersion for this purpose — the native Microsoft/OSInfo resource would be the faster v3 equivalent if it supported minimum version comparison.
Additional context
Microsoft/OSInfocapabilities areget+export(read-only, noset) — ideal for assertions- It's a native Rust binary so it's extremely fast compared to PowerShell-based alternatives
- Semantic version comparison (or at minimum numeric dotted-version comparison) would make this resource the canonical way to gate configs by OS version
- Related: Assertion section in config doc #1421 (assertion section in config docs)
Activity
Add Improvements section and mark elevation workaround resolved
michaeltlombardi commentedon May 8, 2026
I'm not sure how easy this will actually be across operating systems, particularly Linux distributions - we expose the
versionfield as a simplestring, but the underlying library uses an enum that distinguishes between variants:I looked into the source code and found that the Windows implementation does always seem to return a semantic version, but that's not true on Linux (where releases can be numbered, date based, rolling, and so on) or macOS (where versions may be semantic or define only 2 version segments).
To provide this functionality, I think we would need to do something like:
Add a write-only field called
semverRequirementthat takes a DSC semantic version requirement, like^1.2.3or>=1.2.3, <1.5. This field is only used in thetestoperation.Implement the
testoperation for the resource. Currently it uses synthetic testing through the DSC engine. It would be fairly low-effort to implement because it's an equivalency check for defined fields plus the version range check.When a user defines
semverRequirement, thetestoperation indicates that the resource is in the desired state only when:Otherwise, the
testresult indicates that the resource isn't in the desired state because theversionfield is invalid for the instance.An additional wrinkle here is that the semantic version requirement DSC uses is defined in the
dsc-libcrate which depends on thedsc-lib-osinfocrate. This might require us to move the semantic version wrappers fromdsc-libtodsc-lib-semverto avoid a cyclical dependency.theJasonHelmick commentedon May 14, 2026
Linked issue to resolve: #558