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:
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
Andrew, this is excellent. There is a recent post from another user looking 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_WRONG.ADDR...@yahoo.com> wrote in message
> 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:
> 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
"Andrew Aronoff" wrote: > 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 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:
> 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
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" <SixDoub...@discussions.microsoft.com> wrote in message
>> 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:
>> 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
>How do I deploy Window Update Agent to all my workstations?
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.
Regarding a "step in the wrong direction", can you be specific about your 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_WRONG.ADDR...@yahoo.com> wrote in message
> >How do I deploy Window Update Agent to all my workstations?
> 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.
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]" wrote: > Regarding a "step in the wrong direction", can you be specific about your > 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_WRONG.ADDR...@yahoo.com> wrote in message > news:85hrc195l2r177uav28mqn95vvucqhnehe@4ax.com... > > >How do I deploy Window Update Agent to all my workstations?
> > 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.
Thanks for expressing these issues. MBSA 2.0 is a next-generation tool 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" <SixDoub...@discussions.microsoft.com> wrote in message
> 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]" wrote:
>> Regarding a "step in the wrong direction", can you be specific about your >> 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_WRONG.ADDR...@yahoo.com> wrote in message >> news:85hrc195l2r177uav28mqn95vvucqhnehe@4ax.com... >> > >How do I deploy Window Update Agent to all my workstations?
>> > 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 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]" <rwick...@microsoft.com> wrote in message news:erLS$m$gFHA.3868@TK2MSFTNGP14.phx.gbl...
> Thanks for expressing these issues. MBSA 2.0 is a next-generation tool > 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" <SixDoub...@discussions.microsoft.com> wrote in message > news:7433B208-B821-453E-9D10-A1B8A5647A74@microsoft.com... >> Sure!
>> 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]" wrote:
>>> Regarding a "step in the wrong direction", can you be specific about >>> your >>> 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_WRONG.ADDR...@yahoo.com> wrote in message >>> news:85hrc195l2r177uav28mqn95vvucqhnehe@4ax.com... >>> > >How do I deploy Window Update Agent to all my workstations?
>>> > 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.
Andrew Aronoff wrote: > 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.
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
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")
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
' 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
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
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.
-- Rob Wickham [msft] This posting is provided "as is" with no warranties, and confers no rights. "Torgeir Bakken (MVP)" <Torgeir.Bakken-s...@hydro.com> wrote in message news:edBIeKjhFHA.3652@TK2MSFTNGP10.phx.gbl...
> 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
> 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
> 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
> ' 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
Rob Wickham [msft] wrote: > 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.
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?
Grade 5 is "installed" or a green check. Grade 2 is "missing", or a red X. 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.Bakken-s...@hydro.com> wrote in message news:ulvWKHvhFHA.1204@TK2MSFTNGP12.phx.gbl...
> 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?
Torgeir, thanks for this level of detail. I think I understand exactly what 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.Bakken-s...@hydro.com> wrote in message news:OhmeZ9uhFHA.1416@TK2MSFTNGP09.phx.gbl...
>> 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.
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
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
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
Can you elaborate more on the "not needing to fully install the MBSA setup 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:
<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>
> Thanks for expressing these issues. MBSA 2.0 is a next-generation tool > 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" <SixDoub...@discussions.microsoft.com> wrote in message > news:7433B208-B821-453E-9D10-A1B8A5647A74@microsoft.com... >> Sure!
>> 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]" wrote:
>>> Regarding a "step in the wrong direction", can you be specific about >>> your >>> 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_WRONG.ADDR...@yahoo.com> wrote in message >>> news:85hrc195l2r177uav28mqn95vvucqhnehe@4ax.com... >>> > >How do I deploy Window Update Agent to all my workstations?
>>> > 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.
To run MBSA 2.0 without installation, just add wusscan.dll to the same 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
> Can you elaborate more on the "not needing to fully install the MBSA setup > 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]" <rwick...@microsoft.com> wrote in message > news:erLS$m$gFHA.3868@TK2MSFTNGP14.phx.gbl... >> Thanks for expressing these issues. MBSA 2.0 is a next-generation tool >> 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" <SixDoub...@discussions.microsoft.com> wrote in message >> news:7433B208-B821-453E-9D10-A1B8A5647A74@microsoft.com... >>> Sure!
>>> 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]" wrote:
>>>> Regarding a "step in the wrong direction", can you be specific about >>>> your >>>> 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_WRONG.ADDR...@yahoo.com> wrote in message >>>> news:85hrc195l2r177uav28mqn95vvucqhnehe@4ax.com... >>>> > >How do I deploy Window Update Agent to all my workstations?
>>>> > 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.
|
