Scanning, deploying and installing software updates should be a walk in the park, and most of the times it is. But (luckily) sometimes we run into issues that we haven’t seen before. Like in this case where clients stopped scanning for software updates in ConfigMgr 1602. What I have learned in my years working with ConfigMgr is that software update issues often are caused by older version of the Windows Update agent, configuration change on the WSUS server(s) or a change in the infrastructure. The challenge is to figure out is what category your issues falls into. Normally, it’s fairly easy to tell if it’s one or the other. Simply look at the client impact, and you have your answer.

Personally when troubleshooting, I always start by looking at the WSUSApp pool and these log files found on the ConfigMgr client:

· scanagent.log and wuahandler.log – Both are ConfigMgr log files and will often tell when we are having issues. In my example scanagent.log and wuahandler.log was full of errors like:
ScanJob({DA9C4596-5B82-4155-B223-D23A5B3436A7}): CScanJob::OnScanComplete -Scan Failed with Error=0x80244017
ScanJob({DA9C4596-5B82-4155-B223-D23A5B3436A7}): CScanJobManager::OnScanComplete- failed at CScanJob::OnScanComplete with error=0x80244017

When searching for similar error code on Google (and even Bing), you’ll find several forum threads and blog posts stating the you might have a proxy issue. In my example we didn’t have any proxy server, why I normally move on and check two other log files:

  • WindowsUpdate.log on the client and the IIS log files on my WSUS server.
    2016-04-20 13:17:44:532 276 3208 PT + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://wsus01.viaMonstra.com:8530/ClientWebService/client.asmx
    2016-04-20 13:17:44:547 276 3208 WS WARNING: Nws Failure: errorCode=0x803d0005
    2016-04-20 13:17:44:547 276 3208 WS WARNING: There was an error communicating with the endpoint at ‘http://wsus01.viamonstra.com:8530/ClientWebService/client.asmx’.
    2016-04-20 13:17:44:547 276 3208 WS WARNING: The server returned HTTP status code ‘403 (0x193)’ with text ‘Forbidden’.

The interesting part of this snippet is this line server returned HTTP status code ‘403 my client is clearly communicating with the server, but the server isn’t happy. Next step is to figure out, why the server is refusing to communicate with my clients. The best way to see that, is by looking at the IIS files on your WSUS server.

  • IIS log files on my WSUS server.
    2016-04-20 12:34:11 10.1.4.108 POST /SimpleAuthWebService/SimpleAuth.asmx – 8530 – 172.144.187.168 Windows-Update-Agent – 403 4 5 218
    2016-04-20 12:34:11 10.1.4.108 POST /ClientWebService/client.asmx – 8530 – 172.1.154.18 Windows-Update-Agent – 403 4 5 1965

Again, pay attention to this part Windows-Update-Agent – 403 4. IIS error 403 4 = SSL required.

By looking at these 4 log files, here is what we know so far. Clients are trying to communicate with the WSUS server, but are refused by IIS because they aren’t using SSL. This makes fixing the problem super easy, only one question left to answer; – are we supposed to use SSL or not. In this example, we were not supposed to use SSL.

A quick check in IIS revealed that SSL settings were configure to Require SSL.

image

After disabling Require SSL and recycling the WSUSApp pool clients started to successfully communicate with IIS and perform software update scans again.

2016-04-20 17:40:42 ::1 POST /ApiRemoting30/WebService.asmx – 8530 viamonstra\sccm01$ ::1 Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+4.0.30319.34209) – 200 0 0 0

2016-04-20 17:40:42 10.1.4.108 POST /ReportingWebService/ReportingWebService.asmx – 8530 – 172.38.20.199 Windows-Update-Agent – 200 0 0 0

Notice the IIS return code is 200 – and we all love 200 🙂