none
SCCM Updates are installed but Windows update status wrong

    Question

  • Hello everyone,

    I've a strange problem with SCCM updates.

    Updates are deployed and installed on machines, but when I open "Windows Update" and look at: "Updates were installed" the date is wrong.

    My problem is that PRTG base it's warning on Windows Updates...

    So why Is WIndows not seeing that updates were installed?

    Thanks for help

    Wednesday, April 27, 2016 8:17 PM

Answers

All replies

  • As far as I can tell, that date is pulled from the following registry key and property:

    HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\Results\Install

    LastSuccessTime

    I checked a machine that has been managed with ConfigMgr for its entire life (never installed updates directly via Windows Update) and that registry property doesn't exist. I don't believe it's getting set/updated when software updates are managed/installed by ConfigMgr.

    So that might mean that the machine you're looking at has had updates installed through Windows Update at some point in the past and that's how the registry property exists in the first place. But now that ConfigMgr is installing the updates, that property isn't getting updated.

    Open up a PowerShell window and run Get-Hotfix. It should list all of the updates that have been installed by ConfigMgr and you can verify when they were installed by the InstalledOn column.




    Wednesday, April 27, 2016 9:06 PM
  • Hello,

    Yes the machine has the updates installed (I can see them under "View Update History").

    But on another environment, where I pulled out Updates with SCCM the "Updates were installed" showed the correct date.

    And I need the date, because PRTG check it, and the company where I'm at the moment use PRTG to monitor servers...

    Just do add my GPO Settings for Updates:
    "No auto-restart with logged on users for scheduled automatic updates installations" : ENABLED
    "Allow signed updates from an intranet Microsoft update service location": ENABLED

    I've not set "Configure Automatic Updates".

    • Edited by TDA1990 Thursday, April 28, 2016 5:33 AM GPO
    Thursday, April 28, 2016 5:11 AM
  • So why Is WIndows not seeing that updates were installed?

    To see if the updates deployed by Configmgr ,you can look at programs and features--view installed updates, sort by date OR follow the Configmgr logs (wuahandler.log, updatesdeployment.log and other WU* logs) .

    are you checking the status in the Configmgr reports to check the compliance status ? or directly on the box ? Please provide more information ,how are you checking the status.

    If you are managing the clients for software update using Configmgr,you should never look at the windows update on the machine locally. Always look through Configmgr reports for compliance status and client logs help you troubleshooting.

    Take a look at this post http://blog.configmgrftw.com/software-updates-management-and-group-policy-for-configmgr-cont/

    for Software updates troubleshooting http://eskonr.com/2015/04/sccm-2012-troubleshoot-client-software-update-issues/


    Eswar Koneti | Configmgr Blog: www.eskonr.com | Linkedin: Eswar Koneti | Twitter: eskonr


    Thursday, April 28, 2016 5:36 AM
  • Hello,

    I know how to monitor updates... in fact I've always used Compliance and SCCM Console to monitor updates.

    BUT in this company, the IT Departement monitors Servers health via PRTG (monitoring tool).
    They check for:
    -CPU%,RAM%,HDD%,..... AND Updates.
    Now if the date of the client show the wrong date (I don't care, I can look in SCCM Console) my problem is that a warning appear on the moniroting tools.
    That is the reason because I need the correct "Updates were installed" date.

    Thursday, April 28, 2016 5:45 AM

  • That is the reason because I need the correct "Updates were installed" date.

    Configmgr do not provide you the exact time of the when did the updates installed on PC ,unless you do some customizations and Configmgr is not real-time servicing tool .

    I do not have information about PRTG tool and how they check for patches on client PC ,but when the patches are installed on PC (can be either using Configmgr or Manual) ,the date will be printed along with updates (can see from programs and features -view installed updates or WMI ) . You cannot get the same installed date of the updates (IMO) into Configmgr reports unless you do some customizations.

    So the question is--> Where do you see the Wrong Date ? and how did you confirm it is wrong date . Have you tried looking at view installed update ,Installed on or WMI ,WMI should give you lot more information about the updates and its installed date.

     

    Eswar Koneti | Configmgr Blog: www.eskonr.com | Linkedin: Eswar Koneti | Twitter: eskonr

    Thursday, April 28, 2016 6:17 AM
  • Hi Eswar,

    I see the wrong date locally on the machine under: Windows Updates - Updates were installed:

    Basically, if I deploy updates today, they install today, but on: Updates were installed I see the wrong date.

    Thursday, April 28, 2016 6:19 AM
  • Basically, if I deploy updates today, they install today, but on: Updates were installed I see the wrong date.

    How did you captured the updates installed date on the machine deployed by Configmgr? what date you see from control panel--programs and features--view installed updates and other date you said wrong ?

    Eswar Koneti | Configmgr Blog: www.eskonr.com | Linkedin: Eswar Koneti | Twitter: eskonr

    Thursday, April 28, 2016 7:15 AM
  • No, there the date are correct.

    As you can see here, my problem is this:

    Thursday, April 28, 2016 7:36 AM
  • No, there the date are correct.

    As you can see here, my problem is this:

    This is not right way of configuring the patch activity and you should never allow the client to connect to Microsoft directly if you are managing the updates using Configmgr . read this for more information about the complications allowing client to connect to Microsoft for patching http://blog.configmgrftw.com/software-updates-management-and-group-policy-for-configmgr-cont/

    The date you are seeing 'updates have been installed' and this is done by Configmgr .that's wrong way looking at it,but the actual patch installation date can be seen from (AGAIN 3rd time telling)  control panel--programs and features--view installed updates  is the correct way of identifying the Patch install date and not the one you think. 


    Eswar Koneti | Configmgr Blog: www.eskonr.com | Linkedin: Eswar Koneti | Twitter: eskonr


    Thursday, April 28, 2016 8:03 AM
  • I know where to check the correct installation date..

    but again, my problem is PRTG MONITORING tool... that goes to check the parameter: Updates were installed.

    So - my question was WHY the date Updates were installed don't match the actual install date.
    Because I know where to check, but PRTG not.

    (for example a fresh deployed machine, updated, as "Updates were installed" show: NEVER.
    Not a big deal for ME, because I can see the actual date under the control panel as you said...but PRTG can't...so it trow warnings.)

    • Edited by TDA1990 Thursday, April 28, 2016 8:50 AM
    Thursday, April 28, 2016 8:45 AM
  • So - my question was WHY the date Updates were installed don't match the actual install date.
    Because I know where to check, but PRTG not.

    It is because you never disabled the automatic updates for Configmgr and updates are getting from Microsoft ,who knows ? and further ,please read the Jason documentation to avoid all further complicates. I do not know why does your PRTG tool look at this date as this is not right method (IMO) of looking for patch install date and you should always check the compliance report or perform scanning tool that will tell you all the required patches installed or any failed patches.If you disable the automatic updates using GPO ,you will see the date as NEVER as you disallow client to get updates from Microsoft and you have more control over client for managing software updates.

    Eswar Koneti | Configmgr Blog: www.eskonr.com | Linkedin: Eswar Koneti | Twitter: eskonr

    Thursday, April 28, 2016 9:38 AM
  • The GPO is already set as NEVER.

    Client who have the date, is because before (like 2month ago) updates were deployed with WSUS not with SCCM (and when you deploy the updates with WSUS directly, the DATE is correct...even if the WSUS is not MICROSOFT ONLINE SERVER)

    Altrough, as said my question was to understand why SCCM/WindowsUpdate don't update this particular data even if it install the updates.

    I always check updates compliance with SCCM itself... but the IT TEAM of this company, uses PRTG and asked me : "WHY PRTG is telling us that the server aren't updated from 60days when you have said that you have updatet them with SCCM?"

    So I checked (and on the compliance in SCCM all was ok)...and saw that on the "client" the only thing wrong was the date... So my question wasn't about: how can I check if the computer has the updates...

    Thursday, April 28, 2016 9:45 AM

  • Altrough, as said my question was to understand why SCCM/WindowsUpdate don't update this particular data even if it install the updates.

    2 things here 1) if you have configured the GPO correctly and it that is applied on this client ,WHY does it is still allowing PC to connect to microsoft website ? anyone changed registry settings or so ? This is something you REALLY need to troubleshoot from GPO perspective

    2) if you have deployed the updates using Configmgr and to monitor the progress or installation time ,you can check via configmgr client logs, WMI or control panel BUT NOT using the method you are checking and this is completely out of scope for Configmgr client.

    So ,coming to the question ,you allowed client to patch using 2 possible ways 1) using connect to Microsoft update and install the patches 2) Using configmgr .  If you allow such configurations (2 ways ) ,configmgr will never know or do not bother about other method and it does what is supposed to do just like deploy the applicable software updates from Configmgr and do not care about allowing client to connect to Microsoft update and download patches.

    This is something you need to fix first before asking why does configmgr do not know about the installed date .

    So  in short ,you have allowed 2 ways of deploying the patches and both are independent ,one do not know other.


    Eswar Koneti | Configmgr Blog: www.eskonr.com | Linkedin: Eswar Koneti | Twitter: eskonr

    Thursday, April 28, 2016 10:44 AM
  • Maybe I've explained wrong... or I dunno.

    The environment is PATCHED with SCCM ONLY (prior was updated via internal WSUS) - it DOES NOT connect to Microsoft Windows Website....
    What you don't want to understand, is that my question was ONLY: Why the hell the date reported when you watch Windows Update is different from the one of the installed updates.

    Because, WUA is managed by SCCM.
    Now... when you use a WSUS ... the INSTALLED UPDATES date is correct...and you don't catch updates from internet... so the question was: why with SCCM is different?
    Maybe I found out, the date is updated only with INTERACTIVE updates (WSUS does interactive updates, SCCM doesn't).

    Thursday, April 28, 2016 11:06 AM
  • Well, if you are bound by the constraints of this PRTG tool, then I suppose your only option may be to "trick" it and set the registry property it's looking for to a date within the range that it expects to find. You could use a ConfigMgr compliance setting to do this with a PowerShell script. It might look something like this:

    $latestSUinstall = (Get-HotFix | Measure-Object -Maximum InstalledOn).Maximum
    
    [string]$datetimestring = Get-Date $latestSUinstall -Format "yyyy-MM-dd hh:mm:ss"
    
    Set-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\Results\Install' -Name LastSuccessTime -Value $datetimestring

    If you make a change to that registry property, you have to restart the Windows Update service before you see the change in the Windows Update UI.


    Thursday, April 28, 2016 1:26 PM
  • (Get-HotFix | Measure-Object -Maximum InstalledOn).Maximum
    


    That does not work in my case. Install dates on my testmachines are:

    02.12.2016 00:00:00     
    04.04.2016 00:00:00     
    03.10.2016 00:00:00 
    01.04.2016 00:00:00

    and PoSh returns 02.12.2016 00:00:00 - which is neither the oldest nor newest date.


    Torsten Meringer | http://www.mssccmfaq.de

    Thursday, April 28, 2016 1:43 PM
  • I've told the "IT team", that they have to check compliance over SCCM (as logically should be) and to disable the PRTG monitoring for Windows Updates.

    I've yet two further questions...
    1) The "Most recent check for updates" should work fine with SCCM or it's like the "updates were installed" ?
    2) There is a way to disable the "Check for updates" button?

    Cheers

    Thursday, April 28, 2016 1:46 PM
  • That's interesting Torsten. It seemed to work fine on my system, but I know dealing with datetimes can sometimes be tricky. How about

    (Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 1).InstalledOn

    Thursday, April 28, 2016 2:33 PM
  • 1. "Most recent check for updates" is controlled by a similar registry key and property: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\Results\Detect

    LastSuccessTime

    and I doubt ConfigMgr is setting that either

    2. I'm not sure if this disables the button entirely, but setting this in group policy will prevent the successful use of it:

    http://gpsearch.azurewebsites.net/#2790
    Thursday, April 28, 2016 2:49 PM
  • Ah ok...

    Shame :(
    Thanks for the gpo, already found :)

    Thursday, April 28, 2016 2:50 PM
  • Added a suggestion to UserVoice for ConfigMgr SUM to update the Windows Update Control Panel Applet date:

    https://configurationmanager.uservoice.com/forums/300492-ideas/suggestions/14810217-configmgr-sum-installs-should-update-the-date-of-l

     

    Give it a vote or three and we'll see if we can get this change into vNext.

    I hope that helps,

     

    Nash


    Nash Pherson, Senior Systems Consultant
    Now Micro - My Blog Posts
    If you found a bug or want the product to work differently, share your feedback.
    <-- If this post was helpful, please click the up arrow or propose as answer.

    Tuesday, June 14, 2016 3:18 PM