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.
Recently I ran into a problem installing the SCCM client on some Windows Server 2008 R2 systems. In digging through client.msi.log, I found errors 0x80004005 and 1603. Steve Schofield, Microsoft MVP for IIS, discovered the problem was with the client install was, for some reason, performing IIS checks on anonymous authentication. If the authentication is configured to use Application Pool Identity, which was a new feature in IIS 7, then the install will fail. The workaround is simply to switch to using IUSR, install the client, and switch back to the Application Pool Identity.
This successfully resolved my issues on a dozen R2 servers! Thank you Steve!!
The original post: http://www.iislogs.com/steveschofield/iusr-account-and-sccm-2007-r3-agent
More thorough explanation: http://www.iislogs.com/steveschofield/iis-7-iusr-account-sccm-2007-client-status-messages-not-working