Software Update Management Troubleshooting in Configuration Manager

What does this guide do?

This guide helps you troubleshoot the software update management process in Microsoft System Center Configuration Manager, including client software update scanning, synchronization issues and detection problems with specific updates.

The information in this guide applies to System Center 2012 Configuration Manager (ConfigMgr 2012), System Center 2012 R2 Configuration Manager (ConfigMgr 2012 R2) and all versions of Configuration Manager in the current branch (e.g. Configuration Manager 1511 and Configuration Manager 1602).

Who is it for?

This guide is for IT professionals who need to understand, diagnose and troubleshoot the Software Update Management process in Microsoft System Center Configuration Manager.

How does it work?
It is divided into three main sections:

  • Client Software Update Scanning
  •  WSUS to Microsoft Update synchronization
  • Installation, supersedence, or detection issues with specific updates

This guide assumes that a Software Update Point has already been installed and configured. For more information on configuring Software Updates in Configuration Manager, see the following: 

Configuring Software Updates in Configuration Manager 

Estimated time of completion:

30-45 minutes.

Scope your issue

Before getting into actual troubleshooting steps, it’s important to emphasize that while it may seem obvious, the better you understand the problem you’re experiencing, the quicker and easier it will be for you to fix it. Whether you’re tasked with fixing a problem that you are experiencing yourself, or a problem reported to you by someone in your organization, it is recommended that you take a moment and answer the following questions:

  1. What specifically isn’t working and/or what is your goal? 
  2. What is the frequency or pattern for the issue? Is the problem still happening? 
  3. How did you become aware that the problem exists?
  4. Has this ever worked? If so, when did it stop? Was anything changed in the environment right before it stopped working? 
  5. What percentage of clients are affected?
  6. What has been done already (if anything) to try to fix it? 
  7. Know the exact version of the client and the version of the server. Are these systems up to date? 
  8. What do affected clients have in common (e.g. same subnet, AD site, domain, physical location, site, site system, etc.)?

Knowing and understanding the answers to these questions will put you on the best path for a quick and easy resolution to whatever problem you’re experiencing.

If you know the specific area within the Software Update Management process that you’d like to troubleshoot, select it below. If unsure, start with Client Software Update Scanning and we’ll walk through the entire process from beginning to end.

Scope your issue

Before getting into actual troubleshooting steps, it’s important to emphasize that while it may seem obvious, the better you understand the problem you’re experiencing, the quicker and easier it will be for you to fix it. Whether you’re tasked with fixing a problem that you are experiencing yourself, or a problem reported to you by someone in your organization, it is recommended that you take a moment and answer the following questions:

  1. What specifically isn’t working and/or what is your goal? 
  2. What is the frequency or pattern for the issue? Is the problem still happening? 
  3. How did you become aware that the problem exists?
  4. Has this ever worked? If so, when did it stop? Was anything changed in the environment right before it stopped working? 
  5. What percentage of clients are affected?
  6. What has been done already (if anything) to try to fix it? 
  7. Know the exact version of the client and the version of the server. Are these systems up to date? 
  8. What do affected clients have in common (e.g. same subnet, AD site, domain, physical location, site, site system, etc.)?

Knowing and understanding the answers to these questions will put you on the best path for a quick and easy resolution to whatever problem you’re experiencing.

If you know the specific area within the Software Update Management process that you’d like to troubleshoot, select it below. If unsure, start with Client Software Update Scanning and we’ll walk through the entire process from beginning to end.

Part 1: Client Software Update Scanning

The client scan process is outlined in the following steps. Confirm each step in order to properly establish where the issue is.

The client sends a WSUS Location Request to the management point

The first thing the client does is set the WSUS server that will be its update source for software update scans. That process is detailed below.

  1. When the Configuration Manager client needs to process a software update scan, Scan Agent creates a scan request based on the available policy as noted here:
  2. ScanAgent.log:

    CScanAgent::ScanByUpdates- Policy available for UpdateSourceID={C2D17964-BBDD-4339-B9F3-12D7205B39CC}ContentVersion=38CScanAgent::ScanByUpdates- Added Policy to final ScanRequest List UpdateSourceID={C2D17964-BBDD-4339-B9F3-12D7205B39CC}, Policy-ContentVersion=38, Required-ContentVersion=38 
  3. Scan Agent now sends a WSUS Location Request to Location Services as noted here:
  4. ScanAgent.log:

    Inside CScanAgent::ProcessScanRequest() CScanJobManager::Scan- entered ScanJob({4CD06388-D509-46E4-8C00-75909EDD9EE8}): CScanJob::Initialize- entered ScanJob({4CD06388-D509-46E4-8C00-75909EDD9EE8}): CScanJob::Scan- entered ScanJob({4CD06388-D509-46E4-8C00-75909EDD9EE8}): CScanJob::RequestLocations- entered - - - - - -Requesting WSUS Server Locations from LS for {C2D17964-BBDD-4339-B9F3-12D7205B39CC} version 38 - - - - - -Location Request ID = {C2BB9710-C548-49D0-9DF8-5F9CFC5F3862} CScanAgentCache::PersistInstanceInCache- Persisted Instance CCM_ScanJobInstance ScanJob({4CD06388-D509-46E4-8C00-75909EDD9EE8}): - - - - - -Locations requested for ScanJobID={4CD06388-D509-46E4-8C0075909EDD9EE8} (LocationRequestID={C2BB9710-C548-49D0-9DF8-5F9CFC5F3862}), will process the scan request once locations are available. 

    TIP Each scan job is stored in WMI in the CCM_ScanJobInstance class:

    Namespace: root\CCM\ScanAgent Class: CCM_ScanJobInstance

  5. Location Services creates a Location Request and sends it to the management point. The package ID for a WSUS location request is the Update Source Unique ID.
  6. LocationServices.log:

    LocationServices.log: CCCMWSUSLocation::GetLocationsAsyncEx Attempting to persist WSUS location request for ContentID='{C2D17964-BBDD-4339-B9F3-12D7205B39CC}' and ContentVersion='38' Persisted WSUS location request LocationServices Attempting to send WSUS Location Request for ContentID='{C2D17964-BBDD-4339-B9F3-12D7205B39CC}' WSUSLocationRequest : <WSUSLocationRequest SchemaVersion="1.00"><Content ID="{C2D17964-BBDD-4339-B9F312D7205B39CC}" Version="38"/><AssignedSite SiteCode="PS1"/><ClientLocationInfo OnInternet="0"><ADSite Name="CM12-R2PS1"/><Forest Name="CONTOSO.COM"/><Domain Name="CONTOSO.COM"/><IPAddresses><IPAddress SubnetAddress="192.168.2.0" Address="192.168.2.62"/></IPAddresses></ClientLocationInfo></WSUSLocationRequest> Created and Sent Location Request '{C2BB9710-C548-49D0-9DF8-5F9CFC5F3862}' for package {C2D17964-BBDD-4339-B9F312D7205B39CC}   
  7. CCM Messaging sends the location request message to the management point:
  8. CcmMessaging.log:

    CcmMessaging.log: Sending async message '{76453CC6-76BA-4B68-BE30-BA70754570BB}' to outgoing queue 'mp:[http]mp_locationmanager'  Sending outgoing message '{76453CC6-76BA-4B68-BE30-BA70754570BB}'. Flags 0x200, sender account empty 
  9. The management point parses this request and calls the MP_GetWSUSServerLocations stored procedure to get the WSUS locations from the database:
  10. MP_Location.log:

    MP LM: Message Body : <WSUSLocationRequest SchemaVersion="1.00"><Content ID="{C2D17964-BBDD-4339-B9F312D7205B39CC}" Version="38"/><AssignedSite SiteCode="PS1"/><ClientLocationInfo OnInternet="0"><ADSite Name="CM12-R2PS1"/><Forest Name="CONTOSO.COM"/><Domain Name="CONTOSO.COM"/><IPAddresses><IPAddress SubnetAddress="192.168.2.0" Address="192.168.2.62"/></IPAddresses></ClientLocationInfo></WSUSLocationRequest>  MP_LocationManager MP LM: calling MP_GetWSUSServerLocations

    SQL Profiler:

    exec MP_GetMPSitesFromAssignedSite N'PS1' exec MP_GetSiteInfoUnified N'<ClientLocationInfo OnInternet="0"><ADSite Name="CM12-R2-PS1"/><Forest Name="CONTOSO.COM"/><Domain Name="CONTOSO.COM"/><IPAddresses><IPAddress SubnetAddress="192.168.2.0" Address="192.168.2.62"/></IPAddresses></ClientLocationInfo>' exec MP_GetWSUSServerLocations N'{C2D17964-BBDD-4339-B9F3-12D7205B39CC}',N'38',N'PS1',N'PS1',N'0',N'CONTOSO.COM'  


  11. After getting the results from the stored procedure, the management point sends a response to the client:
  12. MP_Location.log: 

    MP LM: Reply message body: <WSUSLocationReply SchemaVersion="1.00"><Sites><Site><MPSite SiteCode="PS1"/><LocationRecords><LocationRecord WSUSURL="http://PS1SITE.CONTOSO.COM:8530" ServerName="PS1SITE.CONTOSO.COM" Version="38"/><LocationRecord WSUSURL="https://PS1SYS.CONTOSO.COM:8531" ServerName="PS1SYS.CONTOSO.COM" Version="38"/></LocationRecords></Site></Sites></WSUSLocationReply>  


  13. CCM Messaging receives the response and sends it back to Location Services:
  14. CcmMessaging.log:

    Message '{76453CC6-76BA-4B68-BE30-BA70754570BB}' got reply '{8E6D05EF-B77F-4AD0-AF64-1C6F3069A29C}' to local endpoint queue 'LS_ReplyLocations' OutgoingMessage(Queue='mp_[http]mp_locationmanager', ID={76453CC6-76BA-4B68-BE30-BA70754570BB}): Delivered successfully to host 'PS1SYS.CONTOSO.COM'. Message '{8E6D05EF-B77F-4AD0-AF64-1C6F3069A29C}' delivered to endpoint 'LS_ReplyLocations'  


  15. Location Services parses the response and sends the location back to Scan Agent:
  16. LocationServices.log:

    Processing Location reply message LocationServices WSUSLocationReply : <WSUSLocationReply SchemaVersion="1.00"><Sites><Site><MPSite SiteCode="PS1"/><LocationRecords><LocationRecord WSUSURL="http://PS1SITE.CONTOSO.COM:8530" ServerName="PS1SITE.CONTOSO.COM" Version="38"/><LocationRecord WSUSURL="https://PS1SYS.CONTOSO.COM:8531" ServerName="PS1SYS.CONTOSO.COM" Version="38"/></LocationRecords></Site></Sites></WSUSLocationReply> Calling back with the following WSUS locations WSUS Path='http://PS1SITE.CONTOSO.COM:8530', Server='PS1SITE.CONTOSO.COM', Version='38'  WSUS Path='https://PS1SYS.CONTOSO.COM:8531', Server='PS1SYS.CONTOSO.COM', Version='38'  Calling back with locations for WSUS request {C2BB9710-C548-49D0-9DF8-5F9CFC5F3862}  


  17. Scan Agent now has the policy and the update source location with the appropriate content version.
  18. ScanAgent.log:

    *****WSUSLocationUpdate received for location request guid={C2BB9710-C548-49D0-9DF8-5F9CFC5F3862} ScanJob({4CD06388-D509-46E4-8C00-75909EDD9EE8}): CScanJob::OnLocationUpdate- Received Location=http://PS1SITE.CONTOSO.COM:8530, Version=38  ScanJob({4CD06388-D509-46E4-8C00-75909EDD9EE8}): CScanJob::Execute- Adding UpdateSource={C2D17964-BBDD-4339-B9F312D7205B39CC}, ContentType=2, ContentLocation=http://PS1SITE.CONTOSO.COM:8530, ContentVersion=38  


  19. Scan Agent notifies WUAHandler to add the update source. WUAHandler adds the update source to the registry and initiates a Group Policy refresh (if the client is in domain) to see whether Group Policy overrides the update server that we just added. 
  20. WUAHandler.log (*New Client showing new Update Source being added): 
    Its a WSUS Update Source type ({C2D17964-BBDD-4339-B9F3-12D7205B39CC}), adding it Its a completely new WSUS Update Source Enabling WUA Managed server policy to use server: http://PS1SITE.CONTOSO.COM:8530  Policy refresh forced Waiting for 2 mins for Group Policy to notify of WUA policy changeWaiting for 30 secs for policy to take effect on WU Agent.  Added Update Source ({C2D17964-BBDD-4339-B9F3-12D7205B39CC}) of content type: 2  


    During this time, the Windows Update Agent sees a WSUS configuration change:

    WindowsUpdate.log :

    * WSUS server: http://PS1SITE.CONTOSO.COM:8530 (Changed) * WSUS status server: http://PS1SITE.CONTOSO.COM:8530 (Changed)  Sus server changed through policy.  

    The following registry keys are checked and set:

    • HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate\AUUseWUServer (this should be a Dword value of 1)
    • HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate WUServer (This should be a string value that is the full WSUS server URL including the port)
    • WUStatusServer (This should be a string value that is the full WSUS server URL including the port) 


    Example:

    Key Name: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate

    Value Name: WUServer

    Type: REG_SZ

    Data: http://PS1Site.Contoso.com:8530


    Value Name: WUStatusServer

    Type: REG_SZ

    Data: http://PS1Site.Contoso.com:8530


    Key Name: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate\AU

    Value Name: UseWUServer

    Type: REG_DWORD

    Data: 0x1


    NOTE: For an existing client, we could expect to see the following in WUAHandler.log to denote when content version has incremented:

    Its a WSUS Update Source type ({C2D17964-BBDD-4339-B9F3-12D7205B39CC}), adding it.  WSUS update source already exists, it has increased version to 38.  

  21. After the updatesource is successfully added, Scan Agent raises a State Message and initiatesthe scan:
  22. ScanAgent.log:

    ScanJob({4CD06388-D509-46E4-8C00-75909EDD9EE8}): Raised UpdateSource ({C2D17964-BBDD-4339-B9F3-12D7205B39CC}) state message successfully. StateId = 2 ScanJob({4CD06388-D509-46E4-8C00-75909EDD9EE8}): CScanJob::Execute - successfully requested Scan, ScanType=1

Troubleshooting

 Log Symptoms  What to Check
 ScanAgent.log shows no policy available for an Update Source and no WUAHandler.log exists or no current activity within WUAHandler.log  Check the Enable software updates on clients setting. For more information, see the following TechNet document:
About Client Settings in Configuration Manager
 ScanAgent/LocationServices receive no WSUS server location  Is a Software Update Point (SUP) role installed for the site? If not, install and configure a Software Update Point and monitor SUPSetup.log for progress. See the following for more information:
Install and Configure a Software Update Point
If a SUP role is installed, is it configured and synchronizing? Check WCM.log, WSUSCtrl.log and WSyncMgr.log for errors.
select * from WSUSServerLocations
select * from Update_SyncStatus

 Client receives the WSUS location but fails to configure the WSUS registry keys  Did group policy refresh respond within the 2 minute timeout per WUAHandler.log? If so, does WUAHandler denote "Group policy settings were overwritten by a higher authority (Domain Controller)"? Check for a GPO being set within the domain.




Scan agent requests the scan and WUAHandler initiates the scan

Once the client has identified and set the WSUS server that will be its update source for software update scans, Scan Agent then requests the scan from WUAHandler which uses the Windows Update Agent API to request a Software Update Scan from the Windows Update Agent. A scan may result from a scheduled or manual software update scan, from a scheduled or manual software updated deployment re-evaluation, or from a deployment that becomes active which triggers an evaluation.

ScanAgent.log:

ScanJob({4CD06388-D509-46E4-8C00-75909EDD9EE8}): CScanJob::Execute - successfully requested Scan, ScanType=1   

WUAHandler.log:

Scan results will include superseded updates only when they are superseded by service packs and definition updates.

Search Criteria is (DeploymentAction=* AND Type='Software') OR (DeploymentAction=* AND Type='Driver') Running single-call scan of updates. Async searching of updates using WUAgent started. 

TIP Review WUAHandler.log after a software update scan to see if any new entries occur. If no new entries occur, this can indicate that we have no SUP being returned by the Management Point.

Troubleshooting

A number of issues with Software Update scan can be caused by missing or corrupted files or registry keys, or by component registration issues. These are fixable through the Windows Update Troubleshooter, updating the Windows Update Agent or resetting Windows Update Agent data store:

The Windows Update Troubleshooter:

2714434 - Description of the Windows Update Troubleshooter (http://support.microsoft.com/kb/2714434)

Updating the Windows Update Agent:

949104 - How to update the Windows Update Agent to the latest version (http://support.microsoft.com/kb/949104)

If the client is running an older version of the Windows Update Agent, be aware that there was a known issue where a 32-bit Windows 7 ConfigMgr 2012 R2 client requesting an update scan fails to return scan results to Configuration Manager. This causes the client to report incorrect compliance status and the updates fail to install when Configuration Manager requests the update cycle. However, if you use the Windows Update control panel applet, the updates will usually install just fine. If you are experiencing this problem you should notice a message similar to the following in WindowsUpdate.log:

WARNING: ISusInternal::GetUpdateMetadata2 failed, hr=8007000E  

At its core this is a memory allocation issue, thus 64-bit Windows 7 computers will not see this error since their address space is effectively unlimited. They will, however, exhibit high memory and high CPU utilization, possibly affecting performance. Note that x86 clients will also exhibit high memory usage (usually around 1.2 to 1.4gb).

For more information on this particular problem, please see the following article:

Support Tip: ConfigMgr 2012 update scan fails and causes incorrect compliance status

Fortunately, there’s a hotfix for this issue here:

3050265 - Windows Update Client for Windows 7: June 2015 (https://support.microsoft.com/en-us/kb/3050265)

Resetting the Windows Update Agent data store:

To reset the Windows Update Agent data store, follow these steps:

  1. Stop the Windows Update service by running net stop wuauserv from a Command Prompt.
  2. Rename the C:\Windows\SoftwareDistribution folder to C:\Windows\SoftwareDistribution.old.
  3. Start the Windows Update service by running net start wuauserv from a Command Prompt.
  4. Initiate a Software Update scan cycle.

Summary

To summarize, when troubleshooting scan failures, the logs you should look at are WUAHandler.log and WindowsUpdate.log. Because WUAHandler simply reports what Windows Update Agent reported, the error in WUAHandler would be the same error that was reported by the Windows Update Agent itself, therefore more information about the error could be found in WindowsUpdate.log. To understand how to read WindowsUpdate.log, see the following KB article:

902093 - How to read the Windowsupdate.log file (https://support.microsoft.com/en-us/kb/902093)

Your best source of information will come from the logs and the error codes they contain. As a reference, you can find the complete list of Windows Update error codes here:

938205 - Windows Update error code list (http://support.microsoft.com/kb/938205)


Windows Update Agent (WUA) starts the scan against the WSUS computer

Once requested, Windows Update Agent (WUA) starts the scan against its configured WSUS server.

Windows Update Agent starts a scan after receiving a request from the Configuration Manager client (CcmExec). If these registry values are correctly set to a WSUS computer that is a valid SUP for the site via local policy, you should see a COM API search request from the Configuration Manager client (ClientId = CcmExec) as follows:

WindowsUpdate.log:

COMAPI -- START --  COMAPI: Search [ClientId = CcmExec]COMAPI <<-- SUBMITTED -- COMAPI: Search [ClientId = CcmExec]   PT   + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL =  http://PS1.CONTOSO.COM:8530/ClientWebService/client.asmxAgent ** START **  Agent: Finding updates [CallerId = CcmExec]Agent   * Include potentially superseded updates  Agent   * Online = Yes; Ignore download priority = Yes  Agent   * Criteria = "(DeploymentAction=* AND Type='Software') OR (DeploymentAction=* AND Type='Driver')"  Agent   * ServiceID = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7} Managed Agent   * Search Scope = {Machine}  

WindowsUpdate.log:

PT   + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://PS1.CONTOSO.COM:8530/ClientWebService/client.asmx  Agent   * Added update {4AE85C00-0EAA-4BE0-B81B-DBD7053D5FAE}.104 to search result Agent   * Added update {57260DFE-227C-45E3-9FFC-2FC77A67F95A}.104 to search result  Agent   * Found 163 updates and 70 categories in search; evaluated appl. rules of 622 out of 1150 deployed entities  Agent **  END  **  Agent: Finding updates [CallerId = CcmExec]  COMAPI >>--  RESUMED  -- COMAPI: Search [ClientId = CcmExec]COMAPI   - Updates found = 163  COMAPI --  END  --  COMAPI: Search [ClientId = CcmExec] 

Troubleshooting

During a scan, the Windows Update Agent needs to communicate with the ClientWebService and SimpleAuthWebService virtual directories on the WSUS computer in order to perform a scan. If the client cannot communicate with the WSUS computer, the scan will fail. This can happen for a number of reasons, including

  • Proxy related issues
  • HTTP timeout errors
  • Authentication errors
  • Certificate problems

We will cover each of these below.

Proxy related issues

The Windows Update Agent uses WinHTTP to scan for available updates. When there is a proxy server between the client and the WSUS computer, the proxy settings must be configured properly on the clients to allow them to communicate with WSUS using the FQDN. In the case of proxy issues, WindowsUpdate.log may report errors that resemble the following: 

0x80244021 or HTTP Error 502 - Bad gateway0x8024401B or HTTP Error 407 - Proxy Authentication Required0x80240030 - The format of the proxy list was invalid0x8024402C - The proxy server or target server name cannot be resolved

In most cases, you can bypass the proxy for local addresses since the WSUS computer is probably located within the intranet anyway. However, if the client is on the Internet, you must make sure that the proxy server is configured to allow that communication. You can run the following commands to view the WinHTTP proxy settings:

  • On Windows XP: proxycfg.exe
  • On Windows Vista or above: netsh winhttp show proxy

Although proxy settings configured in Internet Explorer are part of the WinINET proxy settings, WinHTTP proxy settings are not necessarily the same as the proxy settings configured in Internet Explorer. However, if the proxy settings are set correctly in Internet Explorer, you can import the proxy configuration from IE to use as the WinHTTP proxy settings. To import proxy configuration from Internet Explorer, run the following command: 

  • On Windows XP: proxycfg.exe -u
  • On Windows Vista and above: netsh winhttp import proxy source =ie

For more information see the following:

900935 - How the Windows Update client determines which proxy server to use to connect to the Windows Update Web site

934864 - Microsoft DNS and WINS use for WPAD registration

DNS and DHCP Support for Web Proxy and Firewall Client Autodiscovery: https://technet.microsoft.com/en-us/library/cc302584.aspx

HTTP Timeout Errors

To troubleshoot HTTP timeout errors, first review the IIS logs on the WSUS computer to confirm that the errors are actually being returned from WSUS. If the WSUS computer is not returning the error, the issue is likely with an intermediate firewall or proxy.

If the WSUS computer is returning the error, verify connectivity with the WSUS computer. Here are the steps:

  1. Make sure the client is using the right URL

  2. To confirm that the client is connecting to the correct WSUS server, find the URL of the WSUS computer used by the Windows Update Agent client. This can be found by checking the HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate registry key or by viewing the WindowsUpdate.log file.

    Common reasons that the WSUS assignment may be incorrect include Group Policy conflicts or the addition of a SUP to a secondary site after initial client installation.

    NOTE Active Directory Group Policy may override the local WSUS policy


    The Software Updates feature automatically configures a local Group Policy setting for the Configuration Manager client so that it is configured with the Software Update Point source location and port number. Both the server name and port number are required for the client to find the Software Update Point.


    If an Active Directory Group Policy setting is applied to computers for Software Update Point client installation, this overrides the local Group Policy setting. Because of this, if the value of the setting that‘s defined in the AD Group Policy is different from the one that’s being set by Configuration Manager , the scan will fail on the client because it cannot locate the correct WSUS computer. In this case WUAHandler.log will show the following: 

    Group policy settings were overwritten by a higher authority (Domain Controller) to: Server http://server and Policy ENABLED 

    The Software Update Point for client installation and software updates must be the same server and must be specified in the Active Directory Group Policy setting with the correct name format and port information. For example, this would be http://server1.contoso.com:80 if the Software Update Point was using the default website.

  3. Test the URL
  4. Assuming the server URL is correct, access the server using a URL similar to the following to verify connectivity between the client and the WSUS computer:

    http://SUPSERVER.CONTOSO.COM:8530/Selfupdate/wuident.cab

    To check whetherthe client can access the ClientWebService virtual directory, try accessing aURL similar to this:

    http://SUPSERVER.CONTOSO.COM:8530/ClientWebService/wusserverversion.xml

    To check whether the client can access the SimpleAuthWebService, , try accessing a URL similar to this:

    http://SUPSERVER.CONTOSO.COM:8530/SimpleAuthWebService/SimpleAuth.asmx

    If any of these fail, some of the possible reasons include:

    • Name resolution issues on the client. Verify that you can resolve the FQDN of the WSUS computer.
    • Proxy configuration issues. See step 1 above.
    • Other network-related connectivity issues.
    • Port configuration problems (see below).
    • IIS availability problems.

    Failures here could be caused by port configuration issues, so it’s a good idea to verify that the port settings are correct. WSUS can be configured to use any of the following ports: 80, 443 or 8530, 8531.

    For clients to communicate with the WSUS computer, the appropriate ports must be allowed on the firewall on the WSUS computer. 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 used by the WSUS website or WSUS Synchronization Manager will fail to connect to WSUS running on the Software Update Point to request synchronization. The following procedures provide information about how to verify the port settings used by WSUS and the Software Update Point.

    Determine the WSUS port settings used in IIS 7.0 and above

    1. On the WSUS computer, open Internet Information Services (IIS) Manager.
    2. Expand Sites, right-click the website for the WSUS computer and then click Edit Bindings.
    3. In the Site Bindings dialog box, the HTTP and HTTPS port values are displayed in the Port column.

    Determine the WSUS port settings in IIS 6.0

    1. On the WSUS server, open Internet Information Services (IIS) Manager.
    2. Expand Web Sites, right-click the website for the WSUS computer, then click Properties.
    3. Click the Web Site tab. The HTTP port setting is displayed in TCP port and the HTTPS port setting is displayed in SSL port

    Configure ports for the Software Update Point

    1. In the Configuration Manager console, navigate to the Administration pane -> Site Configuration -> Servers and Site System Roles, then click on on the <SiteSystemName> right-hand pane.
    2. In the bottom pane, right-click Software Update Point and then click Properties.
    3. Go to the General tab and specify/verify the WSUS configuration port numbers.

    Verify port connectivity

    To check port connectivity from the client, run the following command:

    telnet SUPSERVER.CONTOSO.COM

    For example, if our port was 8530 we would use the following command:

    telnet SUPSERVER.CONTOSO.COM 8530

    If the port is not accessible, telnet will return an error that resembles the following:

    Could not open connection to the host, on port <PortNumber>


    This error suggests that the firewall rules are not configured to allow communication for the WSUS computer. Note that this error can also suggest that an intermediate network device is blocking that port. To verify, try the same test from a client on the same local subnet. If this works then that would suggest that the computers are configured correctly, however a router or firewall between segments is blocking the port and causing the failure.

Authentication Errors

This is typically indicated when the scan fails with authentication errors 0x80244017 (HTTP Status 401) or 0x80244018 (HTTP Status 403)

First, confirm the correct WinHTTP proxy settings using the following commands:

  • On Windows Vista or above: netsh winhttp show proxy
  • On Windows XP: proxycfg.exe

Assuming the proxy settings are correct, verify connectivity with the WSUS computer by completing the steps in HTTP Timeout Errors above. Also 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 likely with an intermediate firewall or proxy.

Certificate Problems

Certificate problems are usually indicated by error code 0x80072F0C which means “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 be set to “Ignore” client certificates. If the WSUS website or any of those virtual directories are incorrectly configured to “Accept” or “Require” client certificates, you will receive this error.

Follow these steps to troubleshoot errors related to certificate problems:

Verify that the Software Update Point is configured for SSL

  1. In the Configuration Manager console, navigate to the Administration pane -> Site Configuration -> Servers and Site System Roles, then click <SiteSystemName> in the right-hand pane.
  2. In the bottom pane, right-click Software Update Point and then click Properties.
  3. On the General tab, click Require SSL communication to the WSUS Server.

Verify that the WSUS computer is configured for SSL

  1. Open the WSUS console on the Software Update Point for the site.
  2. Click Options in the console tree pane.
  3. Click Update Source and Proxy Server in the display pane.
  4. Verify that Use SSL when synchronizing update information is selected.

Verify that the Server Authentication certificate is added to the WSUS Administration website

To add the Server Authentication certificate to the WSUS Administration website, complete the following:

  1. On the WSUS computer, open Internet Information Services (IIS) Manager.
  2. Expand Sites, right-click Default Web Site, or WSUS Administration website if WSUS is configured to use a custom website, and then select Edit Bindings.
  3. Click the HTTPS entry and then click Edit. .
  4. In the Edit Site Binding dialog box, select the Server Authentication certificate and then click OK.
  5. Click OK in the Edit Site Binding dialog box and then click Close.
  6. Close Internet Information Services (IIS) Manager.

IMPORTANT Make sure that the FQDN specified in the Site System properties matches the FQDN specified in the certificate. If the Software Update Point accepts connections from the intranet only, the Subject Name or Subject Alternative Name must contain the intranet FQDN. When the Software Update Point accepts client connections from the Internet only, the certificate must still contain both the Internet FQDN and the intranet FQDN because WCM and WSyncMgr still use the intranet FQDN to connect to the Software Update Point. If the Software Update Point accepts connections from both the Internet and the intranet, both the Internet FQDN and the intranet FQDN must be specified by using the ampersand (&) symbol delimiter between the two names.

Verify that SSL is configured on the WSUS computer

The following link applies to System Center Configuration Manager 2007, however the same steps can be used to configure SSL on WSUS in Configuration Manager 2012:

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.

WUAHandler receives results from Windows Update Agent and marks the scan as complete

WUAHandler receives the results from the Windows Update Agent and marks the scan as complete.

WUAHandler.log:

Async searching completed. Finished searching for everything in single call.  

Troubleshooting

Problems here should be addressed the same way as scan failures in the previous step.

As mentioned previously in this guide, when troubleshooting scan failures, the logs you should look at are WUAHandler.log and WindowsUpdate.log. Because WUAHandler simply reports what Windows Update Agent reported, the error in WUAHandler would be the same error that was reported by the Windows Update Agent itself, therefore more information about the error could be found in WindowsUpdate.log. To understand how to read WindowsUpdate.log, see the following KB article:

902093 - How to read the Windowsupdate.log file

Generally speaking, there are many reasons why a Software Update scan might fail. It could be due to one of the issues mentioned above, or it could simply come down to a communication or firewall issue between the client and the Software Update Point computer. Your best source of information will come from the logs and the error codes they contain. As a reference, you can find the complete list of Windows Update error codes here:

938205 - Windows Update error code list

WUAHandler parses the scan results

WUAHandler then parses the results, which includes the applicability state for each update. As part of this process, superseded updates are pruned out. Additionally, the applicability state is checked for all updates that align to the criteria submitted by CCMExec to the Windows Update Agent. The important thing to understand here is that you should see applicability results for updates whether those updates are in a deployment or not.

WUAHandler.log:

Pruning: update id (70f4f236-0248-4e84-b472-292913576fa1) is superseded by (726b7201-862a-4fde-9b12-f36b38323a6f). …Update (Installed): Security Update for Windows 7 for x64-based Systems (KB2584146) (4ae85c00-0eaa-4be0-b81b-dbd7053d5fae, 104)  Update (Missing): Security Update for Windows 7 for x64-based Systems (KB2862152) (505fda07-b4f3-45fb-83d9-8642554e2773, 200) …Successfully completed scan. 

Troubleshooting

Problems here should be addressed the same way as scan failures in the previous step.

As mentioned previously in this guide, when troubleshooting scan failures, the logs you should look at are WUAHandler.log and WindowsUpdate.log. Because WUAHandler simply reports what Windows Update Agent reported, the error in WUAHandler would be the same error that was reported by the Windows Update Agent itself, therefore more information about the error could be found in WindowsUpdate.log. To understand how to read WindowsUpdate.log, see the following KB article:

902093 - How to read the Windowsupdate.log file

Generally speaking, there are many reasons why a Software Update scan might fail. It could be due to one of the issues mentioned above, or it could simply come down to a communication or firewall issue between the client and the Software Update Point computer. Your best source of information will come from the logs and the error codes they contain. As a reference, you can find the complete list of Windows Update error codes here:

938205 - Windows Update error code list



Update Store records the status and raises a state message for each update in WMI

Update Store records the status and raises a State Message for each update in WMI.

Once the scan results are available, these results are stored in the Updates Store. Update Store records the current state of each update and creates a State Message for each update. These State Messages are forwarded to the Site Server in bulk at the end of the Status Message Reporting cycle (which is minutes, by default). Please note that we only send a State Message under the following circumstances:

  • A previous State Message has never been sent for an update (log entry: hasn't been reported before, creating new instance)
  • The applicability state for an update has changed since the last state message was submitted

UpdateStore.log showing state for Missing Update (KB2862152) being recorded and a State Message being raised:

Processing update status from update (505fda07-b4f3-45fb-83d9-8642554e2773) with ProductID = 0fa1201d-4330-4fa8-8ae9b877473b6441 Update status from update (505fda07-b4f3-45fb-83d9-8642554e2773) hasn't been reported before, creating new instance. Successfully raised state message for update (505fda07-b4f3-45fb-83d9-8642554e2773) with state (Missing).  Successfully added WMI instance of update status (505fda07-b4f3-45fb-83d9-8642554e2773). 

StateMessage.log showing state messaged being recorded with State ID 2 (missing):

Adding message with TopicType 500 and TopicId 505fda07-b4f3-45fb-83d9-8642554e2773 to WMI State message(State ID : 2) with TopicType 500 and TopicId 505fda07-b4f3-45fb-83d9-8642554e2773 has been recorded for SYSTEM 

TIP For each update, an instance of the CCM_UpdateStatus class is created or updated, and this stores the current status of the update. The CCM_UpdateStatus class is located in the ROOT\CCM\SoftwareUpdates\UpdatesStore namespace.

Troubleshooting

Problems here should be addressed the same way as scan failures in the previous step.

As mentioned previously in this guide, when troubleshooting scan failures, the logs you should look at are WUAHandler.log and WindowsUpdate.log. Because WUAHandler simply reports what Windows Update Agent reported, the error in WUAHandler would be the same error that was reported by the Windows Update Agent itself, therefore more information about the error could be found in WindowsUpdate.log. To understand how to read WindowsUpdate.log, see the following KB article:

902093 - How to read the Windowsupdate.log file

Generally speaking, there are many reasons why a Software Update scan might fail. It could be due to one of the issues mentioned above, or it could simply come down to a communication or firewall issue between the client and the Software Update Point computer. Your best source of information will come from the logs and the error codes they contain. As a reference, you can find the complete list of Windows Update error codes here:

938205 - Windows Update error code list


State messages are sent to the management point

When WUAHandler successfully receives the results from the Windows Update Agent, it marks the scan as complete and logs the following:

WUAHandler.log:

Async searching completed. WUAHandler Finished searching for everything in single call

Troubleshooting

Problems here should be addressed the same way as scan failures in the previous step, although failures at this stage will likely be surfaced in the WindowsUpdate.log file specifically. To understand how to read WindowsUpdate.log, see the following KB article:

902093 - How to read the Windowsupdate.log file

Generally speaking, there are many reasons why a Software Update scan might fail. It could be due to one of the issues mentioned above, or it could simply come down to a communication or firewall issue between the client and the Software Update Point computer. Your best source of information will come from the logs and the error codes they contain. As a reference, you can find the complete list of Windows Update error codes here:

938205 - Windows Update error code list


Part 2: WSUS to Microsoft Update synchronization

WSUS synchronizing with Microsoft Update is outlined in the following steps. Confirm each step in order to properly establish where the issue is.

Synchronization starts via scheduled or manual request

When a synchronization is triggered, we expect to see the following within the WSUS server's SoftwareDistribution.log:

MANUAL:

Changew3wp.6AdminDataAccess.StartSubscriptionManuallySynchronization manually started Info WsusService.27EventLogEventReporter.ReportEventEventId=382,Type=Information,Category=Synchronization,Message=A manual synchronization was started. 

SCHEDULED:

InfoWsusService.10EventLogEventReporter.ReportEventEventId=381,Type=Information,Category=Synchronization,Message=A scheduled synchronization was started. 

Troubleshooting

Manual Sync

  1. Confirm that theWSUS service is running.  If you see thata manual synchronization has started but it stays at 0%, this is usually due tothe WSUS service ("Update Services" on WSUS 3.x; "WSUSService" on Windows Server 2012+) being in a stopped state.
  2. Reset the WSUS Console MMC cache by completing the following:

    1. Close the WSUS console
    2. Stop the WSUS service ("Update Services" on WSUS 3.x; "WSUS Service" on Windows Server 2012+)
    3. Browse to %appdata%\Microsoft\mmc
    4. Rename "wsus" to "wsus_bak"
    5. Start the WSUS service
    6. Open the WSUS Console and try another manual synchronization

Scheduled Sync

  1. Try a manual synchronization from within the WSUS console.
  2. If a manual synchronization works fine, check the scheduled synchronization settings.

WSUS spawns a connection to Microsoft Update (MU)

After a synchronization starts, the WSUS server attempts to make an HTTP connection via WinHTTP. Consider the following factors when troubleshooting the connection:

WSUS <=winhttp=> network entities <=> Internet

Does a network entity (proxy, firewall, security filter, etc.) exist between the WSUS host machine and the Internet?

If a proxy exists and the WSUS server is required to use the proxy, is the proxy configured within the proper WSUS settings?

Troubleshooting

Manual Sync

  1. Confirm that the WSUS service is running. If you see that a manual synchronization has started but it stays at 0%, this is usually due to the WSUS service ("Update Services" on WSUS 3.x; "WSUS Service" on Windows Server 2012+) being in a stopped state.
  2. Reset the WSUS Console MMC cache by completing the following:
    1. Close the WSUS console
    2. Stop the WSUS service ("Update Services" on WSUS 3.x; "WSUS Service" on Windows Server 2012+)
    3. Browse to %appdata%\Microsoft\mmc
    4. Rename "wsus" to "wsus_bak"
    5. Start the WSUS service
    6. Open the WSUS Console and try another manual synchronization

Scheduled Sync

  1. Try a manual synchronization from within the WSUS console
  2. If a manual synchronization works fine, check the scheduled synchronization settings.
The WSUS computer receives product and classification information from MU and any subscribed metadata

Once WSUS receives product and classification information and any subscribed metadata from Microsoft Update, the WSUS synchronization is complete.

Installation, supersedence, or detection issues w/ specific updates

Deployment issues that occur with specific updates can be broken into the areas below. When you begin troubleshooting, consider the following components associated with these areas.

 Areas -> Installation Supersedence Detection
  Components ->  WUA
Update Installer (CBS, MSI)
CCMExec
Update Metadata  WUA
Update Metadata
Update Installer (CBS, MSI)  


Installation Issues

What is the installer (CBS, MSI, other)?

CBS (Component Based Servicing):

For updates that apply to the Windows operating system (Windows Vista to current), CBS is used to handle the installation.

  1. 1.Gather the CBS log (%Windir%\Logs\Cbs\Cbs.log) and perform an initial review gain insight into the cause of the failure. Troubleshooting installation based issues via CBS logs is beyond the scope of this troubleshooter, however the following Knowledge Base article may help:947821 - Fix Windows corruption errors by using the DISM or System Update Readiness tool
  2. Does the update install successfully as a logged on user? If it does install successfully as a logged on user, does it only fail when installed under the System context? If so, focus on troubleshooting the manual installation failure under the System context. 
MSI (Windows Installer):
For non-Windows software updates, MSI is used to handle the installation.
  1. Gather and review the default MSI logs for the update. Check the associated KB article for the update for any known issues/FAQ .
  2. Extend Windows Installer logging and reproduce the failure. See the following Knowledge Base article for more information:
    223300 - How to enable Windows Installer logging
    When reviewing the resulting logs, check for return value 3 within the log and the lines preceding that entry for insight into the failure.

  3. Check whether the same update fails to install manually under the local system context using the same installation switches that failed during the software update deployment. If this fails, test the installation as the logged on user with the same installation switches to understand if this is an issue with installing under local system. If this works, you can then focus the issue on how to properly install the update using the local system context. This may require checking for administrative deployment guidance within the KB for the update or online.
Supersedence Issues

Attempt to isolate the issue that relates to supersedence by using the following questions:

  1. For questions about how to control when Configuration Manager expires an update, review the "Supersedence Rules" section here: https://technet.microsoft.com/en-us/library/gg712312.aspx
  2. If an update has been expired by Configuration Manager, Microsoft recommends that the latest superseding update be deployed. If you still need to deploy the expired updates, these can be deployed outside a software update deployment via software distribution/application management.
  3. For questions related specifically to the supersedence logic of an update, first review the KB article for the update for further information. You can also review supersedence within the Microsoft Update Catalog, WSUS console, or the Configuration Manager console.
Detection Issues

Determine Compliance State Per Update on a Client

  1. Review the update KB article for known issues with the update.
  2. Run the "Software Updates Scan Cycle" action on the Configuration Manager client.
  3. Review UpdatesStore.log and WindowsUpdate.log.

Troubleshooting Update Applicability

  1. Check if any prerequisites are missing using the KB article for the update. For instance, does the update require the application or OS being patched to be at a specific service pack level?
  2. Confirm that the Unique Update ID of the update in question matches what is deployed. For instance, is the update in question an x86 update but being targeted to an x64 host?
Successful

Congratulation!Your Software Update Management process issue has been resolved.

Additional info

For additional information regarding how to configure software updates in Configuration Manager, please see the following:

You can also post a question in our Configuration Manager 2012 support forum for security, updates and compliance here:

https://social.technet.microsoft.com/Forums/en-US/home?forum=configmanagersecurity

Visit our blog for all the latest news, information and tech tips on Microsoft System Center Configuration Manager:

https://blogs.technet.microsoft.com/configurationmgr

Właściwości

Identyfikator artykułu: 10680 — ostatni przegląd: 16.03.2016 — zmiana: 16

Opinia