Console Displaying Build/Version Mismatch for Windows 10

[DanTheEndpointMan]

Has anyone else noticed that clients in their console display a different OS build numbers compared to their version numbers? I have a lot of clients that are on Windows 10 22H2 that BigFix recognizes as being build number 19045 (22H2), but still lists the version number as 2009 which is for 20H2.

This isn’t much of an issue as it’s still mostly appearing correctly, but I was curious if this mismatch was something others had noticed or was caused by something I don’t have setup to sync. The clients have all had plenty of time to communicate with our relays and update their client info so I don’t think it’ll fix itself with time.

My current theory is that this is potentially caused by the clients being updated via Enablement Package from 20H2, but that’s just a theory.

[JasonWalker]

Also check the BigFix Client versions installed on these endpoints. The “Friendly Names” of the OS version (2009, 22H2, etc.) are just arbitrary names and have changed over time, so we’ve had to update BESClient itself to recognize and produce those names. An older installed client would not recognize a newer friendly name.

[SLB]

What can also get confusing if the older ReleaseID still exists on a build that was upgraded from build 2009 or earlier to a newer version. As @JasonWalker highlights, the client version needs to be updated so it can use the recognise the DisplayVersion instead of the ReleaseId. I think it may have needed 10.0.3 or later if memory service me right.

[SLB]

You can also replicate the anomiliy using the standalone FixletDebugger

[vtripodi]

The Agent is supported on Windows 10 22H2 starting from Platform 10.0.3 (you can check here which Agent version supports a specific Windows version).
As Jason suggested, you may be using an older client, as a result the console shows the wrong version.

[DanTheEndpointMan]

Thank you all for the information. I’ll do an agent update in our environment in the next few weeks and see if that solves the mismatch.

[atlauren]

Also, the releaseid is different from the marketing nomenclature.

via 10.0.7 Fixlet Debugger, “local Fixlet Debugger”

q: (version of it, releaseid of it, name of it, it) of operating system
A: 10.0.19045.2728, 2009, Win10, Win10 10.0.19045.2728 (22H2)
T: 0.818 ms

q: version of client
A: 10.0.7.52
T: 0.665 ms

via 10.0.7 Fixlet Debugger, “local client”:

q: (version of it, releaseid of it, name of it, it) of operating system
A: 10.0.19045.2728, 2009, Win10, Win10 10.0.19045.2728 (22H2)
T: 0.101 ms

q: version of client
A: 10.0.9.21
T: 0.010 ms

[atlauren]

We have an “OS - All” global property for this:

if (((windows of it) and (version of it > pad of ("10" as version)) and (build number of it != 10240)) of operating system) then ((name of it & " (" & releaseid of it & ")" & (if (architecture of it = "i386") then " 32-bit" else "") ) of operating system) else if (mac of operating system) then ((name of it & " " & version of it as string) of operating system) else if ((((windows of it) and (version of it < pad of ("10" as version))) of operating system)) then ((name of it & (if (architecture of it = "i386") then " 32-bit" else "") ) of operating system) else if (unix of operating system) then (name of operating system) else if (((windows of it) and (build number of it = 10240)) of operating system) then ((name of it & " (1507 LTSB)" & (if (architecture of it = "i386") then " 32-bit" else "")) of operating system) else "n/a"

[atlauren]

TIL display version of operating system, supported on client 10.0.3 and later, and Win10 20H2 and later.
https://developer.bigfix.com/relevance/reference/operating-system.html#display-version-of-operating-system-string

I think I’ll be updating our “OS - All” property to use this.

q: (version of it, display version of it, releaseid of it, name of it, it) of operating system
A: 10.0.19045.2728, 22H2, 2009, Win10, Win10 10.0.19045.2728 (22H2)
T: 0.022 ms

q: version of client
A: 10.0.9.21
T: 0.013 ms

[DanTheEndpointMan]

Finally had the chance to get the BigFix agent updated to a more recent version and it fixed the mismatch immediately.