Troubleshooting software update using SCCM 2012 – Part 2

Hello friends

I hope this post finds you in good health and spirit. This post is continuation of part 1 of this series where we had discussed the process of software update deployment. If you have not checked it, here is the link:

In this post we will discuss logs and components for deep dive troubleshooting of the software update. I will discuss the process step by step in reference to my earlier post so that the complete workflow of troubleshooting is clear.

SUP setup 

As discussed in part 1, you need to deploy SUP role on WSUS server. To configure SUP, you need to select Create site system server from Servers and site system roles tab in Administration console.

1Once SUP setup is done you should verify that there is no error in the process. These are the logs which need to be checked.

  1. SUPSetup.log  (on SUP server) – This log is to verify installation of SUP server role.1
  2. WSUSCtrl.log  (on SUP server) – This log is to verify that SUP is connected to WSUS properly.1.png
  3. WCM.log  (on site server) – This log provides information about the software update point configuration and connection to the WSUS server for subscribed update categories, classifications, and languages.1

Once SUP setup and WSUS connectivity is successfully verified you may proceed to next step of troubleshooting.

Metadata synchronization 

I have discussed metadata synchronization process in detail in my previous post. WSUS synchronization manager component synchronizes site server from WSUS server. Products, classification and language for which metadata will be synchronized will depend on your selection during SUP installation. You may change it later too. If the process is successful then state message 6702 will be generated. In event of failure state message 6703 will be generated and process will be retried after 60 minutes. You can check wsyncmgr.log for details.


You can also verify synchronization from Software Update Point Syncronisation Status tab under Monitoring.


Client compliance check

Clients scan for their compliance state on schedule as configured at Client Settings at site server.


You can manually initiate policy evaluation at client side too.

At client side, Windows Update Agent (WUA) connects to the WSUS server, retrieves the software update metadata, and initiates the compliance scan. Here is the list of logs you need to check at client side .

1. LocationServices.log – Provides information about the location of the WSUS server when a scan is initiated on the client. So, this log should be checked first .


2. WUAHandler.log  – When the software update scan cycle initiated, WUA will contact WSUS for scanning and if is successful,a state message will be sent to site server confirming that, software update scan is completed successfully. This log has these activity logged.


If there is any error, for further investigation you can check WindowsUpdate.log.

3. WindowsUpdate.log – It provides information about when the Windows Update Agent connects to the WSUS server and retrieves the software updates for compliance assessment and whether there are updates to the agent components. Note that this log needs to be checked only if there is any error in WUAHandler.log. You can check more about WindowsUpdate.log here.

Clients pass their compliance state to SCCM server and you can run various reports to check compliance state.


Software Update deployment

You can deploy software update to client individually but in production you need to do bulk deployment so software update group makes task easier. As actual updates are not downloaded yet and only metadata was downloaded earlier, now you need to download the update and distribute and deploy it from server side. Here is list of logs you need to check at client side for update deployment.

1.UpdatesDeployment.log – It provides information about the deployment on the client, including software update activation, evaluation, and enforcement.


If you need to check maintenance window for update, check ServiceWindowManager.log.

2. RebootCoordinator.log – There are few updates which need restart of system. Information about system restart is in this log.


Additionally you can check UpdatesStore.log and UpdatesHandler.log.

3. UpdateStore.log  – It provides information about the compliance status for the software updates that were assessed during the compliance scan cycle.


4. UpdatesHandler.log It provides information about software update compliance scanning, and the download and installation of software updates on the client.


Wow, so here we complete checking different logs and components required for software updates. Hopefully it will help you 🙂

You may say “yes” atleast for the sake of my efforts. lol.

I will see you all soon with some other technical stuff. Till then take care and happy learning.

Troubleshooting software update using SCCM 2012 – Part 1

Hello friends

I am back after colorful “Holi”. This post is in continuation of my SCCM troubleshooting series. In this two post series we will discuss step by step troubleshooting of update deployment by SCCM.  In this first part we will discuss anatomy of update deployment. For troubleshooting we need to be well versed with background process. I will cover the process in detail here. In next post, I will discuss logs and component based troubleshooting. So here we start.

WSUS is mandatory for software updates via SCCM. You need  WSUS 3.0 SP2 or newer with SUP site system role installed on it. On SCCM server you need to install WSUS administration console. Although you may install WSUS on SCCM site server but in production environment, it need to be installed on separate box. For brevity, in this post I will assume WSUS and site server on different box.

Synchronizing the Software Update Catalog Metadata

The software update process begins at the top-level site (central administration site or standalone primary site). You can configure synchronization settings, by defining products and classification. You can also schedule or manually initiate the synchronization process. Step by step process is defined below.


  1. On schedule or on manual trigger, a component on site server called WSUS Synchronization Manager calls an application  programming interface (API) which requests the  WSUS server to initiate synchronization from Microsoft Update.
  2. WSUS server connects Microsoft Update to download metadata and stores it in its database. On scheduled trigger it will do full download and in event of manual trigger, only delta download is done which is faster.
  3. WSUS Syncronisation Manager keeps on polling WSUS and once it detects metadata download completion at WSUS server, it requests the software update metadata from the WSUS server and inserts it into the Configuration Manager site database.

Once this process is completed you can check updates on site server.

Note: Till now, only metadata is downloaded and not actual updates.

Compliance scan

Once metadata is synchronized at site server, clients will scan their compliance status and send it to site server. Lets discuss this process now.

Software Updates Agent (SUA) at client side is responsible for checking compliance and to deploy updates that are applicable for client. It gets enabled by default due to Default Client Policy.When you install and synchronize a software update point in a site, Configuration
Manager creates a site-wide machine policy that informs client computers that software update metadata is available. The client computers then initiate a scan for compliance with software updates. Step by step process is mentioned below.


  1. On schedule or when you initiate the scan manually, the client receives machine policy from the Management point. Software updates agent submits a request to the management point to find the WSUS server. After the management point provides the WSUS server location, the agent enables the Specify intranet Microsoft update service location local Group Policy setting, and then configures the policy setting with the URL of the server that is running the software update point/WSUS. The machine policy also provides the schedule for scanning and re-evaluation.

Note: AD based GPO will override local GPO setting, so make it sure that you don’t have any WSUS server defined in AD based GPO.

2. Software update agent  gives control to Windows Update Agent which connects to the WSUS server, retrieves the software update metadata, and initiates the compliance scan. The client returns a list that reflects the compliance state for every update evaluated.

3. If configured, WSUS stores the scan results in the WSUS database. This is not enabled by default.

4. The client stores the compliance scan results in Windows Management Instrumentation (WMI), and then sends the results to the management point as state messages, every 15 minutes, by default.

5. The management point sends the results to the site server, which enters them into the site database.

6. You can run reports to check compliance scan results.

Compliance state of client can be in either of 4 states:

  1. Installed
  2. Required
  3. Not required
  4. Unknown

Ok, so now we have checked scanning process so lets start with update deployment process.

Software Updates Deployment Process

Once you deploy software from server side, client will get it on policy evaluation cycle and deployment will start. Step by step process is as under:



  1. You will deploy updates from site server console using Deploy Software Updates Wizard which will create a package for it. There are various settings in this wizard which are self explanatory so I won’t go in that detail.
  2. Remember, the updates are not yet downloaded on site server rather it has only metadata as explained by me earlier. The site server requests the software updates from the download location that you define in the deployment. These updates can come from Microsoft Update or a local source. I will like to emphasize that metadata is downloaded by WSUS while actual update binaries are downloaded by site server.
  3. The site server copies the software update binaries to the content library on the distribution point. The site server adds the new software update deployment to the machine policy.
  4. At the client policy-polling interval, the client retrieves the machine policy from the management point and receives the new deployment information.
  5. When a client receives a policy containing a new update deployment, WUA initiates a software update evaluation scan once again that evaluates all the newly assigned updates for applicability. Client won’t download all the updates rather only those which are applicable for it. If you configure the software update deployment type as Required, the client requests the binaries from the distribution point for each required update, and then stores them in the local cache. If you configure the deployment type as Available, the updates download when the user invokes the installation manually.
  6. The client sends a state message to the management point that reports that the software update was downloaded. The management point forwards the state message to the site server, which then enters the message into the database.
  7. If the deployment has a deadline, clients trigger another update scan by the WUA at
    that defined deadline to ensure that nothing has changed since the last update scan. The client installs the software update, performs another scan on the client to verify that the update is no longer required, and then sends a state message to the management point that indicates the update has been installed. If a restart is necessary, the state message indicates that the client computer is pending a restart. After the restart, a scan begins to verify that the software update is not required and to create a state message which indicate that the update has installed. For each software update that fails to install, an error message is sent to the management point, which forwards the messages to the site server. The site server inserts status messages into the database.

You can run reports at server side for consolidated information.

OK, so that’s it. This is how software update process runs but before I close let’s talk about SUP hierarchy briefly as it often confuses admins.

SUP Hierarchy

SUPs is one role which need to be installed on CAS server if you have one. It should be installed using top to bottom approach i.e. on the CAS first (if you have one),primary sites next, and finally any secondary sites in your hierarchy. You can’t have SUP on child site without one at the parent. SUP at CAS is mandatory. Its recommended to have SUP at each child primary site. Secondary sites do not strictly require a SUP. Placing a SUP at a secondary enables clients in that secondary site’s boundaries to retrieve their update catalog from local SUP saving WAN utilization. SUP placement at a secondary depends upon the network link to the site and the number of clients at that site. If you are unsure, start without the SUP and monitor the bandwidth usage. If the traffic becomes a burden, add a SUP to the secondary site.

Note: Only SUP at top of the hierarchy can synchronize from Microsoft Update. All SUPs at child site will update from parent SUP server.

Here is table for SUP synchronization source.


Picture credit – SCCM unleased book.

In next post, I will discuss troubleshooting flow keeping this process model in reference for easier understanding. Till then take good care of yourself and stay tuned for part 2.