[German]Windows Server Update Services (WSUS) is having problems detecting the correct build numbers on Windows 10 version 1909. Due to a bug, an incorrect build number is returned.
This information has been already in my inbox for a few days. Blog reader Karl shared the whole thing on Patchmanagement, but put me on CC and writes:
please RT / Share and upvote this so this gets more attention, no matter if you use WSUS or not.
It is not responsible to leave customers down with this strategy. WSUS very apparently is a “do not touch” or least effort zone for MS and they try to promote WuFB “instead”.
Problem: 1903 / 1909 / 2004 / 20H2 and soon 21H1 will report wrong client OS identification strings in WSUS. This makes reporting near impossible with the default reports and GUI views.
What makes me upset is that MSFT has invented a really good achievement with enablement updates and same updates for the core OS but refuse to address a WSUS database logic.
With this in mind I completely understand why there is no separate product category for 1903 and later (1903/1909) and another one for 2004 and later (2004/20H2)
They basically planned this welcomed change without executing for WSUS.
If MS is okay that people need to buy a 3rd party script to fix this (AJtek WAM) and telling at the same time this is “by design” then I suppose their design is not okay.
If Adam Marshall is able to fix this, Microsoft should be the first instance to address this natively.
I have listed 4 seperate uservoices all chiming for a change with each 30+ upvotes which is “a lot” compared in this uservoice area category.
Thanks for your help and upvotes on the linked uservoice items and your time. It helps much use twitter tagging @windowsupdate and express your feedback on this.
This can be found here as a uservoice, but is initially already described in more detail in November 2020 in this Technet thread. Because Windows 10 version 1903 and 1909 use the same code base, they also receive the same updates. The build numbers only differ in one digit – and due to a bug, WSUS does not recognize this. In the specific case, the user writes:
I’m running WSUS (standalone) on Server 2019. All of our pilot machines on Windows 10 1909 are reporting to WSUS with build numbers of 18362 (1903) instead of 18363 (1909).
I understand that 1903/1909 share the same baseline and that the difference between them is basically a feature enablement package, but the different build numbers still need to be properly reported in WSUS. Otherwise, a whole bunch of reporting that I do just goes out the window.
So, WSUS always reports the spring build of a Windows 10 version, even if the fall update is installed. Meanwhile, the whole thing is also confirmed for Windows 10 version 2004 and 20H2. Karl asks that readers upvote this bug on UserVoice and put pressure on Microsoft to fix the whole thing. Or has the whole thing already been fixed? Because Microsoft noted on February 7, 2021 that they want to look at the problem.
Cookies helps to fund this blog: Cookie settings