[English]Der Windows Server Update Services (WSUS) hat Probleme, die korrekten Build-Nummern bei Windows 10 Version 1909 zu erkennen. Wegen eines Bugs wird eine falsche Build-Nummer zurückgeliefert.
Die Information steckt bereits einige Tage in meinem Posteingang. Blog-Leser Karl hat das Ganze auf Patchmanagement geteilt, mich aber auf CC gesetzt und schreibt:
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.
Changes to improve security for Windows devices scanning WSUS – Microsoft Tech Community
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.
Das Ganze ist hier als Uservoice zu finden, wird aber initial bereits im November 2020 in diesem Technet-Thread genauer beschrieben. Weil Windows 10 Version 1903 und 1909 die gleiche Codebasis verwenden, erhalten diese auch die gleichen Updates. Die Buildnummern unterscheiden sich nur in einer Ziffer – und auf Grund eines Bugs erkennt der WSUS dies nicht. Im konkreten Fall schreibt der Nutzer:
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.
Der WSUS meldet also immer die Frühjahrsbuild einer Windows 10-Version, auch wenn das Herbst-Update installiert ist. Inzwischen wird das Ganze auch für Windows 10 Version 2004 und 20H2 bestätigt. Karl bittet, dass die Leser diesen Bug auf UserVoice hochvoten und Druck auf Microsoft ausüben, damit das Ganze behoben wird. Oder ist das Ganze schon korrigiert? Denn Microsoft hat am 7. Februar 2021 angemerkt, dass man das Problem ansehen will.
Moin,
kann ich so nicht bestätigen…
Hab knapp 900 Systeme im WSUS, gerade einige Stichproben gemacht und bei mir werden die Builds richtig übergeben und angezeigt. Sowohl am Client selbst, als auch in der WSUS Konsole…
Server: 2016 LTSC WSUS, Updatestand 02/2021
Clients: Windows 10 Enterprise 1909
Die in WSUS angegebene „Version“ meldet (schon immer) die Version dieser Datei
c:\Windows\System32\wuauclt.exe und nicht die des Betriebssystems.
Daher passt diese auch meist nicht ganz genau auf den Patchlevel!
Grundsätzlich ist die Kritik aber richtig! Ich würde mir auch zusätzlich eine ARM64 und 32bit Kategorie wünschen, denn denn das nervt auch schon seit vielen Jahren (früher mit IA64)
PS: das ganze ist nicht korrigiert. (Einfache Lösung: MS könnte einfach die Versionsnummer dieser Datei an die OS Version anpassen)
„Die in WSUS angegebene „Version“ meldet (schon immer) die Version dieser Datei c:\Windows\System32\wuauclt.exe und nicht die des Betriebssystems.“
Jou, kein Bug. Siehe 2016:
https://social.technet.microsoft.com/Forums/ie/en-US/b9682551-0892-4992-bd18-b4ea0ba3c155/windows-10-os-buildversion-is-not-changing-in-wsus-since-10014393187?forum=winserverwsus
Es war doch schon immer so daß im WSUS nicht die Build-Nummer des Clients angezeigt wurde sondern die seiner Update-Komponente. Früher war die oft zufällig identisch. Aber auch früher gab es Fälle wo nach einem Monatsupdate die Buildnummer per „winver“ am Client in der letzten Zahl höher war als das was das WU-Modul an den WSUS meldete und auf dem Stand des Vormonats verblieb. Eben wohl wenn in dem Monat nichts am Windows-Update aktualisiert wurde.
Da sich 1903 und 1909 die gleiche Updatekomponente teilen, und genauso wohl auch 2004, 20H2 und dann vielleicht auch 21H1 werden auch die im WSUS die gleiche Version anzeigen. Also 1903/1909 werden beide als 10.0.18362.x angezeigt und 2004/20H2 als 10.0.19041.x (statt ..19042.. für 20H2 und wohl ..19043.. für 21H1). Natürlich ist das blöd und wäre anders besser, ist aber definitiv nicht neu sondern leider schon immer so.
Ja, leider ein alter Hut. Ich habe mich schon seit erscheinen von 1909 mit der falschen „major“ Version abgefunden. Was aber für mich viel schlimmer ist, sind die falschen „minor“ Versionen. Es wird trotz installiertem Patch von Februar am WSUS 18362.1316 anstatt 18362.1377 angezeigt.
Man kann also sagen „rienne va plus“ …. nix geht mehr.
Bei uns da gleiche. Seit 1909 kann man den WSUS nicht mehr nutzen, um die OS Version zu sehen. Das 1903/1909 Release ist nicht unterscheidbar und bei der minor version zeigt ein Teil der Clients die richtig Version an und ein Teil auch wieder nicht.
Vorher hatte es meistens gestimmt – wie schon die Vorredner geschrieben haben – eher zufällig, da die Versionsnummer der Windows Update DLL angezeigt wird.
Naja, man kann sich natürlich auch selbst helfen, wenn man es unbedingt haben möchte. Dieses Script https://www.wsus.de/windows-editionen-anzeigen/ erweitern/abändern, schon wird angezeigt um welchen Version (1903 oder 1909) es sich handelt.
Natürlich kann man das Script auch für den WSUS auf W2012R2 verwenden, dann *erkennt* der dumme WSUS auch diese Clients richtig. :)
Dieses Script hilft leider bei der Problemstellung überhaupt nicht. Mit diesem Script wird nur der anfängliche Fehler mit Windows 10 und Server 2016 behoben, dass nicht die Editionen richtig angezeigt wurden. Sprich alles war Windows 10, man konnte aber nicht sehen, ob es Pro oder Enterprise war. Dieses Script wird auch nicht mehr benötigt, weil dieses mittlerweile behoben wurde.
Hat aber nichts mit der Kernaussage dieses Problems zu tun. WSUS kann auch nichts ändern, was nicht vom Client richtig gemeldet wird. Und hier liegt es an der Version des Update-Clients und der Tatsache, dass die OS-Version nicht richtig verarbeitet, bzw. angezeigt wird. Es müsste einfach die Möglichkeit geben die OS-Version, die in der Datenbank vorhanden ist, anzeigen zu lassen.
Kann die Aufregung nicht nachvollziehen, welche Windows Version man auf den Geräten hat kann man auch an anderer Stelle auslesen und auswerten, dafür muss ich mich nicht auf die, anscheinend fehlerhafte, Build Nummer nach einem Update versteifen.
Ich kann verstehen wenn sich jemand ärgert, weil seine Auswertung aufgrund eines solchen Problems nicht mehr richtig funktioniert. Ich würde dann aber einfach nach anderen Möglichkeiten gucken meine Auswertung zu bekommen, inkl. Windows Version. Irgendwelche 3. Party Scripte über mein WSUS laufen zu lassen die ein Problem beheben, von dem MS sagt das es kein Problem ist, sehe ich Kritisch.
Für mich spielt das Problem weder theoretisch noch praktisch eine Rolle.
Ich habe keine Frühjahrs- und Herbstversionen des selben Jahres in der Systemlandschaft. Ich installiere 1x im Jahr die Herbstversionen und lasse immer die Frühjahrsversionen aus. Aktuell also noch alles auf 1909, zum Mai hin kommt dann überall 20H2 drauf.
Und Notfalls kommt die Auswertung aus der Inventarsoftware und nicht aus dem WSUS.
nichts neues.
der wsus auf windows server 2012 r2 erkannte nicht mal den Windows Server 2016 als Server sondern als Windows 10.
Solange das Ding richtig Patched ist mir das egal, da WSUS sowieso nicht das Inventarisierungstool der Firma ist. Solange das Ding Windows 10, von Windows Server 2019 und Windows Server 2016 bzw. Windows Server 2012 R2 unterscheiden kann und auch so anzeigen kann, passt hier alles.
Und was AJTEK WAM betrifft, wofür da Geld einwerfen? Die meisten dieser Optimierungen kann man auch selbst machen bzw. gibt es unter anderen Namen auch gratis zum laden.
Keine Ahnung was da wieder an der DB modizifiert wird, aber spätestens wenn der Client wieder zum WSUS reportet, müsste er ja wieder die falsche Version zurück reporten.
Der WSUS patcht nichts und niemanden, der stellt nur zur Verfügung. Die Clients, der Windows Update Agent hat die Intelligenz an Board um das richtige anzufordern, downzuloaden und zu installieren. Das Wissen ist bei der Fehlersuche hilfreich.
Das Doofe an der Sache ist: auf dem WSUS-Server kann man über Powershell die Betriebsystemversion aus dem Rechner-Objekt auslesen (Property: OSInfo).
d. h.: Die Daten sind da!
Nicht vollständig.
Bsp. Rechner mit ver: Microsoft Windows [Version 10.0.19045.3448]
Ausgelesene Daten vom Wsus:
($client.OSInfo).Version
Major : 10
Minor : 0
Build : 19045
ServicePackMajor : 0
ServicePackMinor : 0
Es fehlen die wichtigen ServicePack Versionsinfos.