Get Updates on Microsoft Updates

Downloads
102913.zip

I created a script, WinUpdateCheck.vbs, that you can use to generate a report that details the number of Microsoft updates installed and the date of the most recently installed update for every Windows XP machine on your network. This information can be very useful in identifying machines that have been compromised with malware that prevents the installation of Microsoft updates (e.g., Conficker worm). It also provides a simple way to monitor Microsoft update installations throughout your network.

Here are the steps to get WinUpdateCheck.vbs working in your environment:

  1. Download WinUpdateCheck.vbs by clicking the Download the Code Here button.
  2. Create a text file that lists the name of every Windows XP host on your network. Each host name should be on a separate line.
  3. In the code that Listing 1 shows, modify the PCLIST constant to reflect the directory path and name of the text file created in step 2.
  4. Modify the PATH constant to reflect the directory location of where you want the results to be logged.

Listing 1: Code to Modify in WinUpdateCheck.vbs



WinUpdateCheck.vbs logs the results in a comma-separated value (CSV) file named Update-Log.csv. (If you run the script more than once, the subsequent runs' results are appended to the existing CSV file.) At the end, the script attempts to open the CSV file in Microsoft Excel. If you don't have Excel installed on the machine from which you're running the script, the results will still be logged in the CSV file. The file just won't open at the end of the script's run.

Note that WinUpdateCheck.vbs assumes the machines being inspected have Windows installed in the C:\Windows directory. If your machines have Windows installed in a different location, you'll need to change \$c\Windows to the appropriate directory in the script's UpdateLog subroutine.

WinUpdateCheck.vbs takes roughly 10 minutes per 100 machines to run, so if you have 500 machines it will take about 50 minutes to complete. (It might be slower or faster, depending on your network infrastructure.)

Discuss this Article 4

duncan_priest
on Dec 1, 2009
The code has a bug on the following line: Set objFolder = objFSO.GetFolder("\\" & strComputer & "\c$\Windows") This assumes that windows has been installed into c:\windows (not the case where I'm currently working) - it should instead use the %systemroot% environment variable.
ebraiter
on Dec 1, 2009
Hmmm. If your company uses WSUS [or some of the equivalents], it keeps track of updates that have and have not been installed [and I don't think a worm can trick it]. So this script is unnecessary - unless you want a second opinion.
AnteonCIS
on Dec 10, 2009
You can improve the reliability of the script by replacing: "\c$\Windows" with: "\admin$" in the second line of the "CheckUpdates" subroutine. The Admin$ hidden share is created by Windows (NT 4.0 and newer) during installation and always points to the Windows installation directory, so it will be valid even if Windows is installed in a directory other than C:\Windows. It will also be valid on a Windows 2000 computer where the default installation directory is C:\WinNT.
irowley
on Dec 2, 2009
Hi I ran the script and the csv was created - all PC's came back as "OFF LINE", including my own PC. This was run as domain account that has admin privileges on all the machines. Any ideas? cheers Ian

Please or Register to post comments.

IT/Dev Connections

Las Vegas
September 30th - October 4th

Paul ThurottYou'll have the opportunity to experience:
• The Microsoft
Technology Roadmap
• Office 365 Implementation
• Hyper-V Optimizing
• Windows 8 Deployment
and much more!

Come See Paul Thurrott & Rod Trent in Person!

Early Registration Now Open

Upcoming Training

Mastering System Center 2012

During over 6 hours of training you can join John Savill from your computer as he will walk you through the key components and capabilities of System Center 2012, what’s involved in using the components, and the benefit they can bring to your environment.

Register Now

Current Issue

May 2013 - The NameTranslate object is useful when you need to translate Active Directory object names between different formats, but it's awkward to use from PowerShell. Here's a PowerShell script that eliminates the awkwardness.

CURRENT ISSUE / ARCHIVE / SUBSCRIBE

Windows Forums

Get answers to questions, share tips, and engage with the Windows Community in our Forums.