Log File Investigation Part 4 (Software Updates Log Reading)

Yes it is been a while since I blogged as I was trying to fix up my VM lab, plus I am doing up several implementation document for SCCM 2012 R2, that is why, I haven't blog since, but I will blog more and share soon as my lab is ready and I have more things to cover :) 

Just in case you miss it, the below were the previous three blogs that I have covered in trouble-shooting in different deployment scenarios (It's two for now, more coming up): 


Log File Investigation Tool (Part 1)

Application Deployment Log Investigation (Part 2) 

Package Deployment Log Investigation (Part 3) 

Today, we are going to spend time on Windows Update deployment, these days, administrators face a enormous task to ensure that the organisation's machines are patched on time. Therefore SCCM 2012 R2 is your best patching companion . 

So the process of getting your computers patch is already a full page topic. But for the benefit of readers I have come up a simple patching flowchart for client machines: 

Because the chart does not account for CAB meetings and approval timeline you should know that the 1 month time frame is just an estimate. 

Next windows update, what log files we should be looking at? 

https://technet.microsoft.com/en-us/library/bb693878.aspx 

Of course you could go through every log file, but let us focus on several logs files that in my opinion will be the fastest way to see the issue the client is having. First the log files to look at: 

WUAHandler.log: Provides information about when the Windows Update Agent on the client searches for software updates.

UpdatesHandler.log: Provides information about software update compliance scanning, and the download and installation of software updates on the client.

Why go through WUAHandler first because it allows you to see the GUID number of the patch that the client machine needs to install. In this log, you will know how the system decide for the client machine what patch to be installed. 

But the main reason is to see the GUID number so that you can trace the UpdatesHandler.log. So here you get to see the GUID number of the software update: 

In this screenshot from my lab machine, you get to see the patch that is required and the GUID number accompanied with it. 

Next UpdatesHandler.log: 

Do a search base on the previous GUID number and you get to find several lines of information in this log, the above log is trying to show case the installation percentage. 

Next after installation it will give a status message, in this screenshot you will see actually it is pending to reboot after the patch has been installed. 

Lastly it will the reboot option for the patch. This is of course determined during your software update deployment. 

Hope it helps. 

Happy Investigating :) 

SY