Installing per-downloaded windows updates

[hdsouza]

Hi, I only need to INSTALL the windows updates that are already DOWNLOADED to the windows server.
I found some equivalent code online. I need help converting it to Winbatch code

Code (html5) Select Expand


$updatesToInstall = New-Object -ComObject 'Microsoft.Update.UpdateColl'
$updates | Where-Object {$_.isdownloaded} | Foreach-Object {$updatesToInstall.Add($_) | Out-Null}
#Create installer object
$installer = $updateSession.CreateUpdateInstaller()
$installer.Updates = $updatesToInstall
WriteEvent "Beginning installation of downloaded updates `($($installer.Updates.count)`)." 'Information' '1003'
#Run installation of downloaded files
$installationResult = $installer.Install()


[td]

The following extensive VB example should make things easier to convert to WinBatch.

http://msdn.microsoft.com/en-us/library/windows/desktop/aa387102%28v=vs.85%29.aspx

[hdsouza]

TD, I had already looked at that link to start with. It explains how to search, download and install.
I have already tried the WB equivalent of that script  (http://techsupt.winbatch.com/webcgi/webbatch.exe?techsupt/nftechsupt.web+WinBatch/OLE~COM~ADO~CDO~ADSI~LDAP/Samples~from~Users+Windows~Update~Agent.txt )
.... and it fails on line
objSearchResult = objUpdateSearcher.Search("Type='Software'")

So as to avoid complexities and since I did not need to search for updates in any case (as updates are already downloaded) I wanted to get straight to installing the updates. Also the WB/VB code references the objUpdateSearcher.Search which fails. hence we cannot use them

Any ideas?
Thanks

[td]

The MSFT VB example demonstrates the use of methods and properties used by your PowerShell script that are not used by the Tech Database article...

[hdsouza]

TD, I am not using powershell. I am only using winbatch
If the VB script  does work for installing the updates, can you convert it to winbatch and post the code here
I am only looking for the install section.
Thanks

[hdsouza]

The MSFT VB example demonstrates the use of methods and properties used by your PowerShell script that are not used by the Tech Database article...

So how does this fix the problem. Maybe I am missing something here
Are you saying winbatch cannot apply downloaded updates?

I was able to get a list of already installed items with this code. Is there not something similar to Install already downloaded items?

Code (winbatch) Select Expand


objSearcher = CreateObject("Microsoft.Update.Searcher")
TotalHistoryCount = objSearcher.GetTotalHistoryCount - 1


[td]

Could be wrong but would guess you are missing the fact that the Powershell script you posted, which installs previously acquired updates, is simply calling COM Automation object methods and those parts of the VB example on MSFT's site are calling those same COM Automation objects' methods.

Would assume you already know that WinBatch can be used to call the same COM Automation object methods as well but could be wrong about that too.

[hdsouza]

Could be wrong but would guess you are missing the fact that the Powershell script you posted, which installs previously acquired updates, is simply calling COM Automation object methods and that parts of the VB example on MSFT's site are calling those same COM Automation objects' methods.

Would assume you already know that WinBatch can be used to call the same COM Automation object methods as well but could be wrong about that too.

That was the reason why I posted the powershell script to help with converting it to winbatch and I clearly stated that in my first post. If I did not believe that COM objects could not be aclled from winbatch then I would not have posted it to start with. But then you directed me to VB script.  Its because I do not understand VB i am doing it in winbatch. so you sending me a vb SCRIPT defeats the point.  Also I had already mentioned on January 14, 2015, 02:18:13 pm that it fails on the first few lines of code in the WB script and the VB script uses that same lines at the begining.

[td]

You were sent you to the VB script to help you convert the Powershell script because conversion from VB to WinBatch is trivial for most WinBatch users with any COM Automation experience and the  VB script has a section that uses the same objects as the Powershell script   

I have no idea why you would thought you needed to convert the entire VB script to WinBatch.  It was assumed that it would be clear that you only needed to convert the part that is relevant to implement the functionality of the Powershell script.

[hdsouza]

You were sent you to the VB script to help you convert the Powershell script because conversion from VB to WinBatch is trivial for most WinBatch users with any COM Automation experience and the  VB script has a section that uses the same objects as the Powershell script   

I have no idea why you would thought you needed to convert the entire VB script to WinBatch when it should have been clear that you only needed to convert the part that is relevant to implement the functionality of the Powershell script.

I never said the entire script had to be converted. But the download script needs a parameter defined at the beginning of the script.. which fails. I have mentioned that twice now. If you believe this is trivial and doable then can you tell us what the install script is

[hdsouza]

Is there a winbatch extender needed to get this line to work. Did not think so, but some of the VB guys here mentioned there could be a library in VB to be referenced
objSearchResult = objUpdateSearcher.Search("Type='Software'")

[td]

I don't have any problems executing ' objUpdateSearcher.Search("Type='Software'")' in WinBatch after creating the 'objUpdateSearcher' object.  Can't tell you why you are unable to create it.  You will need to search on the object's projid using the search engine of your choice or just search MSFT's MSDN pages.  MSFT has the Windows Update Agent extensively documented with many examples.

[td]

It does seem possible that the reason the 'Search' method could fail with a COM error is because it can't find an internet connection.  This may be the case even if you are only looking for already acquired updates.   You will need to ask MSFT if and why it works that way.

Also a script my be trivial conceptually but it still takes time to write.  The reason why we don't necessarily write  scripts on demand is because when is a straight forward task that  any experience use should be capable of handling, we will choose to focus our limited resources on a greater need. We need to be fair to everyone.

[hdsouza]

The problem has not even been understood. I dont need to search for updates. I only need to install existing updates. That should not need the searcher function
If you do not a searcher function, you would need it enumerate the downloads on the local system  and one would not run into the problem of searching the MSFT site

The VB script that you provided uses the the output of the searcher function off MSFT to get a count to the number of items to install. Again ...The count should be coming from the number of items already downloaded. So providing this VB script as an option was incorrect in the first place. Thats the reason I started off with the powershell script that was more relevant to the problem at hand. But the problem was not understood and then went on a tangent saying that the script is trivial, putting other people down (as usual) etc etc etc

[td]

Ok, now you are saying you don't needed  this line

objSearchResult = objUpdateSearcher.Search("Type='Software'")

Are you sure about that?

The 'Search' method can be used to obtain already 'downloaded' updates by making a simple change to the query string, however, the method may error even when searching for local updates if the system does not have internet access. 

And the PowerShell script creates a collection of updates but it isn't clear that collection has any elements.   The VB script demonstrates how to load updates into the updates collection before looping through the collection to install each update.  The Powershell script is also calling a method on each update to verify that the update is indeed downloaded.   These facts together suggest that the Powershell script may not by itself be able to access the 'downloaded' updates and needs to have the collection loaded before the installation loop is executed.

As previously mentioned, the Powershell script is easily converted to WinBatch.  Once converted you could run the script on a system with 'downloaded' updates present to determine if it will pick them up.  If it doesn't then you could use a modified search query to get a the updates to add to the update collection.   The query to collect 'downloaded' updates would look something like the following

searchResult = updateSearcher.Search("IsPresent=1 AND Type='Software' AND IsHidden=0") (may not be the exact syntax)

Of course, this will not work if you are running on a system that does not fully support the Windows Update Agent.

A lot of information is available on MSFT's web site and a little experimentation can go a long way toward understanding how MSFT has implemented this collection of COM Automation interfaces.