locked
1909 Machines Reporting to WSUS as Build 18362 Instead of 18363 RRS feed

  • General discussion

  • 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.

    Wednesday, November 13, 2019 3:31 PM

All replies

  • Same issue here.  If the Windows Update client is truly pulling this info from Windows and sending it up to the WSUS server then I have no idea why it would be reporting 10.0.18362 instead of the correct 10.0.18363.

    It's bad enough that WSUS cannot correctly display Windows 2016/2019 vs Windows 10 under the Operating System column but you think they could at least show the correct Version number.

    Wednesday, November 13, 2019 7:26 PM
  • I have the exact same problem.

    This gives me a problem of distinguishing which of my clients are on 1909 and which ones are on 1903.

    Thursday, November 14, 2019 8:51 AM
  • It does at least look like it's Windows fault, since 1909's update agent and a few base system devices all report a build number of 18362.

    https://imgur.com/a/46lsCwd

    MSFT folks, any comment/update? This can't just not be fixed, is the appropriate Windows dev team being made aware?

    • Edited by ac513 Monday, November 18, 2019 2:35 AM More details
    Monday, November 18, 2019 2:29 AM
  • I have this problem also. I think that Microsoft is fully overwhelmed by internal problems.
    Friday, November 22, 2019 1:25 PM
  • I have the same problem. Any news?
    Wednesday, November 27, 2019 2:20 PM
  • Per the other thread on this, the Windows Update agent in Windows itself is still build 18362. So it's a Windows problem with it reporting an inaccurate build number due to this, not a WSUS problem it seems.

    https://social.technet.microsoft.com/Forums/en-US/a78aeebd-5a2c-46e7-92b2-57fddedbaa3e/windows-10-1909-not-correct-number-version-in-wsus?forum=winserverwsus

    I don't know if there's much of a "fix" other than Microsoft fixing it in Windows. The issue is present in Server 1909 too... It reports as build 18362.

    • Edited by ac513 Wednesday, November 27, 2019 2:37 PM
    Wednesday, November 27, 2019 2:26 PM
  • Also evident if you use testsigning ("bcdedit -set TESTSIGNING on"). The text in the lower right corner of the screen ("Test Mode, Windows 10 Pro, Build 18362.19h1_release.190318-1202") will report build number as 18362. "winver" correctly reports 18363.

    Friday, December 13, 2019 8:46 AM
  • Seeing the same on our WSUS. Will there be a fix for this?
    Wednesday, January 22, 2020 9:29 AM
  • We've got exactly the same problem.

    This makes it very difficult for us to to find out if the "enablement package" has been successfully deployed and installed on the WSUS Clients!

    A "wontfix" is completely unacceptable!

    Friday, January 31, 2020 10:23 AM
  • Hi all,

    please submit a feedback item for this issue on the Windows Server uservoice site:
    https://windowsserver.uservoice.com/forums/295047-general-feedback

    This will create an item on our end which will be reviewed by the people owning WSUS & Windows Update.

    If you are an enterprise customer, please also open a support case to start the design change request process.

    The more people/companies report this, the higher chance for a change.

    This issue is considered by design (not saying it is a good one), as in the WSUS console the version of WUAUENG.dll from the client machine is displayed and due to the nature of how servicing is done on 1903 and 1909 versions of Windows 10, this file has the same version on both.

    Let me know if you have any questions.

    Thanks,
    Andrei


    We could change the world, if God would give us the source code.

    Thursday, February 6, 2020 6:05 AM
  • considering the servicing time of 18-30 months, wouldn't it be easier to rely on an internal process rather than uservoice? 

    On-prem solution exist. MSFT strategy is called out Hybrid. I do not see why admins should spent time in uservoice for design issues that are present due to a very welcome servicing change as with 1903, 1909.

    **At the moment we hope this can be continued with 2004* / 2012*.

    *unofficial versions / **as mentioned by Rich Terminal-er 


    MCP Windows Server, MCSA Windows 2008 / 2012, MCITP Hyper-V SCCM


    Monday, March 2, 2020 12:29 PM
  • I am glad to see this thread however it does not resolve the issue at hand.

    In the corporate world we just got around to upgrading some of our production machines from 1809 (set to end support in May) so we upgraded to 1909. Everything went well on the Win 10 Pro machines and are running 18363.720.

    I went to check on the WSUS (Server 2016) and the status of the reporting clients. I was confused to see the 1909 clients reporting as 18362.628 (aka 1903). As I searched I found this thread concerning this issue. However it seems that the issue is in the hands of MS.

    Therefore I add my plea to this thread that MS issue an update to address this concern.

    Thursday, April 9, 2020 5:15 AM