9

I'm working on a PowerShell script to do some Windows Update tasks. Most tasks center around getting a collection of Windows Updates that have not yet been applied, using the code snippet below. Once that collection is returned, I iterate through it and perform such tasks as hiding, downloading, or installing the updates.

I notice that this code can take anywhere from 6 to 115 sceconds to run. Typically the longer runs are after the machine has restarted or been idle for more than 15 minutes.

But if I open the Windows Update control panel item, it instantly knows how many updates are outstanding, and can give me a list (collection) of those outstanding updates. If I click WU's "check for updates" link, it will take >10 seconds to check again, and sometimes that check will yield different results than it "knew" instantly when I opened it.

So I assume that WUA maintains a cached collection of updates somewhere, probably updated automatically once daily. My question: how can my code access that cache, rather than running the longer "check for updates" code shown below? Specifically, I am hoping to quickly obtain an IUpdateCollection to work with. 

$Session = New-Object -ComObject Microsoft.Update.Session            
$Searcher = $Session.CreateUpdateSearcher()
$Searcher.Online = $false  #tested $true and $false; $true slightly slower
$Criteria = "IsInstalled=0 and Type='Software'"
$SearchResult = $Searcher.Search($Criteria)           
$SearchResult.Updates

Note that all this is happening on a current, Windows2012R2 system.

quux
  • 660
  • 1
  • 10
  • 22
  • Have you checked the WindowsUpdate.log to see what is happening? What does `$Searcher.GetTotalHistoryCount()` show before you run this? – xXhRQ8sD2L7Z Dec 07 '14 at 23:11
  • ST8Z6FR57ABE6A8RE9UF - nothing unusual in WindowsUpdate.log. I see the $Searcher.GetTotalHistoryCount() start and complete instantly (returning "46"); the $Searcher.Search($Criteria) take over six seconds to complete. No errors. – quux Dec 08 '14 at 18:05
  • It's interesting, I know you can get the number from the registry but all that info isn't in there. Maybe its reading manifest files from the SoftwareDistribution folder? – xXhRQ8sD2L7Z Dec 10 '14 at 06:36

1 Answers1

3

Look like the cache is a CAB file called wsusscn2.cab that is regularly downloaded from MSFT. There is a direct link to it in the msdn link I posted below. Perhaps write a script that downloads that once per day/week (maybe to a network share if this is going to be a widely deployed script), and then change your script to force it to always look at the CAB file instead of online. Like this: 

$Session = New-Object -ComObject Microsoft.Update.Session       
$UServiceManager = New-Object -ComObject Microsoft.Update.ServiceManager
$UService =  $UServiceManager.AddScanPackageService("Offline Sync Service", "c:\wsusscn2.cab") 
$Searcher = $Session.CreateUpdateSearcher()
$Searcher.ServerSelection = 3  
$Searcher.ServiceID = $UService.ServiceID
$Criteria = "IsInstalled=0 and Type='Software'"
$SearchResult = $Searcher.Search($Criteria)           
$SearchResult.Updates

msdn

user3191188
  • 242
  • 3
  • 12
  • This seems unlikely. 1) A search of my computer finds no copies of wsusscan2.cab 2) In all the documentation I can find, it says this file must be downloaded before use. So, while it's one way to approach things, it seems not to be the cache that the system uses. – quux Dec 15 '14 at 23:56
  • Additionally: using an Invoke-Webrequest, the (currently 103 MB) file download takes longer than my original method did! – quux Dec 16 '14 at 00:07
  • usage of the `Wsusscn2.cab` offline cache is official and documented - https://msdn.microsoft.com/en-us/library/ff647642.aspx - mbsa fyi produces, ime, similar results to the powershell approach – Patrick Feb 26 '16 at 01:22
  • 1
    Patrick: yes, it's documented. One can script doing it that way, and I have (https://gist.github.com/bklockwood/716d9f582dd78a9e6e9e) .. but this doesn't seem to be how the *OS itself* actually caches such data. Thanks for the input, though. – quux Mar 07 '16 at 09:21