Note For more information about software updates in Microsoft System Center 2012 Configuration Manager, click the following article number to view the article in the Microsoft Knowledge Base:
BackgroundWhen you troubleshoot software update scan failures, you should focus on the WUAHandler.log and WindowsUpdate.log files. Because WUAHandler just reports what the Windows Update Agent reported, the error in the WUAHandler.log file would be the same error that was reported by the Windows Update Agent itself. Therefore, most information about the error will likely be found in the WindowsUpdate.log file. For more information about how to read the WindowsUpdate.log file, click the following article number to view the article in the Microsoft Knowledge Base:
Scan failures that are caused by missing or corrupted componentsErrors 0x80245003, 0x80070514, 0x8DDD0018, 0x80246008, 0x80200013, 0x80004015, 0x800A0046, 0x800A01AD, 0x80070424, 0x800B0100, and 0x80248011 are caused by missing or corrupted components.
Several issues with the software update scan can be caused by missing or corrupted files or registry keys, component registrations, and so on. A good place to start is to run the Windows Update Troubleshooter to detect and fix these issues automatically. You can find the Windows Update Troubleshooter, together with the list of error codes it detects, in the following document:
It's also a good idea to make sure that you're running the latest version of the Windows Update Agent. For information about how to update the Windows Update Agent, click the following article number to view the article in the Microsoft Knowledge Base::
If running the Windows Update Troubleshooter does not fix the problem, reset the Windows Update Agent data store on the client. To reset the Windows Update Agent data store, follow these steps:
- Stop the Windows Update service by running the following command: NET STOP WUAUSERV
- Rename the C:\Windows\SoftwareDistribution folder to C:\Windows\SoftwareDistribution.old.
- Start the Windows Update service by running the following command: NET START WUAUSERV
- Start a software update scan cycle.
Scan failures that are caused by proxy-related issuesErrors 0x80244021, 0x8024401B, 0x80240030, and 0x8024402C are caused by proxy-related issues.
Verify the proxy settings on the client, and make sure that they are configured correctly. The Windows Update Agent uses WinHTTP to scan for available updates. So, when there is a proxy server between the client and the WSUS computer, the proxy settings must be configured correctly on the clients to enable them to communicate with WSUS by using the computer's FQDN.
For proxy issues, WindowsUpdate.log may report errors that resemble the following:
In most cases, you can bypass the proxy for local addresses because as the WSUS computer is located within the intranet anyway. However, if the client is connected to the Internet, you must make sure that the proxy server is configured to enable that communication.
To view WinHTTP proxy settings, run one of the following commands, depending on your operating system:
Windows Vista and later versions: netsh winhttp show proxy
Because proxy settings that are configured in Internet Explorer are part of the WinINET proxy settings, WinHTTP proxy settings aren't necessarily the same as the proxy settings that are configured in Internet Explorer. However, if the proxy settings are set correctly in Internet Explorer, you can import the proxy configuration from Internet Explorer.To import proxy configuration from Internet Explorer, run the following commands, depending on your operating system:
Windows Vista and later versions: netsh winhttp import proxy source =ie
Scan failures that are caused by issues that are related to HTTP time-out or authenticationErrors: 0x80072ee2, 0x8024401C, 0x80244023, or 0x80244017 (HTTP Status 401), 0x80244018 (HTTP Status 403)
Verify connectivity with the WSUS computer. During a scan, the Windows Update Agent has to communicate with the ClientWebService and SimpleAuthWebService virtual directories on the WSUS computer in order to run a scan. If the client can't communicate with the WSUS computer, the scan fails. This can occur for several reasons. These include port configuration, proxy configuration, firewall issues, and network connectivity.
First, we need to find the URL of the WSUS computer. We can do this by checking the following registry key:
Try to access the URL to verify connectivity between the client and the WSUS computer. For example, the URL you use should resemble the following:
Then check whether the client can access the ClientWebService virtual directory. The URL for this should resemble the following:
Finally, check whether the client can access the SimpleAuthWebService virtual directory. The URL to for this test should resemble the following:
If these tests are successful, review the IIS logs on the WSUS computer to confirm that the HTTP errors are being returned from WSUS. If the WSUS computer is not returning the error, the issue is probably with an intermediate firewall or proxy.
If any of these fail, check for name resolution issues on the client. Verify that you can resolve the FQDN of the WSUS computer.
Also, verify the proxy settings on the client to make sure that they are configured correctly. For more information, see the "Scan failures that are due to proxy-related issues" section.
Finally, verify that the WSUS ports can be accessed. WSUS can be configured to use any of the following ports:
Port settings are configured when the software update point site system role is created. These port settings must be the same as the port settings that are used by the WSUS website. Otherwise, WSUS Synchronization Manager will not connect to the WSUS computer that is running on the software update point to request synchronization. The following procedures provide information about how to verify the port settings that are used by WSUS and the software update point.
Determine the WSUS port settings in IIS 6.0.
- On the WSUS server, open Internet Information Services (IIS) Manager.
- Expand Web Sites, right-click the website for the WSUS server, and then click Properties.
- Click the Web Site tab.
- The HTTP port setting is displayed in TCP port, and the HTTPS port setting is displayed in SSL port.
- On the WSUS server, open Internet Information Services (IIS) Manager.
- Expand Sites, right-click the website for the WSUS server, and then click Edit Bindings.
- In the Site Bindings dialog box, the HTTP and HTTPS port values are displayed in the Port column.
Verify and configure ports for the software update point.
- On the Configuration Manager console, browse to Administration pane -> Site Configuration -> Servers and Site System Roles, and then click <SiteSystemName> in the right pane.
- In the bottom pane, right-click Software Update Point and then click Properties.
- On the General tab, specify/verify the WSUS configuration port numbers.
If the port is inaccessible, telnet returns an error that resembles the following. (This error suggests that firewall rules must be configured to enable communication for the WSUS Server ports.)
Scan fails with error 0x80072f0c
Error 0x80072f0c translates to "A certificate is required to complete client authentication." This error should occur only if the WSUS computer is configured to use SSL. As part of the SSL configuration, WSUS virtual directories must be configured to use SSL, and they must be set to ignore client certificates. If the WSUS website or any of the virtual directories that were mentioned previously are configured incorrectly to "Accept" or "Require" client certificates, you receive this error.
When the site is configured in "HTTPS only" mode, the software update point is automatically configured to use SSL. When the site is in "HTTPS or HTTP" mode, you can chose whether to configure the software update point to use SSL. When the software update point is configured to use SSL, the WSUS computer must also be explicitly configured to use SSL. Before you configure SSL, you should review the certificate requirements and make sure that a Server Authentication certificate is installed on the software update point server.
Verify that the software update point is configured for SSL.
- On the Configuration Manager console, browse to Administration -> Site Configuration -> Servers and Site System Roles, and then click <SiteSystemName> in the right pane.
- In the bottom pane, right-click Software Update Point, and then click Properties.
- On the General tab, click Require SSL communication to the WSUS Server.
- Open the WSUS console on the software update point for the site.
- In the console tree pane, click Options.
- In the display pane, click Update Source and Proxy Server.
- Verify that the Use SSL when synchronizing update information option is selected.
- On the WSUS computer, start Internet Information Services (IIS) Manager.
- Expand Sites, right-click Default Web Site or the WSUS administration website if WSUS is configured to use a custom website, and then select Edit Bindings.
- Click the HTTPS entry, and then click Edit.
- In the Edit Site Binding dialog box, select the server authentication certificate, and then click OK.
- In the Edit Site Binding dialog box, click OK, and then click Close.
- Exit IIS Manager.
Configure SSL on the WSUS computer.The following link applies to System Center Configuration Manager 2007. However, you can follow the same steps to configure SSL on WSUS in 2012 Configuration Manager and 2012 R2 Configuration Manager.
How to Configure the WSUS Web Site to Use SSL
Important You cannot configure the whole WSUS website to require SSL, because then all traffic to the WSUS site would have to be encrypted. WSUS encrypts update metadata only. If a computer tries to retrieve update files on the HTTPS port, the transfer will fail.
Group Policy overrides the correct WSUS configuration informationThe Software Updates feature automatically configures a local Group Policy setting for the Configuration Manager client so that it is configured to use the software update point source location and port number. Both the server name and the port number are required for the client to find the software update point.
However, if an Active Directory Group Policy setting is applied to computers for software update point client installation, this overrides the local Group Policy setting. Unless the value of the setting that‘s defined in Group Policy is identical to the one that’s being set by Configuration Manager (server name and port), the Configuration Manager software update scan will fail on the client. In this case, the WUAHandler.log file shows the following:
To resolve this issue, the software update point for client installation and software updates must be specified in the Active Directory Group Policy setting by using the correct name format and port information. For example, this if the software update point was using the default website, the software update point would be http://server1.contoso.com:80.
Other things to checkIf all else fails, check the following things:
- Review the PolicyAgent.log file on the client to verify that the client is receiving policies.
- Verify that software update synchronization is successful on the software update point.
- If the WUAHandler.log file doesn't exist and isn't created after you start a scan cycle, the issue most likely occurs because one of the following isn't available:
- Software update scan policy
- WSUS server location
- Verify that there are no communication errors in the CcmMessaging.log file on the client.
- If the management point returns an empty WSUS location response, there might be a mismatch in the content version of WSUS. In turn, this might be caused by failed synchronization. To find the content version of the software update point, go to Configuration Manager Console > Monitoring pane > Software Update Point Synchronization Status.