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:

https://vinitpandey.wordpress.com/2017/03/23/troubleshooting-software-update-using-sccm-2012-part-1/

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.

Once 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.
2. WSUSCtrl.log  (on SUP server) – This log is to verify that SUP is connected to WSUS properly.
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.

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.

https://support.microsoft.com/en-in/help/902093/how-to-read-the-windowsupdate.log-file

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.