2014-12-06 14 views
9

Pracuję nad skryptem PowerShell, aby wykonać niektóre zadania Windows Update. Większość zadań koncentruje się wokół pobierania aktualizacji systemu Windows, które nie zostały jeszcze zastosowane, za pomocą poniższego fragmentu kodu. Po zwróceniu tej kolekcji dokonuję jej iteracji i wykonuje takie zadania, jak ukrywanie, pobieranie lub instalowanie aktualizacji.Powolne WUA (Windows Update API)

Zauważam, że ten kod może trwać od 6 do 115 działek. Zwykle dłuższe przebiegi są po ponownym uruchomieniu urządzenia lub bezczynności przez ponad 15 minut.

Ale jeśli otworzę element panelu sterowania Windows Update, to natychmiast wie, ile aktualizacji jest zaległych, i może dać mi listę (kolekcję) tych zaległych aktualizacji. Jeśli kliknę link WU "sprawdź dostępność aktualizacji", ponowne sprawdzenie zajmie> 10 sekund, a czasami ten czek przyniesie inne wyniki, niż "wiedział" od razu po jego otwarciu.

Zakładam więc, że WUA przechowuje zbuforowany zbiór aktualizacji gdzieś, prawdopodobnie aktualizowany automatycznie raz dziennie. Moje pytanie: w jaki sposób mój kod może uzyskać dostęp do pamięci podręcznej, zamiast wyświetlać poniższy kod "sprawdź aktualizacje"? W szczególności mam nadzieję szybko uzyskać IUpdateCollection do pracy.

$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 

Należy pamiętać, że to wszystko dzieje się na bieżąco, system Windows2012R2.

+0

Czy sprawdził WindowsUpdate.log aby zobaczyć, co się dzieje? Co pokazuje '$ Searcher.GetTotalHistoryCount()' przed uruchomieniem tego? – xXhRQ8sD2L7Z

+0

ST8Z6FR57ABE6A8RE9UF - nic niezwykłego w WindowsUpdate.log. Widzę, że $ Searcher.GetTotalHistoryCount() zaczyna się i kończy od razu (zwracając "46"); the $ Searcher.Search ($ Criteria) zajmuje ponad sześć sekund. Bez błędów. – quux

+0

To interesujące, wiem, że możesz uzyskać numer z rejestru, ale nie ma tam tej informacji. Może jego pliki manifestu czytania z folderu SoftwareDistribution? – xXhRQ8sD2L7Z

Odpowiedz

3

Wygląd bufora to plik CAB o nazwie wsusscn2.cab, który jest regularnie pobierany z MSFT. Istnieje bezpośredni link do niego w linku msdn zamieszczonym poniżej. Być może napisać skrypt, który pobiera pliki raz dziennie na tydzień (może do udziału sieciowego, jeśli ma to być szeroko wdrożony skrypt), a następnie zmienić skrypt tak, aby zawsze wyświetlał plik CAB zamiast online. Jak to:

$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

To wydaje się mało prawdopodobne. 1) Wyszukiwanie na moim komputerze nie zawiera kopii wsusscan2.cab 2) W całej dokumentacji, którą mogę znaleźć, jest napisane, że plik ten musi zostać pobrany przed użyciem. Tak więc, chociaż jest to jeden ze sposobów podejścia do rzeczy, wydaje się, że nie jest to pamięć podręczna, z której korzysta system. – quux

+0

Dodatkowo: przy użyciu Invoke-Webrequest, pobieranie pliku (obecnie 103 MB) trwa dłużej niż moja oryginalna metoda! – quux

+0

Używanie bufora podręcznego 'Wsusscn2.cab' jest oficjalne i udokumentowane - https://msdn.microsoft.com/en-us/library/ff647642.aspx - mbsa fyi produkuje, ime, podobne wyniki do podejścia PowerShell – Patrick