If like me you are using the Windows releaseid as a means to locate builds that can no longer received security updates, you may also be in the position that with the change in stance from Microsoft where by they are dropping the yymm releaseid eg 1511, 1607, 1909 etc and moving to a yyqn convention, eg 20H2, 21H1, 21H2 etc, any properties using the releaseid of operating will miss the newer builds or may lead to wrong versions being reported due to stale data.
One possible solution now that the 10.0.3 agents include a new “display version of operating system” inspector is to combine the use of “releaseid” and “display version” so endpoints with the newer “display version” will report its version, otherwise fallback to the “releaseid”. This means you can still have 1 property that covers either build format. This methods seems to be working for me so I thought I’d share in case anyone find it useful for their environment…or maybe there are better ways.
(if(exists properties "display version" of result types of property "operating system") then ((if (exists display version of it) then (display version of it) else (releaseid of it)) of operating system) else (releaseid of operating system))
If run on a 10.0.3 agent where the OS has the newer display version, you would see something like 21H1 where as if run on 10.0.3 where there isn’t a display version and its still the older releasedis, you should get back something like 2004, 1909 etc. If run on a pre 10.0.3 agent, you will only get the releaseid….well, that’s the idea