Prev: objUser.SetPassword "object dose not support this property or method" error
Next: Active X component can't create object scripting.filesystemobject code 800A01AD
From: Mark F on 8 Feb 2006 09:48 Hello, There are a variety of Windows Update (WUA/WSUS) VBScripts out there, and here is ours from its recent commissioning @ Hull College: www.futuretime15.karoo.net For any newbies to VBScripting, its ValidArguments() function, which parses the command-line arguments, may also be worth a peek. ===================================================== Filename: WindowsUpdates.wsf Description: Automatically downloads and installs relevant updates Version: Modified 1.0 WindowsUpdates.vbs Notes: From the Microsoft Shared Computer Toolkit for WinXP Closing its optional console window kills the task See also %windir%\WindowsUpdate.log for another log Large portions are Copyright (C) Microsoft Corporation 2005 Modifications to enhance its interface by Mark Fairpo Commissioned within Hull-College.ac.uk for a resilient VBScript Use "WindowsUpdates /?" or "CScript WindowsUpdates.wsf /?" for help =====================================================
From: maximillianx on 8 Feb 2006 10:08 Hi Mark, I put something together using Microsoft's skeleton code last year with extensive logging and email functionality: http://uphold2001.brinkster.net/vbshf/forum/forums/thread-view.asp?tid=199&start=1 Regards, Rob "Mark F" <MarkF(a)discussions.microsoft.com> wrote in message news:7FF32CEF-E641-44C5-AE75-F9EA7E387C17(a)microsoft.com... > Hello, > > There are a variety of Windows Update (WUA/WSUS) VBScripts out there, and > here is ours from its recent commissioning @ Hull College: > > www.futuretime15.karoo.net > > For any newbies to VBScripting, its ValidArguments() function, which > parses > the command-line arguments, may also be worth a peek. > > ===================================================== > > Filename: WindowsUpdates.wsf > > Description: Automatically downloads and installs relevant updates > > Version: Modified 1.0 WindowsUpdates.vbs > Notes: From the Microsoft Shared Computer Toolkit for WinXP > Closing its optional console window kills the task > See also %windir%\WindowsUpdate.log for another log > > Large portions are Copyright (C) Microsoft Corporation 2005 > Modifications to enhance its interface by Mark Fairpo > Commissioned within Hull-College.ac.uk for a resilient VBScript > > Use "WindowsUpdates /?" or "CScript WindowsUpdates.wsf /?" for help > > =====================================================
From: Mark F on 8 Feb 2006 12:24 Hi Rob, At the time we tested your VBScript there were undiagnosed issues (1) after upgrading our intranet's Update Server. Because of your greater knowledge of this Agent you'd spliced the ribs from Microsoft's skeletal routines, so we lacked confidence in what was causing our problem. I am not discrediting your A+ scripting, but it formed part of a duff black-box at that time. Hence our VBScript adding a ServerSelection command-line option. I humbly defer my VBScript in favour of yours. However, you include optional extras surplus to our 3am Wake-on-LAN updating requirements (e.g. shut-down, etc). Trimer code was important, as all VBScripts are pasted together by our NetAdmin into a VBScript from Sophos Anti-Virus; such spaghetti is his choice as he needs to maintain it. Kind Regards, Mark F 1. Microsoft's new Patch-approval interface left our NetAdmin weary, and you never indicated that the Server URL may be unreachable. From C:\Windows\WindowsUpdate.log, I am unsure which API is used to get 'ServiceId = {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx}, Server URL = https://update.microsoft.com/v6/ClientWebService/client.asmx'. Microsoft.Update.ServiceManager's ServiceID returns OK, ServiceUrl returned blank, and RedirectUrls returned an invalid VarType. Hence, I simply included its ServerSelection command-line option. "maximillianx" wrote: > Hi Mark, > > I put something together using Microsoft's skeleton code last year with > extensive logging and email functionality: > > http://uphold2001.brinkster.net/vbshf/forum/forums/thread-view.asp?tid=199&start=1 > > Regards, > Rob
From: maximillianx on 8 Feb 2006 12:50 No problem, just wasn't sure if you guys could have gotten out of doing some more work or not :) Regards, Rob "Mark F" <MarkF(a)discussions.microsoft.com> wrote in message news:F1307ED9-2371-4901-BC92-083CF6912F6F(a)microsoft.com... > Hi Rob, > > At the time we tested your VBScript there were undiagnosed issues (1) > after > upgrading our intranet's Update Server. Because of your greater knowledge > of > this Agent you'd spliced the ribs from Microsoft's skeletal routines, so > we > lacked confidence in what was causing our problem. I am not discrediting > your > A+ scripting, but it formed part of a duff black-box at that time. > > Hence our VBScript adding a ServerSelection command-line option. I humbly > defer my VBScript in favour of yours. However, you include optional extras > surplus to our 3am Wake-on-LAN updating requirements (e.g. shut-down, > etc). > Trimer code was important, as all VBScripts are pasted together by our > NetAdmin into a VBScript from Sophos Anti-Virus; such spaghetti is his > choice > as he needs to maintain it. > > Kind Regards, > Mark F > > 1. Microsoft's new Patch-approval interface left our NetAdmin weary, and > you > never indicated that the Server URL may be unreachable. From > C:\Windows\WindowsUpdate.log, I am unsure which API is used to get > 'ServiceId > = {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx}, Server URL = > https://update.microsoft.com/v6/ClientWebService/client.asmx'. > Microsoft.Update.ServiceManager's ServiceID returns OK, ServiceUrl > returned > blank, and RedirectUrls returned an invalid VarType. Hence, I simply > included > its ServerSelection command-line option. > > "maximillianx" wrote: > >> Hi Mark, >> >> I put something together using Microsoft's skeleton code last year with >> extensive logging and email functionality: >> >> http://uphold2001.brinkster.net/vbshf/forum/forums/thread-view.asp?tid=199&start=1 >> >> Regards, >> Rob
From: Mark F on 8 Feb 2006 14:18
No worries Rob. We ran 3-out-of-several VBScripts we downloaded, all emerging from differently styled communities. I do recommend considering my own primal-methods of making Microsoft's original routines more visible within your Script. As yours is now daunting in unbroken length that this became prima-facta to our NetAdmin shelving it, rather than been able to state 'either routines patently copied from Microsoft or more likely our system is at fault'. "maximillianx" wrote: > No problem, just wasn't sure if you guys could have gotten out of doing some > more work or not :) > > Regards, > Rob |