Expert Solution for 2011 Scripting Games Beginner Event 6: Parse the Windows Update Log for Errors with PowerShell

Expert Solution for 2011 Scripting Games Beginner Event 6: Parse the Windows Update Log for Errors with PowerShell

  • Comments 7
  • Likes

Summary: Microsoft MVP, Sean Kearney, uses Windows PowerShell to solve 2011 Scripting Games Beginner Event 6 and parse the Windows update log for errors.

Microsoft Scripting Guy, Ed Wilson, here. Today we have Sean Kearney to provide his solution for Beginner Event 6.

Photo of Sean Kearney

Sean Kearney is an infrastructure support analyst and Microsoft MVP in Window PowerShell. He is absolutely passionate about automation technologies—especially Windows PowerShell. If you say, “Powershell,” he may just break into song. Sean considers himself “just a tech at heart,” but he can often be found dabbling with most Microsoft technologies at a moment’s notice. We have also been advised to keep him at arm’s length from any open Starbucks in Seattle. We have been advised that any rumors about him ever singing for Microsoft JobsBlog are completely unfounded. Complete rubbish. Let us just keep it between you and me, OK?

Sean's contact information:
Twitter: EnergizedTech
Blog: Energized About Technology
Website: Powershell: Releasing the Power of Shell to You

Worked solution

----------------------------------- Update of Terror Begin -------------------------------

Yes. One of those days. Not just any day, but “THOSE DAYS.” Yep that kind.

I needed to get our workstations updated to deal with a new Security hotfix. All was beautiful. It fit in with the applications. The test rollouts were great. It was all fine until the call…

“Ring…Ring…”

I glance down. Peering up at me with a disdainful look is my phone. The Boss is calling. I cautiously pick it up.

“Hello, a problem with that update. The CIO is having an issue. It’s not updating on his machine. You know what this means.”

Yep. I knew. Ignore everything else on my plate, including a dead server, to fix this ONE machine. 

I immediately pop over to grab his laptop, and I bump into him.

“I’ll be back in 60 minutes after lunch. I’m confident you’ll have this fixed…or else,” he winks at me.

I hate when he winks like that.  He might be kidding or not. I would like to avoid the “NOT.”

I do quick search online and find out everything in the Windows Update process is logged as Success or Fail in a nice little text log called (oddly enough) WindowsUpdate.log. It is right inside my Windows folder.

Big choice. Do I spend 60 minutes reading through a log file? Or do I try to find a quick way to parse for errors? I’ve looked at this log once before, and I noticed that bad lines were usually tagged with the word FATAL or WARNING.

This looks like a job for Windows POWERSHELL!

Our first task. Read that file. A simple Get-Content Cmdlet will do that.

Get-Content C:\Windows\WindowsUpdate.Log

But darn it. I need to filter out all the stuff I do not need. Fortunately, I know in Windows PowerShell each line of text is an object that I can compare. I can simply compare and see if an object in the pipeline contains the data with a Where-Object cmdlet and add a Like to see if anything is “like” this in the line. I pop some * about the characters to ignore Where it is in the line. Every little bit helps in this situation. A quick and dirty solution will meet my needs to find the answer now.

Get-Content C:\Windows\WindowsUpdate.Log | Where-Object { $_–like ‘*FATAL*’ –or $_ -like ‘*WARNING*’}

Ahhh, much nicer. But I realized I didn’t have my twelfth cup of coffee, so then I miss all the stuff. I am just not as fast as I should be with that PAUSE key. I wish I could pipe this into More to get screenfuls at a time…

Oh right. I can…

Get-Content C:\Windows\WindowsUpdate.Log | Where-Object { $_–like ‘*FATAL*’ –or $_ -like ‘*WARNING*’} | MORE

With the logs parsing and showing me the real problem where the errors in the logs were, I was able to identify our update failure. With a quick search on BING through TechNet, I nailed the minor update needed and got him on his way.

The CIO thanked me later that day for a job well done. Bought me lunch too. I smiled. I never did let him know about my secret weapon: Windows POWERSHELL!

----------------------------------- Update of Terror End ---------------------------------

Thank you, Sean.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • <p>I would suggest to never work with fixed paths, as you never can expect them to be the same on all computers. It is rumoured there are some folks that do not have Windows installed on the C: volume...</p> <p>The more universal approach would be: Get-Content $env:windir\WindowsUpdate.log ...</p>

  • <p>Or even better use $env:systemroot as $env:windir is more &quot;legacy&quot; like...</p>

  • <p>Shorter:</p> <p>select-string -path $env:SystemRoot\WindowsUpdate.log FATAL</p>

  • <p>I completely agree there are better solutions. &nbsp; &nbsp;That is the beauty of Powershell that I COULD find a better way of doing this in the long term. &nbsp;</p> <p>Also take note of the context as well. &nbsp;&quot;The boss is breathing down your neck...&quot;</p> <p>Often in those scenarios you find you use what works first (Direct Access to the file thinking down the pipeline) and worry about cleaning it up later. In the field there are short term and long term solutions. &nbsp; </p> <p>When you&#39;re patching something on the fly, sometimes you use a quick bandaid (Like the solution above) and then rethink the solution long term (Like what Martin suggested).</p> <p>Sean</p>

  • <p>Dear Sean,</p> <p>a great story that could happen everywhere exactly like this! I know it!!</p> <p>But: Even this one liner may have to be commented :-)</p> <p>1. Beginner event 6 doesn&#39;t want us, to search &quot;Warning&quot;s </p> <p>2. BitByter is right! I would have said the same</p> <p>3. Martin is right! &nbsp; I would ...</p> <p>Besides that: The solution should be short and so I will NOT argue that there is NO error handling *sss*</p> <p>One last point: </p> <p>If you use &quot;Select-String&quot; like Martin did, the performance will be great!</p> <p>&quot;Get-Content&quot; runs on my computer for nearly a second and &quot;Select-String&quot; does the job in less than the tenth of the time!</p> <p>The reason might be, that &quot;Get-Content&quot; is passing each line down the pipeline to be processed by the next pipeline step,</p> <p>whereas &quot;Select-String&quot; will filter the content and only return the matching lines!</p> <p>This is not a point that we should take care of for BE6, but generally you should keep this in mind when you have to do similar tasks!</p> <p>kind regards, Klaus</p>

  • <p>&quot;| more&quot;. &nbsp;I&#39;ll have to remember that one. &nbsp;</p>

  • <p>It&#39;s nice to see that any kind of useful Windows CLI is coming along, still doesn&#39;t hold a candle to:</p> <p>cat WindowsUpdate.log | grep &quot;FATAL\|WARNING&quot; | less</p> <p>on the Linux side.</p>