locked
Why does my v1709 say it is out of date with updates when SCCM says it is up to date and compliant? RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    1
    Sign in to vote

    My v1709 computers are showing below saying they are not up to date. The particular computers showing this show up as compliant when I go to Monitoring > Deployments > Patch Tuesday Windows Updates.

    Why do the computers show as compliant if they are not?
    Why does the computer say it is not up to date if it is not able to contact Windows Updates in the first place but is set to contact SCCM for updates?

    These are the updates that have been deployed for v1709 via my ADR/SUG 

    If I check the installed update history on the computer it shows the last install was 5/18. I pushed these updates out on 5/24.

    When I search the WUAHandler.log file on the computer it shows that it has 2 out of the 3 updates for v1709 that were pushed out. It is missing the Cum Update for v1709 KB4103727 apparently. It installed KB4103729 and KB4132650 according to the log but says nothing about the cumulative update. I was hoping for a fail message or something.

    Why if it shows that it installed does that not show in the "View installed update history" in Windows?
    Why does it show show compliant for that SUG if it did not install the cumulative update (probably the most important update)?

    When I look at the reporting for that specific update, the computer in reference is shown as state unknown, yet that same computer shows as compliant in monitoring.... Why do you contradict yourself SCCM?


    • Edited by SCCMN0ob Wednesday, May 30, 2018 7:22 PM
    Wednesday, May 30, 2018 6:32 PM

Answers

  • Question
    Sign in to vote
    1
    Sign in to vote

    Yes, I agree. This is a major pain. And guess what, not everyone notices this issue because of the fact that the reports show these systems as compliant. And guess what, this isn't anything new. Older OS versions had the same issue of reporting as compliant when they weren't as well it just wasn't as wide spread of an issue because WSUS had a way to mitigate the issue for older OS versions.

    I deploy SCCM software updates monthly to my company's systems using a phased approach. The first phase is running the updates on a couple test systems I have. I check to ensure they actually get updates or not so I noticed this issue right away. If you aren't thorough in checking systems you might not notice this and just think everything is compliant because the reports say they are. I've only ever used SCCM with WSUS so I'm am unsure if WSUS stand-alone has the same issue but I'd imagine it does as well since SCCM uses WSUS as the backbone of the Software Updates feature, including scanning of the systems for updates it needs.

    I contacted Microsoft Support about this issue and below is the reason/resolution to it. This was sometime last year and I haven't seen/heard anything newer regarding this.

    The reason your systems are reporting as compliant but are not is because the Windows Update Agent version is out of date. For older versions of Windows WSUS had a component that would check the WUA version and deploy the newest version using a small package downloaded via the IIS WSUS website. But, for Windows 10 Microsoft didn't create a small package to update the WUA. Also, the WUA in Windows 10 is updated on a regular basis! The only way the WUA is updated on Windows 10 is through the monthly cumulative updates which can be 700MB-1GB in size for the whole package. If your clients happen to miss a monthly cumulative update that included a newer WUA the next month they scan against a new CAB on the WSUS server they don't see they need any updates and report they are compliant.

    I was curious as to why if I scan for updates against Microsoft online update servers it is able to detect the required updates while WSUS cannot. MS support said that the online update servers don't work the same way as WSUS. I can't for the life of me think why Microsoft can't make WSUS work the same was the online update servers in this regard. But anyways, the solution given to me was to install the most recent cumulative update. So, I find myself manually downloading the most recent cumulative update every couple of months and deploying it to Windows 10 systems that show an older WUA on them using a regular deployment package outside of the Software Updates features. I use a collection query which adds systems with older WUA versions and then deploy the latest cumulative update to the collection. If you have several different builds of Windows 10 you will have to do a collection/package for each version you have.

    UPDATE: I've found that Server 2016 is also affected by this issue. I was trying the solution previously suggested by downloading and installing the latest cumulative update to get the WUA to the latest version. What I found was that the latest cumulative update says it doesn't apply. So that solution fell flat on it's face. So I started digging some more to try and resolve it.

    I noticed when I performed scans for updates online it was grabbing KB4132216. KB4132216 is a servicing stack update (SSU). I wasn't aware of these until now and Microsoft support didn't mention anything about them. The SSU is a small 11MB package. KB4132216 is not the latest SSU and had to be installed before the latest one would install. After KB4132216 was installed I installed the latest SSU (KB4465659) then performed a scan for updates with the SCCM client. Scan detected that this month's CU was needed from SCCM/WSUS after doing this!

    So the actual solution to this is to deploy the servicing stack updates via a regular SCCM package instead of trying to deploy a large cumulative update package that was previously suggested. You can create a collection query to add all systems that do not have the SSU that is required then deploy the package to the collection. If I'm not mistaken you have to enable inventory to collect the Quick Fix Engineering (QFE) info. Once that inventory comes in then you can create a sub-select collection query to bring back any systems that do not have the KB installed.

    The great thing about the servicing stack updates are they are really small packages and they don't require a reboot! I don't know why Microsoft can't implement a detection mechanism in WSUS to see that the latest servicing stack update is applied and if not install it.

    Paul

    • Marked as answer by SCCMN0ob Wednesday, October 3, 2018 12:48 PM
    • Edited by PRAMAG Friday, January 25, 2019 2:26 PM
    Monday, October 1, 2018 8:22 PM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi SCCMN0ob,

     

    From the installed update history and reporting for the "KB4103727"
    We could know the "KB4103727" didn't installed and not reported status.

    So you could click the "Software Updates Scan Cycle" and "Software Updates Deployment Evaluation Cycle" on the client and click the "Evaluation Software Update Deployments" on the device collection of the client in ConfigMgr console.

    In additon, i saw the "KB4103727" has been replaced by the KB4103714(e.g. image)

    You could try to deploy the latest CU for the client.

    Other related links for the similar error on client:

    https://answers.microsoft.com/en-us/windows/forum/windows_10-update/your-device-is-at-risk-because-its-out-of-date-and/8be130eb-493a-4f03-b655-2a4a5de42cfe?auth=1
    https://www.drivereasy.com/knowledge/solved-how-to-fix-some-settings-are-managed-by-your-organization-error-on-windows-10/
    Hope it helps.


    Best regards
    Yuxiang

    Please remember to mark the replies as answers if they help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, May 31, 2018 3:50 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    When I check in ConfigMgr and look at KB4103727 mine does not show that it has been superseded. I checked in my WSUS and it does not show either and KB4103714 is not there in Configmgr or WSUS.

    The 2nd link you provided talks about removing the text "Some settings are managed by your organization" That is supposed to be there so I don't want to remove that.

    On one of my v1709 I computer I went ahead and enabled the "Check online for Windows Updates" button and clicked it and it is downloading the KB4103727 from Windows updates, wonder why if it has been superseded by KB4103714? After I clicked the check online for windows updates everything shows correctly and the computer is up to date. Glad SCCM is great at updating my computers - sarcasm.

    I did the troubleshooter for Windows Update from your first link and that didn't do anything. Some of the other responses are a bit ridiculous having to download other KB's to get it fixed, this is occurring on several different computers so I hope I do not need to do this on every single computer. 

    Still though, I am hoping that the solution is not to have everyone click check online for windows updates....

    Thursday, May 31, 2018 1:27 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    KB 4103714 is not released to WSUS. This is stated in the KB article. That's why it's not superseded in WSUS/CM.

    Rolf Lidvall, Swedish Radio (Ltd)

    Thursday, May 31, 2018 2:13 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Gotcha, thanks. I guess for now I need to have everyone who has this issue to click the "Check online for windows updates" button and get their updates from Windows Updates this time because that fixed my computer. Rather annoying that it is not installing via SCCM.
    Thursday, May 31, 2018 3:07 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I deployed just KB4103727 directly to a collection that has a v1709 computer that shows out of date and needs KB4103727 and the deployment shows that the computer is compliant.........

    Wha??? Windows Update still says the device is at risk and doesn't show anywhere that it is installed.


    Just checked that specific update on that collection where that computer is and it shows that update as not required so thats why it is compliant. I know if I click "Check online for Windows Updates" that it is going to download and install that update.... This is making no sense. Every update for Win 10 v1709 has been installed on this machine (except for KB4103727 which it is saying not required, even though it is....) not sure why it is saying out of date aside from it really does need that update and in that case im not sure why sccm is saying it is not required..


    • Edited by SCCMN0ob Thursday, May 31, 2018 3:21 PM
    Thursday, May 31, 2018 3:14 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Well I guess since there doesn't seem to be a solution for this through SCCM I will just wait until this coming patch Tuesday and push out those patches and hopefully it will update and stop showing the computer is at risk. What a pain.
    Friday, June 1, 2018 1:11 PM
  • Question
    Sign in to vote
    1
    Sign in to vote

    Yes, I agree. This is a major pain. And guess what, not everyone notices this issue because of the fact that the reports show these systems as compliant. And guess what, this isn't anything new. Older OS versions had the same issue of reporting as compliant when they weren't as well it just wasn't as wide spread of an issue because WSUS had a way to mitigate the issue for older OS versions.

    I deploy SCCM software updates monthly to my company's systems using a phased approach. The first phase is running the updates on a couple test systems I have. I check to ensure they actually get updates or not so I noticed this issue right away. If you aren't thorough in checking systems you might not notice this and just think everything is compliant because the reports say they are. I've only ever used SCCM with WSUS so I'm am unsure if WSUS stand-alone has the same issue but I'd imagine it does as well since SCCM uses WSUS as the backbone of the Software Updates feature, including scanning of the systems for updates it needs.

    I contacted Microsoft Support about this issue and below is the reason/resolution to it. This was sometime last year and I haven't seen/heard anything newer regarding this.

    The reason your systems are reporting as compliant but are not is because the Windows Update Agent version is out of date. For older versions of Windows WSUS had a component that would check the WUA version and deploy the newest version using a small package downloaded via the IIS WSUS website. But, for Windows 10 Microsoft didn't create a small package to update the WUA. Also, the WUA in Windows 10 is updated on a regular basis! The only way the WUA is updated on Windows 10 is through the monthly cumulative updates which can be 700MB-1GB in size for the whole package. If your clients happen to miss a monthly cumulative update that included a newer WUA the next month they scan against a new CAB on the WSUS server they don't see they need any updates and report they are compliant.

    I was curious as to why if I scan for updates against Microsoft online update servers it is able to detect the required updates while WSUS cannot. MS support said that the online update servers don't work the same way as WSUS. I can't for the life of me think why Microsoft can't make WSUS work the same was the online update servers in this regard. But anyways, the solution given to me was to install the most recent cumulative update. So, I find myself manually downloading the most recent cumulative update every couple of months and deploying it to Windows 10 systems that show an older WUA on them using a regular deployment package outside of the Software Updates features. I use a collection query which adds systems with older WUA versions and then deploy the latest cumulative update to the collection. If you have several different builds of Windows 10 you will have to do a collection/package for each version you have.

    UPDATE: I've found that Server 2016 is also affected by this issue. I was trying the solution previously suggested by downloading and installing the latest cumulative update to get the WUA to the latest version. What I found was that the latest cumulative update says it doesn't apply. So that solution fell flat on it's face. So I started digging some more to try and resolve it.

    I noticed when I performed scans for updates online it was grabbing KB4132216. KB4132216 is a servicing stack update (SSU). I wasn't aware of these until now and Microsoft support didn't mention anything about them. The SSU is a small 11MB package. KB4132216 is not the latest SSU and had to be installed before the latest one would install. After KB4132216 was installed I installed the latest SSU (KB4465659) then performed a scan for updates with the SCCM client. Scan detected that this month's CU was needed from SCCM/WSUS after doing this!

    So the actual solution to this is to deploy the servicing stack updates via a regular SCCM package instead of trying to deploy a large cumulative update package that was previously suggested. You can create a collection query to add all systems that do not have the SSU that is required then deploy the package to the collection. If I'm not mistaken you have to enable inventory to collect the Quick Fix Engineering (QFE) info. Once that inventory comes in then you can create a sub-select collection query to bring back any systems that do not have the KB installed.

    The great thing about the servicing stack updates are they are really small packages and they don't require a reboot! I don't know why Microsoft can't implement a detection mechanism in WSUS to see that the latest servicing stack update is applied and if not install it.

    Paul

    • Marked as answer by SCCMN0ob Wednesday, October 3, 2018 12:48 PM
    • Edited by PRAMAG Friday, January 25, 2019 2:26 PM
    Monday, October 1, 2018 8:22 PM
  • Question
    Sign in to vote
    1
    Sign in to vote

    Wow that is terrible! lol, Microsoft is a mess man.

    Thanks for the advice, this helps.

    Wednesday, October 3, 2018 12:48 PM