none
SCCM Clients not getting updates, WAUHandler just has one entry RRS feed

  • Вопрос

  • Hi There,

    Recently we had an issue which ultimately meant a rebuild of our SCCM server. We have SCCM 2019 on a Server 2016 box with SQL 2017 and WSUS configured. 

    All aspects of the system are working apart from windows updates. Boundaries and groups are setup, infact they are set to how they were before the rebuild. System centre is Synching with WSUS and all roles such as SUP/Management Point, Distribution are configured. 

    The clients however, no matter how many times I try and initiate a Software updates evaluation do nothing. The WAUHandler.log literally just has this:

    <![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]LOG]!><time="16:06:29.233-60" date="10-14-2019" component="WUAHandler" context="" type="1" thread="8864" file="cwuahandler.cpp:3162">

    We have configuration manager 1906. Its been a week now and constant trawling but I cannot seem to find anything to rectify this issue. If anyone has anything that might point me in the right direction it would be so helpful. 

    Thanks!

    14 октября 2019 г. 19:05

Ответы

  • All, I have managed to find a solution to this now, perhaps this might help others in the future as I had seen the same question I had unanswered on reddit too.

    Basically I noticed in adsiedit on the domain controller there was the System Management container which held all information from the previous site installation, my site code I changed on this rebuild. I deleted the container which held the old site code and key for management point, and then waited for Config Manager to re-publish to AD. I didn't hold out much hope, but low and behold the WAUHandler is now successfully completing and logs are building well on the clients. 

    Thanks

    • Помечено в качестве ответа Lukeass 15 октября 2019 г. 19:56
    15 октября 2019 г. 18:56

Все ответы

  • > "We have SCCM 2019"

    There's no such thing. As you noted at the end you have ConfigMgr 1906.

    For your issue, you need to assign your site system(s) hosting the software update point role to your boundary groups so that the client agent can properly map to them. Without knowing your topology, I can't tell you which ones; however, in many cases, adding the site system(s) hosting the software update point role to your default site boundary group is sufficient.


    Jason | https://home.configmgrftw.com | @jasonsandys

    14 октября 2019 г. 20:22
  • We  have system centre 2019. 1906. I did add site system to the boundary group - the configuration of the boundary and group configuration was set the same as before the rebuild. I have checked and it is definitely there, though the clients still fail to see the SUP server, or run the update task sequence when manually triggered. 
    15 октября 2019 г. 12:13
  • Do you see any error on client location.log

    Is the windows update scan is completed (Scanagent.log)

    Is the update shows required in SCCM console? Have you check the update deployment enforcement report?

    15 октября 2019 г. 12:24
  • We  have system centre 2019

    That's not indicative of the ConfigMgr version though. As noted, you have 1906.

    > I did add site system to the boundary group

    Which boundary group?

    What boundaries are in this boundary group and what kind of boundaries are they?

    What is the client's IP address and mask?


    Jason | https://home.configmgrftw.com | @jasonsandys

    15 октября 2019 г. 15:51
  • Thanks for the replies, so as follows:

    So I have a IP Range boundary, 172.22.102.1 > 254 and a class C subnet 255.255.255.0.

    From that I have a Boundary Group with the boundary mentioned above as a member, as it is all on one server the site server under reference is itself - it then has a relationship to the default site boundary in its properties. 

    There are no errors in the location.log nor in the Scanagent. It is like it is not even getting that far, the WAUHandler still sits with the same single message.

    15 октября 2019 г. 18:02
  • All, I have managed to find a solution to this now, perhaps this might help others in the future as I had seen the same question I had unanswered on reddit too.

    Basically I noticed in adsiedit on the domain controller there was the System Management container which held all information from the previous site installation, my site code I changed on this rebuild. I deleted the container which held the old site code and key for management point, and then waited for Config Manager to re-publish to AD. I didn't hold out much hope, but low and behold the WAUHandler is now successfully completing and logs are building well on the clients. 

    Thanks

    • Помечено в качестве ответа Lukeass 15 октября 2019 г. 19:56
    15 октября 2019 г. 18:56
  • As long as its fixed now, that's good.

    For th issue specifically, what you've noted implies that there was a boundary conflict with information from the old site that was confusing the client agent and causing it to not even be assigned to the correct site.


    Jason | https://home.configmgrftw.com | @jasonsandys

    15 октября 2019 г. 19:52
  • Hi Jason,

    Exactly that, the container in AD had the old site code referenced and management point. I literally deleted the container and within 15 minutes the config manager had republished a new System Management container with the new site code and MP. That was all, next thing the clients all started successful scans. It was only by repetitive searching I noticed this in adsiedit on the DC and made the change. 

    Thanks!


    • Изменено Lukeass 15 октября 2019 г. 20:00
    15 октября 2019 г. 19:59