You may be asking, what does IIS bindings have to do with SCCM software updates. Well, let me tell you lol.
I’ve stood up a new SCCM infrastructure including site configuration/roles and deployed a few clients. When testing software updates on a client, software update scan/deployment cycles kept failing. Upon investigation of logs, the scan were failing with “Scan failed with error = 0x80072efd”. Furthermore, reporting showed scan error failure code -2147012867. These errors indicate that the Windows Update Agent could not communicate with the defined source location.
The troubleshooting difficulty is that there are many possibilities of causing this.
- Local GPO “Specify intranet Microsoft update service location”. When using SCCM software updates, the client sets this local GPO on the client pointing to the WSUS location. In my case this wasn’t it.
- Windows Firewall blocking the ports used by WSUS, on either the client or server. In my case this wasn’t it.
- A proxy or bad winhttp settings redirecting the traffic incorrectly from client to server. In my case this wasn’t it.
- Various other things.
I believed that I had reached the end of the Internet at this point when finally I came across a posting on WindowsNoob that steered me in the right direction. To fix a different technical problem with WSUS conflicting with Symantec Endpoint Protection, I swapped the Software Updates Component from using ports 80/443 to using ports 8530/8531. I guess with this change, SCCM didn’t automagically configure the default website in IIS bindings to listen for requests on the newly defined port.
So to resolve the issue, I did the following:
- Open IIS Manager
- Right-click on the default website and select “Edit Bindings”
- Add port 8530 as an IIS binding….and voila it works.