MBSACLI 2.0 /xmlout Parsing Script
Andrew Aronoff
option and parses the XML output file to produce a readable text file.
The script can be downloaded here:
http://www.silentrunners.org/MBSACLI%20XML%20Parser.vbs
The MD5 hash is: E2EE397BC540EC23D901018EC033890E
This hash applies to the initial release, R00. The release number will
always be found on line 15 of the script.
The script is free, but is provided with no warranty, expressed or
implied. It changes settings in the registry (and is designed to reset
the registry to the initial settings before it's done) and requires
Internet connectivity (so that it can retrieve hotfix datafiles from
Microsoft). You use this script at your own risk!
Please note:
1. The script must be located in the same directory as MBSACLI.EXE and
WUSSCAN.DLL. (It will display an error message if it isn't.)
2. The output text file will be placed in the same directory as the
script. The title root is "Hotfix Check Results.txt".
3. The script can be run with a single command line parameter that
will be appended to the output file name. If "Workstation 999" is the
command line parameter, the output text file title would be "Hotfix
Check Results Workstation 999.txt".
4. The script can only be run under Windows 2000 and Windows XP, since
earlier OS's are incompatible with MBSACLI 2.0. Running under an
earlier OS will display an error message.
5. The script must be run under an Administrator account. Running
under a non-admin account will display an error message.
6. The script will only report uninstalled hotfixes. The report format
is:
Sequence number. Hotfix title
Security bulletin number, Knowledge Base article number, update type,
update severity.
(Optional) restart-pending notice.
Security Bulletin URL
Download URL
A typical entry might be:
#. Some alarmiing hotfix title here
MS00-000 KB123456, Security Update, Maximum Severity: Critical
Security Bulletin URL: http://www.microsoft.com/.../MS00-000.mspx
Download URL: http://ridiculously_long_filename_here.exe
7. Microsoft Update Agent 2.0 is required for MBSACLI 2.0. Once it's
installed, the script does not require the Automatic Updates service
to be started. The script will enable the service if it's disabled and
start it up. It will restore the original service status before it
exits.
8. The script is written for use on workgroup PC's. Revisions are
welcome so that it can be used in a domain.
9. The script will hang if MBSACLI.EXE cannot download its .CAB file.
If someone has a suggestion to avoid this, please let me know.
10. If the script throws an error, please let me know and I'll fix the
bug.
11. If you have an XML parsing suggestion, please let me know and I'll
improve the script.
12. If you need customization assistance to get the script to work
your way in your shop, make me an offer. ;-)
13. MS will, of course, provide their own scripts. I have no idea what
their scripts will do.
regards, Andy
--
**********
Please send e-mail to: usenet (dot) post (at) aaronoff (dot) com
To identify everything that starts up with Windows, download
"Silent Runners.vbs" at www.silentrunners.org
**********
Rob Wickham [msft]
for something like this.
Slightly OT: Does anyone have existing scripts that can generate a list of
computer names or individual IP addresses when given either a domain name as
input or an IP range as input? I suspect there are such scripts being used
with the MBSA 1.2.1 batchscan.js samples, but I'd like to confirm this with
anyone who's done it already.
--
Rob Wickham [msft]
This posting is provided "as is" with no warranties, and confers no rights.
"Andrew Aronoff" <NOSPAM_WRO...@yahoo.com> wrote in message
news:lutoc1hmhs2lib90n...@4ax.com...
SixDoubleO
Thanks for the script. I am in the middle of writing something similar,
although I use kix. But I will take a look at your script.
One question, though. How do I deploy Window Update Agent to all my
workstations? I'm certain that not all of them have it.
PS - Is it just me, or is this newest MBSA a complete step in the wrong
direction?
Nelson Araujo [MSFT], CISSP, MCAD
To deploy Windows Update Agent on your computers just scan them with MBSA
2.0, with the option to Configure computers enabled. But please make sure
you have the requirements to remotely scan MBSA on the target computer (like
firewall settings) before doing that as MBSA will not be able to penetrate
XP firewall (or 3rd party vendors).
Let me know if I can help more.
--
Regards,
Nelson Araujo, CISSP, MCAD
Software Development Engineer
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.
"SixDoubleO" <SixDo...@discussions.microsoft.com> wrote in message
news:C930F401-1D9E-4A40...@microsoft.com...
Andrew Aronoff
When you run my script on a workstation that doesn't have Windows
Update Agent 2.0, MBSACLI.EXE will fail to download the .CAB file, the
script will detect a tiny .XML file and it will offer to send the
default browser to the Update Agent 2.0 download location. That's one
way to get it.
The other way is to download it here:
http://go.microsoft.com/fwlink/?LinkId=43264
and use your preferred method of rolling out a hotfix.
>Is it just me, or is this newest MBSA a complete step in the wrong
>direction?
That makes two of us.
Rob Wickham [msft]
concerns? Is it the fact that there is now a client-side component required
for update scanning, or something else?
--
Rob Wickham [msft]
This posting is provided "as is" with no warranties, and confers no rights.
"Andrew Aronoff" <NOSPAM_WRO...@yahoo.com> wrote in message
news:85hrc195l2r177uav...@4ax.com...
SixDoubleO
To get full functionality from the mbsacli.exe utility, it must be
physically installed on the workstation.
The new tool seems to focus around an administrator running it
manually/interactively, directed at a large number of workstations. This is
not how I do things. Everything I do is lights-out and occurs at the
workstation. In my particular environment, I have about 1400 workstations
that I cannot necessarily guarantee will be turned on or even AT the office
at a specified time. So my strategy is to scan (and update) these machines
right at logon....it's the one time I get a "captive audience" so to speak.
So the Gui/reporting/console type functions are of no use to me.
The new tools relies on the WUA component and MSI 3.1. So I have to deploy
these components to the workstation before I can even scan it. I don't like
this.
It just seemed that HFNetChk/MBSA 1.2 was better suited to scripted
environments as it had no dependencies on other components. All I had to do
was make the hfnetchk.exe and mssecure.xml files available in my netlogon
share, and away we went. I could parse the output of hfnetchk and fire off
all needed updates automatically.
On the bright side, I think the XML output will open up many more
capabilities for me (although I agree with others that the use of the "Update
Required=true/false" attribute is a very silly implementation).
Like I said above, the tools seems geared toward interactive/manual scanning
and not scheduled/scripted implementations. Granted, many of us scripters
have completely circumvented the need for costly SMS systems, and maybe
therein lies the problem?
Nonetheless, those are some of my concerns. I appreciate you taking the
time to hear them.
Rob Wickham [msft]
using the next-generation scanning of WSUS. The bonus is that a WSUS server
or connection to Microsoft Update is not required, and we've kept in the /HF
scenario of not needing to fully install the MBSA setup package just to scan
for updates. The ability to extend detection for new products without the
need to change the detection engine on the client was also a significant
point of interest for our users. Next we needed to deliver a new scanning
engine that can go all the way back to Windows 2000 SP3, and still use a
common, public client API and backend catalog of detection logic was a
challenge.
We think it was the best tradeoff we could make however, and we made MBSA
2.0 very flexible about how to deploy key components like WUA.
Historically, it takes about 8 months to ship new detection engines in MBSA
and we no longer have to wait that long based on the capabilities of WUA. A
newly shipped Microsoft product can have a security update hosted by
Microsoft Update with no changes to the scanning engine on the client, or in
MBSA 2.0. Being able to respond quickly like this is good.
Finally, even older versions of MBSA required components like remote
registry and file sharing, so although there are new components of Windows
required short-term, long term these will simply be a part of the OS without
the need for out of band deployment and ongoing management.
The RestartRequired='true' | 'false' attribute is interesting because it
tells you that the update only needs the computer to be rebooted in order to
provide the intended security protection. Without this, the installation
package would probably be run over and over until the reboot happened and
you can integrate this added level of detail into your scripts and same some
cycles on the client computers.
If you have more questions about the xml attributes, please don't hesitate
to ask.
--
Rob Wickham [msft]
This posting is provided "as is" with no warranties, and confers no rights.
"SixDoubleO" <SixDo...@discussions.microsoft.com> wrote in message
news:7433B208-B821-453E...@microsoft.com...
Mike Chan [MSFT]
the agent upgrade that MBSA attempts it not specific to MBSA. It is a
required upgrade of a windows component (for AU, WU, MU, WSUS, MBSA, etc)...
so MBSA is only delivering something that will be included in future updates
and service packs as well. This was the only way we could deliver consistent
scanning between all our tools.
also, if you have the latest agents on the clients, you should be able to
script around mbsacli.exe, wusscan.dll and wsusscan.cab without a full
install simliar to what you have been doing before.
--
Mike Chan
Technical Product Manager (MBSA)
Security Business and Technology Unit
Microsoft Corporation
"Rob Wickham [msft]" <rwic...@microsoft.com> wrote in message
news:erLS$m$gFHA...@TK2MSFTNGP14.phx.gbl...
Torgeir Bakken (MVP)
> I have written a VBS script that runs MBSACLI 2.0 with the /xmlout
> option and parses the XML output file to produce a readable text file.
>
> The script can be downloaded here:
> http://www.silentrunners.org/MBSACLI%20XML%20Parser.vbs
> (snip)
Hi,
Further down in this post is another mbsacli.exe /xmlout parse script
(that I have written).
Some comment first:
In the thread "MBSACLI 2.0 XML tags", you wrote:
"BTW, I noticed that when Windows Update Agent 2.0 is not installed,
nothing is added to the XML file. That's too bad."
The reason for this is that the error messages from mbsacli.exe goes
to StdErr, while you only redirect StdOut (where all the "normal"
output goes to.
To redirect StdErr to a separate file, use " 2>SomeFile", here is a
snippet from the full script below:
'--------------------8<----------------------
' As the ShortPath property have been used for all paths, extra
' quotes are not needed
sCmd = "%comspec% /c " & sMBSAFilePath & " " & sMBSACmdSwitches _
& " >" & sXMLFilePath & " 2>" & sStdErrFilePath
'--------------------8<----------------------
One small issue here is that mbsacli adds header information to this
error file even when no errors have arised, so you will need to skip
the first 4 lines in that file. See the use of the function CheckStdErr
below for how I have handled this.
Also, I have used Microsoft's XML DOM (MSXML2.DOMDocument) to parse
the XML file.
Here is the full script:
'--------------------8<----------------------
Option Explicit
' Script that parses the output from MBSA 2.0's mbsacli.exe
' (using the /xmlout switch). Any errors in the StdErr is
' also picked up.
'
' Script is reporting both installed and missing updates. See
' the comments for the sXPath variable on how to change it to
' report only on installed or missing updates.
'
' Author: Torgeir Bakken
' Date: 2005-07-11
Const OverwriteIfExist = -1
Const OpenAsASCII = 0
Dim sReportFile, sXMLFilePath, sXPath, oXMLDoc, oErr, oFSO, oShell
Dim sMsgBoxTitle, sStdErr, sStdErrFilePath, sMBSAFilePath
Dim sCabFilePath, sMBSACmdSwitches, sCmd
' ------- Section with variables you can/must change -------
' Path and name of status text file to be created
' Environment variables allowed
sReportFile = "%tmp%\UpdateStatus.txt"
' Path and name of mbsacli.exe, environment variables allowed
sMBSAFilePath = "C:\mbsa2\mbsacli.exe"
' Path and name of wsusscan.cab, environment variables allowed.
' Note that microsoft does not support placement on a network drive.
' Set it to "" if you do not want to use the /catalog switch
' If this string is not empty (""), /catalog <cab file path> will
' be added to the command line of mbsacli.exe
sCabFilePath = "C:\mbsa2\wsusscan.cab"
' Command line switches to be used for mbsacli.exe
' Using /xmlout to run in updates only mode using only mbsacli.exe
' and wusscan.dll. Only these switches can be used with this option:
' /catalog, /wa, /wi, /nvc, /unicode
sMBSACmdSwitches = "/xmlout /nvc"
sXPath = "//UpdateData"
' To list only installed updates, use this one instead:
'sXPath = "//UpdateData[@IsInstalled='true']"
' To list only missing updates, use this one instead:
'sXPath = "//UpdateData[@IsInstalled='false']"
' Title to be used by MsgBox commands
sMsgBoxTitle = "MBSA Update Check"
' ------- Section that prepares for running mbsacli.exe -------
Set oShell = CreateObject("WScript.Shell")
Set oFSO = CreateObject("Scripting.FileSystemObject")
sMBSAFilePath = oShell.ExpandEnvironmentStrings(sMBSAFilePath)
If oFSO.FileExists(sMBSAFilePath) Then
sMBSAFilePath = oFSO.GetFile(sMBSAFilePath).ShortPath
Else
MsgBox sMBSAFilePath & " does not exist!", _
vbCritical + vbSystemModal, sMsgBoxTitle
WScript.Quit
End If
If sCabFilePath <> "" Then
sCabFilePath = oShell.ExpandEnvironmentStrings(sCabFilePath)
If oFSO.FileExists(sCabFilePath) Then
sCabFilePath = oFSO.GetFile(sCabFilePath).ShortPath
sMBSACmdSwitches = sMBSACmdSwitches & " /catalog " & sCabFilePath
Else
MsgBox sCabFilePath & " does not exist!", _
vbCritical + vbSystemModal, sMsgBoxTitle
WScript.Quit
End If
End If
' Get a temporary file name for xml file MbsaCli.exe creates
Do
sXMLFilePath = oFSO.GetSpecialFolder(2).ShortPath _
& "\" & oFSO.GetTempName
Loop While oFSO.FileExists(sXMLFilePath)
' Get a temporary file name for the stderr file MbsaCli.exe creates
Do
sStdErrFilePath = oFSO.GetSpecialFolder(2).ShortPath _
& "\" & oFSO.GetTempName
Loop While oFSO.FileExists(sStdErrFilePath)
' As the ShortPath property have been used for all paths, extra
' quotes are not needed
sCmd = "%comspec% /c " & sMBSAFilePath & " " & sMBSACmdSwitches _
& " >" & sXMLFilePath & " 2>" & sStdErrFilePath
' ------- Section that runs mbsacli.exe and checks the result -------
oShell.Run sCmd, 0, True
sStdErr = CheckStdErr(sStdErrFilePath)
On Error Resume Next
oFSO.DeleteFile sStdErrFilePath
On Error Goto 0
If sStdErr <> "" Then
MsgBox "MBSA failed, error was:" & vbNewLine & vbNewLine & sStdErr, _
vbCritical + vbSystemModal, sMsgBoxTitle
On Error Resume Next
oFSO.DeleteFile sXMLFilePath
On Error Goto 0
WScript.Quit
End If
' ------- Section that parses the output in the xml file -------
Set oXMLDoc = CreateObject("MSXML2.DOMDocument")
oXMLDoc.SetProperty "SelectionLanguage", "XPath"
oXMLDoc.Async = False
oXMLDoc.Load sXMLFilePath
If (oXMLDoc.parseError.errorCode <> 0) Then
Set oErr = oXMLDoc.ParseError
MsgBox "Could not load file " & sXMLFilePath _
& " , error: " & oErr.Reason, _
vbCritical + vbSystemModal, sMsgBoxTitle
WScript.Quit
End If
Dim dicElements, oNodes, oElement
Dim sGUID, sKBID, sBulletinID, iType, iSeverity, bRestartRequired
Dim bIsInstalled, sTitle, sBulletinURL, sInformationURL, sDownloadURL
Dim sType, sSeverity
' use a dictionary object to filter out double entries (will
' exist e.g. for WSUS scans).
Set dicElements = CreateObject("Scripting.Dictionary")
dicElements.CompareMode = vbTextCompare
Set oNodes = oXMLDoc.DocumentElement.SelectNodes(sXPath)
On Error Resume Next
For Each oElement in oNodes
sGUID = "" ' init value
sGUID = oElement.getAttribute("GUID")
If Not dicElements.Exists(sGUID) Then
' init values
sKBID = "": sBulletinID = "": iType = "": iSeverity = ""
bIsInstalled = "": bRestartRequired = "": sTitle = ""
sBulletinURL = "": sInformationURL = "": sDownloadURL = ""
sType = "": sSeverity = ""
sKBID = oElement.getAttribute("KBID")
sBulletinID = oElement.getAttribute("BulletinID")
iType = CInt(oElement.getAttribute("Type"))
Select Case iType
Case 1
sType = "Security Update"
Case 2
sType = "Service Pack"
Case 3
sType = "Update Rollup"
End Select
iSeverity = CInt(oElement.getAttribute("Severity"))
Select Case iSeverity
Case 0
sSeverity = "(no rating)"
Case 1
sSeverity = "Low"
Case 2
sSeverity = "Moderate"
Case 3
sSeverity = "Important"
Case 4
sSeverity = "Critical"
End Select
bIsInstalled = CBool(oElement.getAttribute("IsInstalled"))
bRestartRequired = CBool(oElement.getAttribute("RestartRequired"))
sTitle = oElement.selectSingleNode("Title").text
sBulletinURL = oElement.selectSingleNode _
("References/BulletinURL").text
sInformationURL = oElement.selectSingleNode _
("References/InformationURL").text
sDownloadURL = oElement.selectSingleNode _
("References/DownloadURL").text
' using the GUID value as dictionary key
dicElements.Add sGUID, _
Array( _
sKBID, _
sBulletinID, _
sType, _
sSeverity, _
bIsInstalled, _
bRestartRequired, _
sTitle, _
sBulletinURL, _
sInformationURL, _
sDownloadURL)
End If
Next
oFSO.DeleteFile sXMLFilePath
On Error Goto 0
' ------- Section that creates the report file -------
If dicElements.Count = 0 Then
WScript.Echo "No updates found"
Else
Dim f
Set f = oFSO.CreateTextFile( _
oShell.ExpandEnvironmentStrings(sReportFile), _
OverwriteIfExist, OpenAsASCII)
f.WriteLine "Report on update status run at " & Now
f.WriteLine "---------------------------------" _
& "---------------------------------"
f.WriteLine
f.WriteLine "Total number of update entries found: " _
& dicElements.Count
f.WriteLine "---------------------------------" _
& "---------------------------------"
f.WriteLine
f.WriteLine "Installed updates:" & vbNewLine
ListElements (True)
f.WriteLine "---------------------------------" _
& "---------------------------------"
f.WriteLine
f.WriteLine "Missing updates:" & vbNewLine
ListElements (False)
f.Close
oShell.Run "notepad.exe " & """" & sReportFile & """", 1, False
End If
' Start functions and subs
Function CheckStdErr(ByVal sFile)
Const OpenAsASCII = 0
Const FailIfNotExist = 0
Const ForReading = 1
Dim oFSO, fFile, i, sValue, sLine
Set oFSO = CreateObject("Scripting.FileSystemObject")
If oFSO.GetFile(sFile).Size = 0 Then
CheckStdErr = "Something is wrong, StdErr file size is 0 byte!"
Exit Function ' ----->
End If
Set fFile = oFSO.OpenTextFile(sFile, ForReading, _
FailIfNotExist, OpenAsASCII)
' Skip first 4 lines that always just contains the same header info
For i = 1 To 4
fFile.SkipLine
Next
sValue = "" ' init value
'Parse the rest of the text file
Do While Not fFile.AtEndOfStream
sLine = fFile.Readline
If sLine <> "" Then
If sValue = "" Then
sValue = sLine
Else
sValue = sValue & vbNewLine & sLine
End If
End If
Loop
fFile.Close
CheckStdErr = sValue
End Function
Sub ListElements(ByVal bInstallStatus)
Dim sDicElement
For Each sDicElement In dicElements
If dicElements.Item(sDicElement)(4) = bInstallStatus Then
f.WriteLine "KB ID: " & dicElements.Item(sDicElement)(0)
f.WriteLine "Bulletin ID: " & dicElements.Item(sDicElement)(1)
f.WriteLine "Type: " & dicElements.Item(sDicElement)(2)
f.WriteLine "Severity: " & dicElements.Item(sDicElement)(3)
If bInstallStatus Then
f.WriteLine "Restart Required: " _
& dicElements.Item(sDicElement)(5)
End If
f.WriteLine "Title: " & dicElements.Item(sDicElement)(6)
f.WriteLine "Bulletin URL: " & dicElements.Item(sDicElement)(7)
f.WriteLine "Information URL: " & dicElements.Item(sDicElement)(8)
f.WriteLine "Download URL: " & dicElements.Item(sDicElement)(9)
f.WriteLine
End If
Next
End Sub
'--------------------8<----------------------
--
torgeir, Microsoft MVP Scripting and WMI, Porsgrunn Norway
Administration scripting examples and an ONLINE version of
the 1328 page Scripting Guide:
http://www.microsoft.com/technet/scriptcenter/default.mspx
Rob Wickham [msft]
results of the scanning went to STDOUT, so that you would not need to do
things like skip the first 4 lines of the STDERR case. Just redirect to
STDOUT and parse XML.
Cases such as WUA not being installed should appear in the STDOUT case
inside the "<Advice>" attribute where check ID = 10500, even though they
also go to STDERR without the XML formatting.
--
Rob Wickham [msft]
This posting is provided "as is" with no warranties, and confers no rights.
"Torgeir Bakken (MVP)" <Torgeir.B...@hydro.com> wrote in message
news:edBIeKjh...@TK2MSFTNGP10.phx.gbl...
Torgeir Bakken (MVP)
> We made specific tests during development to ensure that the
> actual XML results of the scanning went to STDOUT, so that you
> would not need to do things like skip the first 4 lines of the
> STDERR case. Just redirect to STDOUT and parse XML.
>
> Cases such as WUA not being installed should appear in the STDOUT
> case inside the "<Advice>" attribute where check ID = 10500, even
> though they also go to STDERR without the XML formatting.
Hi,
Problem is, it doesn't end up in StdOut, so something must have
happened between development and release ;-)
Some examples on error situations when running mbsacli.exe /xmlout
and what StdOut and StdErr gives:
1)
With the /catalog switch pointing to a non-existing catalog file:
Content of StdErr:
Error: Cannot open file C:\wsusscan.cab
In this case, StdOut creates a 0 byte file (mbsacli.exe returns
errorlevel 1 though).
2)
With the Automatic Updates service disabled:
Content of StdErr:
Cannot communicate with Windows Update Agent service on target computer.
Content of StdOut:
<XMLOut>
</XMLOut>
3)
With old version of WUA installed (original WinXP SP1):
Content of StdErr:
Windows Update Agent not found, or the computer is not running Windows
2000 SP3 or later.
Content of StdOut:
<XMLOut>
</XMLOut>
So as I see it, the only sure way to pick up all error situations (and
it's messages) is to parse StdErr.
Torgeir Bakken (MVP)
> (snip)
> If you have more questions about the xml attributes, please
> don't hesitate to ask.
Hi,
I would like to see more documentation on the "Check ID" and it's
associated attributes (Grade/Type/Cat/Rank).
And a specific question for those:
When running Mbsacli.exe /xmlout on a computer that is connected
to a WSUS server, I get two different sections in the xml file:
Check ID="500" Grade="5" Type="5" Cat="1" Rank="1" Name="Windows
Security Updates"
and
Check ID="500" Grade="2" Type="5" Cat="1" Rank="1" Name="Windows
Security Updates"
where the Grade="5" version lists the WSUS related patches, while it
looks like the Grade="2" version lists all updates related to all
relevant updates found in wsusscan.cab (available at Windows Updates).
So am I correct to say that Check ID="500"/Grade="5" is WSUS relevant
updates, and Check ID="500"/Grade="2" is standard AU/WU relevant
updates?
Rob Wickham [msft]
What you'd see for the case of there being an update visible to MU or
wsusscan.cab, BUT NOT visible on the WSUS server (because it's not approved
yet) is Grade=8.
--
Rob Wickham [msft]
This posting is provided "as is" with no warranties, and confers no rights.
"Torgeir Bakken (MVP)" <Torgeir.B...@hydro.com> wrote in message
news:ulvWKHvh...@TK2MSFTNGP12.phx.gbl...
Rob Wickham [msft]
you have been seeing now, and I'm hopeful that your workaround of checking
stderr will resolve this for you.
--
Rob Wickham [msft]
This posting is provided "as is" with no warranties, and confers no rights.
"Torgeir Bakken (MVP)" <Torgeir.B...@hydro.com> wrote in message
news:OhmeZ9uh...@TK2MSFTNGP09.phx.gbl...
Andrew Aronoff
>Further down in this post is another mbsacli.exe /xmlout parse script
>(that I have written).
Thanks for your script. It's a terrific learning opportunity.
I'll certainly revise my version to incorporate a check for StdErr and
use of the MS XML DOM.
Andrew Aronoff
It introduced me to the XML parsing language with the MS DOM.
>I'll certainly revise my version to incorporate a check for StdErr and
>use of the MS XML DOM.
Revision 01 captures StdError output and parses the XML with the MS
DOM. It can be downloaded here:
http://www.silentrunners.org/MBSACLI%20XML%20Parser.vbs
The MD5 hash is: 3AF0BE9AA93E5FF527E817A9A77DF295
This hash applies to revision 01. The revision number will always be
found on line 15 of the script. The revision history is at the bottom
of the script.
This is the last revision whose availability will be posted to this
newsgroup.
The script is free, but is provided with no warranty, expressed or
implied. It changes settings in the registry (and is designed to reset
the registry to the initial settings before it's done) and requires
Internet connectivity (so that it can retrieve hotfix datafiles from
Microsoft). You use this script at your own risk!
Please note:
1. The script must be located in the same directory as MBSACLI.EXE and
WUSSCAN.DLL. (It will display an error message if it isn't.)
2. The output text file will be placed in the same directory as the
script. The title root is "Hotfix Check Results.txt".
3. The script can be run with a single command line parameter that
will be appended to the output file name. If "Workstation 999" is the
command line parameter, the output text file title would be "Hotfix
Check Results Workstation 999.txt".
4. The script can only be run under Windows 2000 and Windows XP, since
earlier OS's are incompatible with MBSACLI 2.0. Running under an
earlier OS will display an error message.
5. The script must be run under an Administrator account. Running
under a non-admin account will display an error message.
6. The script will only report uninstalled hotfixes. The report format
is:
Sequence number. Hotfix title
Security bulletin number, Knowledge Base article number, update type,
update severity.
Security Bulletin URL
Download URL
A typical entry might be:
#. Some alarmiing hotfix title here
MS00-000 KB123456, Security Update, Maximum Severity: Critical
Security Bulletin URL: http://www.microsoft.com/.../MS00-000.mspx
Download URL: http://ridiculously_long_filename_here.exe
7. Microsoft Update Agent 2.0 is required for MBSACLI 2.0. Once it's
installed, the script does not require the Automatic Updates service
to be started. The script will enable the service if it's disabled and
start it up. It will restore the original service status before it
exits.
8. The script is written for use on individual workgroup PC's.
Revisions are welcome so that it can be used to scan a domain.
9. The script will hang if MBSACLI.EXE cannot download its .CAB file.
If someone has a suggestion to avoid this, please let me know.
10. If the script throws an error, please let me know and I'll fix the
bug.
11. If you have an XML parsing suggestion, please let me know and I'll
improve the script.
12. If you need customization assistance to get the script to work
your way in your shop, make me an offer. ;-)
13. MS will, of course, provide their own scripts. Torgeir Bakken has
posted a version that works admirably well and can be found here:
http://tinyurl.com/al6vo
Fake Name
package just to scan for updates" scenario? In MBSA 1.2 I could just copy
mbsacli.exe. What files are required to run an updates-only scan in MBSA
2.0? Is there any specific guidance around the standalone/disconnected
scenario? For example, I know the following:
1) Windows Update agent must be installed on the computer
[http://go.microsoft.com/fwlink/?LinkId=43264]
2) Security catalog must be downloaded
[http://go.microsoft.com/fwlink/?LinkId=39043]. Where should this file go?
Can it live in a shared network location?
3) mbsacli should be run. What switches should be used? What other files
are required?
<rant>
Though I understand it makes YOUR lives a lot easier when you have a
dedicated engine to scan for updates, requiring WUA to be installed on the
local computer has heedlessly destroyed my only usage scenario for MBSA.
MBSA 1.2 was doing a fantastic job of scanning for missing OS patches, and
it was portable and easy-to-use. I haven't yet been able to get MBSA 2.0
working without installing it, which means I now have to install 2 separate
packages on each machine I wish to scan. MBSA does not represent a win for
customers and I will be sticking with MBSA 1.2 for as long as the security
catalog file is updated. Please reconsider the decisions you have made to
require a heavy infrastructure. It's not what we want.
</rant>
"Rob Wickham [msft]" <rwic...@microsoft.com> wrote in message
news:erLS$m$gFHA...@TK2MSFTNGP14.phx.gbl...
Nelson Araujo [MSFT], CISSP, MCAD
folder. The other steps you describe seems correct to me (just missing the
other DLL). You should specify /xmlout for that.
Let me know if that works.
--
Regards,
Nelson Araujo, CISSP, MCAD
Software Development Engineer
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.
"Fake Name" <postmaster@localhost> wrote in message
news:uJ4RGE$jFHA...@TK2MSFTNGP15.phx.gbl...