Let’s discuss how to Fix SCCM Scan Issues with Software Update Patching. Software Update SCAN errors are prevalent. In large environments, it’s tough to determine the cause of these errors. We need to work with different teams to resolve this kind of issue. FIX SCCM Scan Issues with Software Updates.
The proxy settings configured on the core servers can cause communication issues for clients trying to reach the WSUS server. All client communications intended for the WSUS/SCCM server (FQDN) are blocked at the proxy server.
In this post, I’ll share one of my experiences, especially with Windows 2008 R2 core servers (I found it difficult to troubleshoot on Windows CORE servers).
The latest post on Software Updates and Patching on SCCM or ConfigMgr is in the link below. Fix SCCM Client-Side Patching Or Software update issues. Troubleshooting Tips HTMD Blog (anoopcnair.com).
| Index |
|---|
| SCCM Scan Issues |
| Cause for SCCM Scan Issues with Software Updates |
| Solution – Fix SCCM Scan Issues with Software Updates |
| General Patching Issue – FIX SCCM Scan Issues with Software Updates |
SCCM Scan Issues
The scan error was due to incorrect proxy settings in the environment. The system context proxy settings should be blank ( that means the internal FQDN should have direct access).
In our case, the system context proxy setting also pointed to the proxy server; hence, all the internal FQDN communications went through the proxy server, and the SCCM clients could not reach the WSUS server.
The scan agent is failing; hence, the SCCM patching is also failing for all the Windows servers.
Cause for SCCM Scan Issues with Software Updates
Proxy settings configured in the core servers create the client’s communication block to reach the WSUS server. All communications initiated by the client to get the WSUS/SCCM server (FQDN) are stopped at the proxy server.
Ideally, all internal FQDN (WSUS/SCCM server) communication should not go to/through a proxy server. In our case, all the communications are going to the proxy server, producing unexpected results.
Solution – Fix SCCM Scan Issues with Software Updates
Reset the proxy settings in the Windows 2008 core server, as mentioned below.
“netsh winhttp reset proxy”
Run “netsh winhttp show proxy” command from CORE server.
Restart the “Windows Update” (for Windows 7 and Windows 2008) service to reinitiate scanning and patching processes.
General Patching Issue – FIX SCCM Scan Issues with Software Updates
A. Group Policy conflict
Ensure that the following three policies are not configured from the domain level. The SCCM client will apply the policy whenever it is required.
- Allow signed content from intranet Microsoft update service location.
- Specify intranet Microsoft update service location.
- Automatic Updates Configuration
See the Technet article for more details – http://go.microsoft.com/fwlink/?LinkId=94680.
B. Additional information: If the above steps do not resolve the issue, the following steps will help to segregate or Identify the issue
- Disabling the SCCM Agent on the affected machine. To do this, you can run the following commands:
Disable the Service sc config CcmExec start= disabled
Stop the Service net stop CcmExec - Ensure that the following policy is not enforced on the system:
User Configuration\Administrative Templates\Windows Components\Windows Update\Remove access to use all Windows Update Features - Check this first in the local system policy (you can pull this up using gpedit. msc—Local Group Policy Editor). After that, please run RSOP.msc and ensure the policy is not configured. This will also give you information about domain policies. If the policy is enabled, please either remove it or disable it.
- Restart the Automatic Updates service.
- Now, from the command line, run the following command:
Configure Proxy proxycfg.exe –p “WSUS SERVER FQDN”
By doing this, we are configuring WinHTTP to bypass server access in the upper case.
At this point, we need to test an update scan. Since the SMS Host Agent service is disabled and stopped, we won’t be able to use the agent to run the scan. In this case, we would need to run a scan using the command below:
wuauclt /resetauthorization /detectnow
Check Windowsupdate.log for the outcome of the testing
How do you bypass the proxy server to test using the proxycfg utility? (More details http://msdn.microsoft.com/en-us/library/windows/desktop/ms761351(v=vs.85).aspx).
Also, find the registry entries you can check for the bypass list
“HKEY_LOCAL_MACHINE\ SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Connections\.”
C. I have a similar problem, which was explained in the Technet thread. We took network traces and found that internal communication to the WSUS server also goes to an external proxy (even though that is applicable only for internet communications).
Finally, the proxy settings in a WPAD entry in the DHCP scope (“252 WPAD” Wpad entry) are incorrect. WPAD entry in the DHCP scope is not required as we use group policy for proxy settings. We removed the WPAD setting, and the problem was resolved.
I hope this helps fix the FIX SCCM scan issues with software updates.
Resources
- SCCM Patching Software Update Process Guide – https://www.anoopcnair.com/sccm-software-update-patching-process-guide/
We are on WhatsApp. To get the latest step-by-step guides and news updates, Join our Channel. Click here –HTMD WhatsApp.
Author
Anoop C Nair is Microsoft MVP! He is a Device Management Admin with more than 20 years of experience (calculation done in 2021) in IT. He is a Blogger, Speaker, and Local User Group HTMD Community leader. His primary focus is Device Management technologies like SCCM 2012, Current Branch, and Intune. He writes about ConfigMgr, Windows 11, Windows 10, Azure AD, Microsoft Intune, Windows 365, AVD, etc.
Hi Anoop
I have SCCM 2012 R2 in our enterprise for managing 10000 desktops. We are using SUP for patch deployment, still many machines are updating its Microsoft patches automatically from internet bypassing SCCM which creates some issues on some of our custom applications to stop working. How can we set it strictly via SCCM only?
Hi Anoop. Thank you for sharing this piece of information. Your blogs never leave with without an answer. I do however have a question. We have around 3k clients in our estate that continue to scan ESU update that was made available by Microsoft on July 30th, which was later superseded by August Monthly quality rollup. How is it possible, clients continue to scan for an older update when its newer version is already deployed. Unless there is a remote possibility and an off theory, it will only scan but never install or download the older update and how do we remediate this issue. Reinstalling the client or hard resetting the policy on all these clients will put an immense load on site as clients download the policies.