none
SCCM Client PC's failing to download/install Windows Updates RRS feed

  • Question

  • Hi,

    Last month I noticed that our client PC's, shortly after they had built (using SCCM Task Sequence)  were downloading and installing Windows Updates using the usual Windows Update process. What I mean is, I had Software Centre showing Updates as installing, but also had the Windows Update agent installing various updates. It was also showing in the start menu (Yellow icon saying Shut down and install updates). Now my understanding is, that that shouldn't of been happening, and only SCCM/Software Centre should be showing Windows Updates as installing.

    I noticed that we had some GPO's set for Windows Updates, which I have disabled, as I believed these were not necessary. Also, I like to control my Updates via SCCM Software Update groups after testing them, and not just allow clients to grab any updates that are required and approved.

    My problem now is, none of the clients are getting/installing any updates. I'm getting the following errors in the WUAHandler.log:

    Unable to read existing WUA resultant policy. Error = 0x80070002. WUAHandler 09/04/2015 19:03:29 8732 (0x221C)
    Group policy settings were overwritten by a higher authority (Domain Controller) to: Server  and Policy NOT CONFIGURED WUAHandler 09/04/2015 19:03:29 8732 (0x221C)
    Failed to Add Update Source for WUAgent of type (2) and id ({FC358571-80C5-4EAA-8A33-F79AD4C14785}). Error = 0x87d00692. WUAHandler 09/04/2015 19:03:29 8732 (0x221C)

    So, I've checked in:

    HKLM\Software\Policies\Microsoft\Windowa\WindowsUpdate\ & HKLM\Software\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate 

    and neither have a WSUS server set. I'm assuming this is correct?

    RSOP shows all policies in \\Computer Configuration\Administrative Templates\Windows Components\Windows Update as DISABLED

    GPEDIT shows \\Computer Configuration\Administrative Templates\Windows Components\Windows Update\Specify intranet Microsoft update service location as Enabled and as our server (https://XXX.XXX:8531) - I'm assuming this is what SCCM client sets as if I changed this setting and then restart the setting comes back. If it was a Group Policy conflict then I would expect to see it in RSOP.

    Does anyone have any suggestions? I'm puzzled as to what to look at next. Is my first assumption of having 0 group policies configured for WSUS correct? Am I also correct in assuming Windows Updates shouldn't show in Control panel, or at the Start > Shutdown prompt, and only show in Software Centre?

    Thanks, and sorry for the long winded post!


    • Edited by PageyUK Friday, April 10, 2015 10:28 AM
    Friday, April 10, 2015 10:27 AM

Answers

  • You should always set the Configure Automatic Update setting to Disabled to prevent exactly what you've described: specifically, autonomous activity by the WUA including rebooting systems that have a pending reboot and installation of updates directly approved in WSUS.

    As for the Windows Update Control Panel and Shutdown integration, that's all only valid for activities initiated and controlled by the WUA and thus does not include updates delivered and deployed by ConfigMgr.

    Finally, if you are getting the message that settings are being overwritten by a higher authority but you have no domain GPOs set to do this, there are known issues with the Windows Update/WUA settings not being properly reset after the GPOs are removed from a system. To my knowledge, the only course of action here is to delete the local GPO cache and reinitialize it: https://macgyveritblog.wordpress.com/2014/01/27/recreate-the-local-group-policy-cache-in-windows/


    Jason | http://blog.configmgrftw.com | @jasonsandys

    Friday, April 10, 2015 4:07 PM

All replies

  • Friday, April 10, 2015 10:44 AM
  • Hi,

    Thanks, I assumed as much, but RSOP doesn't show any policies on clients with the issue.

    Can you tell me what, if any of the GPO's need to be enabled for clients to only get updates from WSUS?

    Can you also tell me if the Windows Update Control Panel applet, and the Start > Shutdown button should interact with Windows Updates, or should it just be shown in Software Centre?


    • Edited by PageyUK Friday, April 10, 2015 12:23 PM
    Friday, April 10, 2015 11:51 AM
  • Hi,

    Just a further thought as I look into this some more, is this happening because theWindows Update > Configure Automatic Updates policy is set to 'Disabled' when it should be set to 'Not Configured' ?

    Essentially, my concern is if that is configured, and pointed to the SCCM SCUP (Which has the Windws Update Service Role installed - as a Replica) will it install any updates that are Required and Approved, or will it only install updates I have deployed from SCCM via an Update Group?

    • Edited by PageyUK Friday, April 10, 2015 2:29 PM
    Friday, April 10, 2015 2:27 PM
  • You should always set the Configure Automatic Update setting to Disabled to prevent exactly what you've described: specifically, autonomous activity by the WUA including rebooting systems that have a pending reboot and installation of updates directly approved in WSUS.

    As for the Windows Update Control Panel and Shutdown integration, that's all only valid for activities initiated and controlled by the WUA and thus does not include updates delivered and deployed by ConfigMgr.

    Finally, if you are getting the message that settings are being overwritten by a higher authority but you have no domain GPOs set to do this, there are known issues with the Windows Update/WUA settings not being properly reset after the GPOs are removed from a system. To my knowledge, the only course of action here is to delete the local GPO cache and reinitialize it: https://macgyveritblog.wordpress.com/2014/01/27/recreate-the-local-group-policy-cache-in-windows/


    Jason | http://blog.configmgrftw.com | @jasonsandys

    Friday, April 10, 2015 4:07 PM
  • Hey Jason,
    Thanks for replying and explaining the WUA stuff. That made sense to be but my mind was being clouded by the issue all of the PC's/Clients onsite were, and are still getting. I cleared out the Group Policy cache as detailed on the link.

    - Cleared C:\Program Data\Microsoft\Group Policy\History\*.*
    - Ran a gpupdate /force
    - Restarted PC

    Issue still remains. Here is the output from the WUAHandler.log

    CWuaHandler::SetCategoriesForStateReportingExclusion called with E0789628-CE08-4437-BE74-2495B842F43B;E0789628-CE08-4437-BE74-2495B842F43B,A38C835C-2950-4E87-86CC-6911A52C34A3; for leaves and E0789628-CE08-4437-BE74-2495B842F43B,A38C835C-2950-4E87-86CC-6911A52C34A3; for bundles 
    WUAHandler 13/04/2015 16:14:34 2508 (0x09CC)
    Its a WSUS Update Source type ({FC358571-80C5-4EAA-8A33-F79AD4C14785}), adding it. WUAHandler 13/04/2015 16:15:02 2488 (0x09B8)
    Unable to read existing resultant WUA policy. Error = 0x80070002. WUAHandler 13/04/2015 16:15:02 2488 (0x09B8)
    Enabling WUA Managed server policy to use server: https://(Name.domain of our SCCM SUP):8531 WUAHandler 13/04/2015 16:15:02 2488 (0x09B8)
    Waiting for 2 mins for Group Policy to notify of WUA policy change... WUAHandler 13/04/2015 16:15:02 2488 (0x09B8)
    Unable to read existing WUA resultant policy. Error = 0x80070002. WUAHandler 13/04/2015 16:15:11 2488 (0x09B8)
    Group policy settings were overwritten by a higher authority (Domain Controller) to: Server  and Policy NOT CONFIGURED WUAHandler 13/04/2015 16:15:11 2488 (0x09B8)
    Failed to Add Update Source for WUAgent of type (2) and id ({FC358571-80C5-4EAA-8A33-F79AD4C14785}). Error = 0x87d00692. WUAHandler 13/04/2015 16:15:11 2488 (0x09B8)

    Monday, April 13, 2015 3:25 PM
  • worth a look?

    http://eskonr.com/2014/10/sccm-configmgr-2012-software-update-scan-error-group-policy-settings-were-overwritten-by-a-higher-authority-error-code-0x87d00692/

    Hi,

    Thanks for that. I also found that article, and attempted those steps:

    - Checked HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate 

    (The only key on the root was (Default) REG S_SZ. There are multiple keys in the sub AU Key (See below screenshot)

    - Deleted C:\Windows\System32\GroupPolicy\Machine\Registry.pol

    - Restarted SMS Agent/Service

    - Initiated the Software Updates Scan Cycle & Software Updates Deployment Evaluation Cycle

    - Logfile still says the same.

    - Repeated the above with a restart, still the same.

    Here is what RSOP Shows:


    • Edited by PageyUK Monday, April 13, 2015 5:12 PM
    Monday, April 13, 2015 5:08 PM
  • Also, GPEDIT shows this, which I assume is being set by the SCCM Client?

    Opening that entry shows my SCCM SCUP:

    - Set the intranet update service for detecting updates: https://XXXXX.domain:8531

    - Set the intranet statistics server: https://XXXXX.domain:8531

    (obviously XXXXX.domain is the SCUP server and the domain it resides in)


    • Edited by PageyUK Monday, April 13, 2015 5:36 PM
    Monday, April 13, 2015 5:35 PM
  • Also, GPEDIT shows this, which I assume is being set by the SCCM Client?

    Yes, the SCCM Client shall create those two settings. This is by design. Are you saying that on a client where those settings are present, you still get the "overwritten by a higher authority" message?

    If that's true, then that's of no particular importance, because as long as those values point to the correct server, then it really doesn't matter if they are last created by the SCCM Client or a Domain GPO. But as discussed earlier in this thread, the only WSUS related GPO that should be configured in a SCCM environment is "Configure Automatic Updates" = Disabled.


    Rolf Lidvall, Swedish Radio (Ltd)

    Tuesday, April 14, 2015 9:02 AM
  • Also, GPEDIT shows this, which I assume is being set by the SCCM Client?

    Yes, the SCCM Client shall create those two settings. This is by design. Are you saying that on a client where those settings are present, you still get the "overwritten by a higher authority" message?

    If that's true, then that's of no particular importance, because as long as those values point to the correct server, then it really doesn't matter if they are last created by the SCCM Client or a Domain GPO. But as discussed earlier in this thread, the only WSUS related GPO that should be configured in a SCCM environment is "Configure Automatic Updates" = Disabled.


    Rolf Lidvall, Swedish Radio (Ltd)

    Hi,

    Yes, on that particular client which has those settings in the above screenshot, I still get the "overwritten by a higher authority" message. Is there anything else I can check? Here is what the Client settings are set at on SCCM. 

    That's it. I assume the server name itself, is set by the client, and not a user entered variable?

    Tuesday, April 14, 2015 9:19 AM
  • One other thing I have just noticed, is that the server listed/set in the Configure Site Components > Software Update point. Under the Sync Settings tab, there is a different server set. I assume this is correct and fine, as this is simply just where SCCM sync's its updates from....

    The option Synchronize from an upstream data source location (URL) is https://servername.domain/ (obviously servername.domain is a name of a server we have, with the correct domain suffix.)

    Oddly, there is no port set, but syncing and downloading updates from this source does work... Does this server need to be the same SCUP that the clients use, or is this irrelevant?

    Tuesday, April 14, 2015 9:29 AM