2014-12-06 4 views
9

Я работаю над скриптом PowerShell для выполнения некоторых задач Windows Update. Большинство задач сосредоточены вокруг получения коллекции обновлений Windows, которые еще не были применены, используя нижеприведенный фрагмент кода. После возвращения этой коллекции я повторяю ее и выполняю такие задачи, как скрытие, загрузка или установка обновлений.Slow WUA (API обновления Windows)

Я заметил, что этот код может занять от 6 до 115 сеансов. Как правило, более длинные прогоны после перезапуска машины или простоя в течение более 15 минут.

Но если я открою элемент панели управления Windows Update, то мгновенно знает, сколько обновлений выдающихся, и может дать мне список (сбор) этих выдающихся обновлений. Если я нажму ссылку WU для проверки на обновления, потребуется еще> 10 секунд, чтобы проверить, и иногда эта проверка даст разные результаты, чем «мгновенно», когда я ее открываю.

Поэтому я предполагаю, что АВП хранит кешированную коллекцию обновлений где-то, возможно, обновляется автоматически один раз в день. Мой вопрос: как мой код может получить доступ к этому кешу, а не работать с более длинным кодом «проверить на наличие обновлений», показанным ниже? В частности, я надеюсь быстро получить IUpdateCollection для работы.

$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 

Обратите внимание, что все это происходит на текущей, системы Windows2012R2.

+0

Вы уже проверили на windowsupdate.log, чтобы увидеть, что происходит? Что показывает '$ Searcher.GetTotalHistoryCount()' перед запуском? – xXhRQ8sD2L7Z

+0

ST8Z6FR57ABE6A8RE9UF - ничего необычного в WindowsUpdate.log. Я вижу, что $ Searcher.GetTotalHistoryCount() начинается и заканчивается мгновенно (возвращается «46»); $ Searcher.Search ($ Criteria) занимает более шести секунд. Нет ошибок. – quux

+0

Это интересно, я знаю, что вы можете получить номер в реестре, но все, что информация не там. Может быть, его чтение файлов манифеста из папки SoftwareDistribution? – xXhRQ8sD2L7Z

ответ

3

Похоже, что кэш - это файл CAB, называемый wsusscn2.cab, который регулярно загружается из MSFT. Существует прямая ссылка на него в ссылке msdn, опубликованной ниже. Возможно, напишите сценарий, который загружается один раз в день/неделю (возможно, в общий сетевой ресурс, если это будет широко развернутый скрипт), а затем измените свой скрипт, чтобы заставить его всегда смотреть на CAB-файл, а не в Интернете. Как это:

$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

+0

Это кажется маловероятным. 1) Поиск моего компьютера не находит копий wsusscan2.cab. 2) Во всей документации, которую я могу найти, он говорит, что этот файл должен быть загружен перед использованием. Таким образом, хотя это один из способов приблизиться к вещам, похоже, это не тот кеш, который использует система. – quux

+0

Дополнительно: с использованием Invoke-Webrequest загрузка (в настоящее время 103 МБ) занимает больше времени, чем мой оригинальный метод! – quux

+0

использование автономного кеша 'Wsusscn2.cab' является официальным и документированным - https://msdn.microsoft.com/en-us/library/ff647642.aspx - mbsa fyi производит, ime, аналогичные результаты для подхода powershell – Patrick

Смежные вопросы