ConfigMgr (SCCM) – Troubleshooting Tips to Resolve Scan Issues in Software Updates

ConfigMgr (SCCM) – Troubleshooting Tips to Resolve Scan Issues in Software Updates

Thought of sharing one of the interesting issue which I faced. The SCAN was not getting completed successfully. Most of the machines are windows 2008 core servers so with GUI it was not that much easy to troubleshoot (at least for me :)

Issue

 

Scan agent was not able to compete the scan successfully. Hence the Software Update patching was not working all the Windows 2008 Core servers.

Cause

 

After the troubleshooting and network capture, it has been noticed that the proxy server was blocking the communication between the client and WSUS server. Proxy settings configured in the core servers was creating the communication block for client to reach WSUS server. All the communications initiated by client to reach WSUS/SCCM server (FQDN) were getting terminated at the proxy server.

Ideally, all the internal FQDN (WSUS/SCCM server) communication should not go to/through proxy server. In our case all the communications were going to proxy server and producing unexpected results.

Solution

 

Reset the proxy settings in the Windows 2008 core server as mentioned in the below.

“netsh winhttp reset proxy”

Ran “netsh winhttp show proxy” command from CORE server.

Restarted “Windows Update” (for windows 7 and windows 2008) service to reinitiate scanning and patching processes.

General software update troubleshooting Tips

A. Group Policy conflict

 

Ensure that the following three policies mentioned are not be configured from domain level. The SCCM client will apply the policy whenever it is required.

a. Allow signed content from intranet Microsoft update service location.

b. Specify intranet Microsoft update service location

c. Automatic Updates Configuration

See Technet article for more details – http://go.microsoft.com/fwlink/?LinkId=94680

B. Additional information if above steps are not resolving the issue. Following steps will help to segregate or Identify the issue

 

1. On the affected machine, disable the SCCM Agent. To do this, you can run the following commands:
Disable the Service  sc config CcmExec start= disabled
Stop the Service  net stop CcmExec

2. 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 that the policy is not configured either. This will give you information from domain policies too. If the policy is enabled please either remove the policy or disable it.

3. Restart the Automatic Updates service.

4. Now, from the command line, run the following command:
Configure Proxy  proxycfg.exe –p “WSUS SERVER FQDN”

By doing this, we are configuring WinHTTP so that server access in upper case is also bypassed.

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 to Bypass Proxy server for testing purpose using proxycfg untility. (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 bypass list – “HKEY_LOCAL_MACHINE\ SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Connections\” .

C. I’ve similar problem explained in the technet thread and we had taken network traces and found that internal communication to WSUS server is also going to external proxy (even though that is applicable only for internet communications).

 

At last it turns out to be incorrect proxy settings in a WPAD entry in the DHCP scope (“252 WPAD” Wpad entry). As we are using group policy for proxy setting, WPAD entry in the the DHCP scope is not required. We removed the WPAD setting and the problem got resolved.

Hope this helps !!

Leave a Comment
  • Please add 1 and 4 and type the answer here:
  • Post
Wiki - Revision Comment List(Revision Comment)
Sort by: Published Date | Most Recent | Most Useful
Comments
  • Richard Mueller edited Revision 3. Comment: Changed tag "Core" to "Server Core"

  • Richard Mueller edited Revision 2. Comment: Changed tag "Windows 2008" to "Windows Server 2008", added language tag

  • Ed Price - MSFT edited Revision 1. Comment: Title casing

Page 1 of 1 (3 items)
Wikis - Comment List
Sort by: Published Date | Most Recent | Most Useful
Posting comments is temporarily disabled until 10:00am PST on Saturday, December 14th. Thank you for your patience.
Comments
  • Ed Price - MSFT edited Revision 1. Comment: Title casing

  • Hi, thanks for the article. I've just noticed this issue now with some of my SCCM clients. However, I don't believe that setting a proxy and bypass setting by netsh winhttp on all machines is a proper solution (proxycfg.exe has been deprecated). Is it possible that the WSUS server name in the local policy that SCCM pushes out can simply be set to lower case? Or some other similar simple solution?lowercase o

  • Richard Mueller edited Revision 2. Comment: Changed tag "Windows 2008" to "Windows Server 2008", added language tag

  • Richard Mueller edited Revision 3. Comment: Changed tag "Core" to "Server Core"

Page 1 of 1 (4 items)