locked
Where does WSUS store the information on what OS an individual machine is running? RRS feed

  • Question

  • I'm having an issue that I wasn't able to resolve in another thread about WSUS not recognizing what operating system a Server 2012 machine is running ... it never says that any OS updates are applicable to it, even though it does for two identical servers.  So I'm wondering ... how exactly does WSUS know and store the OS information for an individual machine?  Specifically, is this a backend issue, with machine properties stored in the SQL server?  Is there any way to refresh the OS data?

    Friday, July 21, 2017 7:35 PM

All replies

  • I'm having an issue that I wasn't able to resolve in another thread about WSUS not recognizing what operating system a Server 2012 machine is running ... it never says that any OS updates are applicable to it, even though it does for two identical servers.  So I'm wondering ... how exactly does WSUS know and store the OS information for an individual machine?  Specifically, is this a backend issue, with machine properties stored in the SQL server?  Is there any way to refresh the OS data?

    Hi.
    WUAgent doesn't really work like that. (the data within SQL in WSUS essentially records whatever the WUAgent reports up to it)
    WUAgent calls in to WSUS (or WU/MU) and basically says "my OS is *this*, please give me the catalog metadata for *this* OS", and then the WUAgent examines the received catalog and checks the metadata within the catalog and determines applicability to *itself*.
    WUAgent will also examine what Approvals exist at your WSUS (or WU/MU) and if updates are detected as Applicable+Required it will begin downloading the update payload and (according to your implementation) will begin installation or schedule the installation of the updates.
    The WUAgent will (usually within 30mins) send a scan-results report back to WSUS/WU/MU with what *it* detected (basically the applicability results and results of installation if any).

    So, the symptom you describe is really being controlled by the WUAgent on the 'client', not by the WSUS.
    One reason why this could occur, is if the 'client' computer is missing an important pre-requisite update for which it can't get an approval (eg KB2919355). At certain points-in-time, MSFT will 'draw a line' about servicing out-of-date systems and you won't get new updates if you don't have that certain baseline.

    e.g. KB2919355 states:
    Important 
    All future security and non-security updates for Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2 require this update to be installed. We recommend that you install this update on your Windows RT 8.1-based, Windows 8.1-based, or Windows Server 2012 R2-based computer in order to receive continued future updates.

    There are other possible causes for the symptoms you describe, but this one (not at minimum service baseline) is a common one.

    NB: your other thread, shows that you did a select-string for the keyword 'FATAL'. Unfortunately, windowsupdate.log, and logfiles in general for Windows, often require the full context of surrounding events/rows to be useful. The example you provided in the other thread is missing that context, making it difficult to diagnose. If you want to upload the entire logfile to OneDrive and share that link here (rather than posting the log here), that helps us help you :)


    Don [doesn't work for MSFT, and they're probably glad about that ;]



    • Edited by DonPick Saturday, July 22, 2017 7:02 AM
    Saturday, July 22, 2017 7:00 AM
  • Thanks for the informative reply.  I've got it straightened out now -- I was POSITIVE that the problem machine was Server 2012 R2 like the others, but it turned out that it was really 2012 Datacenter.  It had always downloaded the same updates as the other two machines, but then seemingly stopped.  I checked the products section of WSUS and saw that only Server 2012 R2 was checked.  I checked plain Server 2012 and it began downloading updates again.
    • Proposed as answer by DonPick Tuesday, July 25, 2017 9:19 PM
    Monday, July 24, 2017 11:46 PM
  • I've got it straightened out now -- I was POSITIVE that the problem machine was Server 2012 R2 like the others, but it turned out that it was really 2012 

    Oh. That would do it :)

    I have those days myself... (I could have sworn that it was abcxyz...)  ;)


    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Tuesday, July 25, 2017 9:21 PM