Did You Know 2: WSUS Maintenance

While this is actually old news, but the sites I went usually do not update the WSUS option. Especially for those SCCM to download different language windows patches, the private memory pool will be easily hit. 

Bear in mind that WSUS capacity is slightly different from SCCM. Therefore remember to setup this simple maintenance option in your site server: 

Make sure you set at least 8GB and above in KB. 

Information was taken from here: 

http://blogs.technet.com/b/configurationmgr/archive/2015/03/23/configmgr-2012-support-tip-wsus-sync-fails-with-http-503-errors.aspx

http://blog.coretech.dk/kea/house-of-cardsthe-configmgr-software-update-point-and-wsus/

Happy reading!

SY 

Did You Know 1: Software Update Status

Everyday we read software updates report status, but have you ever thought, what does the status really means? Well, few days back a manager came by and ask me a question on the report status and it lead me think of giving "professional' answers that are published in technet: 

State	Description
Required	Specifies that the software update is applicable and required on the client computer. Any of the following conditions could be true when the software update state is Required: ·         The software update was not deployed to the client computer. ·         The software update was installed on the client computer. However, the most recent state message has not yet been inserted into the database on the site server. The client computer rescans for the update after the installation has finished. There might be a delay of up to two minutes before the client sends the updated state to the management point that then forwards the updated state to the site server. ·         The software update was installed on the client computer. However, the software update installation requires a computer restart before the update is completed. ·         The software update was deployed to the client computer but has not yet been installed.
Not Required	Specifies that the software update is not applicable on the client computer. Therefore, the software update is not required.
Installed	Specifies that the software update is applicable on the client computer and that the client computer already has the software update installed.
Unknown	Specifies that the site server has not received a state message from the client computer, typically because one of the following: ·         The client computer did not successfully scan for software updates compliance. ·         The scan finished successfully on the client computer. However, the state message has not yet been processed on the site server, possibly because of a state message backlog. ·         The scan finished successfully on the client computer, but the state message has not been received from the child site. ·         The scan finished successfully on the client computer, but the state message file was corrupted in some way and could not be processed.

Taken from: https://technet.microsoft.com/en-us/library/gg682168.aspx

I hope you find this useful! :) 

Happy reading! 

SY

Log File Investigation Part 6 (Software Update End To End Log Investigation)

I actually enjoy mapping out the process because I feel that apart from giving me a better understanding of the software update process it will help the front end personnel to troubleshoot their patching more effectively.  

I have shared the above logs file mapping with my colleagues and so far they felt that it is easier for them as they know which log file to target at and to analyse. Of course, if you know which log file to read or have your own preference you don't to follow the above chart. 

Don't forget my earlier series as well: 

http://cmxp.blogspot.sg/2015/04/log-file-investigation-part-1.html

http://cmxp.blogspot.sg/2015/04/log-file-investigation-part-2.html

http://cmxp.blogspot.sg/2015/04/log-file-investigation-part-3.html

http://cmxp.blogspot.sg/2015/06/log-file-investigation-part-4.html

http://cmxp.blogspot.sg/2015/08/log-file-investigation-part-5-software.html

Happy investigating! :) 

SY

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