Jak zdalnie wykryć system Windows zakończył konfigurację łaty po ponownym uruchomieniu

Planujemy zautomatyzować tworzenie maszyn wirtualnych dla naszej infrastruktury kompilacji, abyśmy mogli:

1. Skaluj zasoby kompilacji na podstawie zapotrzebowania, np. Dodając więcej agentów kompilacji, gdy jest to wymagane, i usuwając je, gdy nie są wymagane
2. Odtworzyć całość lub część środowiska kompilacji, jeśli / kiedy maszyny umrą
3. Zduplikuj środowisko kompilacji, gdy potrzebujemy konfiguracji testowej

Jednym z kroków tego procesu jest automatyzacja tworzenia podstawowych obrazów maszyn wirtualnych (w naszym przypadku przy użyciu funkcji Hyper-V). Do tego mamy skrypt, który:

1. Tworzy nowy VHDX z ISO za pomocą skryptu Convert-WindowsImage . Obecnie korzystamy z systemu Windows 2012R2, ale zaczniemy od 2016 roku, gdy tylko będzie dostępny.
2. Dodaje skrypt nienadzorowany do nowego VHDX ze wszystkimi potrzebnymi konfiguracjami podstawowymi
3. Aktualizuje VHDX o najnowsze łaty systemu Windows za pomocą skryptu Apply-WindowsUpdate
4. Tworzy nową maszynę wirtualną Hyper-V na podstawie VHDX i uruchamia ją
5. Czeka na uruchomienie maszyny wirtualnej i czeka, aż usługa WinRM będzie gotowa na przyjęcie połączeń zdalnych
6. Oczekiwanie na zakończenie przez Windows konfiguracji początkowej i konfiguracji nowych łatek
7. Stosuje wszelkie dalsze poprawki
8. Uruchomi się ponownie, aby zakończyć konfigurację najnowszych łatek
9. Czeka, aż system Windows zakończy konfigurowanie poprawek
10. Pcha skrypt sysprep na maszynę i wywołuje ten skrypt. Spowoduje to uruchomienie sysprep, a następnie wyłączenie urządzenia
11. Usuwa maszynę wirtualną, ale zachowuje VHDX
12. Usuwa pliki sysprep i instalacji nienadzorowanej z VHDX, a następnie kompaktuje VHDX
13. Przenosi VHDX do lokalizacji szablonu i oznacza jako tylko do odczytu

Występuje problem w krokach 6 i 9. Idealnie czekamy na zakończenie całej konfiguracji przed ponownym uruchomieniem / zamknięciem komputera, ale wydaje się, że nie ma sposobu na wykrycie, że system Windows zakończył etap konfiguracji.

Podczas przechodzenia przez interfejs użytkownika jest bardzo jasne, kiedy którykolwiek z kroków zostanie wykonany, ponieważ interfejs logowania nie pojawia się, dopóki proces nie jest gotowy. Jednak przy użyciu WinRM do zdalnego połączenia z maszyną jest to mniej jasne, ponieważ WinRM zapewnia dostęp do komputera, zanim zakończy się praca konfiguracyjna.

Pytanie brzmi zatem, jaki jest najgłupszy sposób na wykrycie przez zdalne połączenie, że system Windows zakończył konfigurowanie aktualizacji itp., Abyśmy mogli ponownie uruchomić / zamknąć komputer bez powodowania problemów w późniejszym czasie.

------ EDYTOWAĆ -----

W końcu jesteśmy stosując zmodyfikowaną wersję odpowiedzi Katherine, że nasz skrypt czeka także windeployi ngendo końca. Biorąc pod uwagę, że ngennie kończy się to długo po zakończeniu inicjalizacji systemu operacyjnego, co działa, i jako bonus, ostateczny VHDX będzie miał całą strukturę .NET, co oznacza, że ​​nie musimy sobie z tym poradzić, gdy tworzymy nowy Maszyny wirtualne dysku szablonu. Zarówno skrypt, którego używamy do tworzenia szablonu VHDX, jak i skrypty do tworzenia lokalnego środowiska testowego znajdują się na github na wypadek, gdyby ktoś był zainteresowany.

Może to zabrzmieć jak dziwna odpowiedź, ale ...

Istnieje skrypt PowerShell do sprawdzania, czy są dostępne aktualizacje dla Nagios . Prawdopodobnie możesz użyć tego skryptu lub wariantu do swoich celów, bez Nagios.

Jeśli chodzi o to, czy są w toku, sprawdź, czy Wuauclt i TrustedInstaller są uruchomione. Porady Microsoft dotyczące aktualizacji Server Core mogą pomóc tutaj :

W zależności od zainstalowanych aktualizacji może być konieczne ponowne uruchomienie komputera, chociaż system nie powiadomi Cię o tym. Aby ustalić, czy proces instalacji został zakończony, użyj Menedżera zadań, aby sprawdzić, czy procesy Wuauclt lub Trusted Installer nie są aktywnie uruchomione. Możesz także skorzystać z metod opisanych w sekcji „Wyświetlanie zainstalowanych aktualizacji”, aby sprawdzić listę zainstalowanych aktualizacji.

Prawdopodobnie możesz wyciągnąć tę informację za pomocą czegoś takiego Get-Process -Computername YourImage TrustedInstaller.exe. Po zakończeniu zarówno procesów Wuauclt, jak i TrustedInstaller ponowne uruchomienie powinno być bezpieczne.

Każda poprawka aktualizacji systemu Windows zapisze kilka zdarzeń w dzienniku zdarzeń Instalatora.

• Identyfikator zdarzenia 1 - Inicjowanie zmian dla pakietu KB ####
• Identyfikator zdarzenia 4 - Konieczne jest ponowne uruchomienie komputera, zanim pakiet KB #### może zostać zmieniony na stan zainstalowany
• Identyfikator zdarzenia 2 - pakiet KB #### został pomyślnie zmieniony na stan Zainstalowany

Jednym ze sposobów na określenie wszystkich zastosowanych poprawek byłoby zapętlenie kontroli identyfikatora zdarzenia 4. Porównaj czas tego zdarzenia z bieżącym czasem. Jeśli żadne zdarzenie o identyfikatorze 4 nie zostało zapisane przez 5 lub 10 minut, wszystkie patache są prawdopodobnie gotowe i gotowe do ponownego uruchomienia.

Nie jestem pewien, czy chcesz zrobić pierwszy restart po zakończeniu instalacji łat (zdarzenie 4), czy drugi restart po zakończeniu konfigurowania (zdarzenie 2). Ten kod robi to pierwsze. Po prostu zmień filterHashTable na event id 2 dla drugiego restartu przed krokiem 10.

$target = "bart"
$found = $false
while (-not $found) {
    $lastEvent4 = (get-winevent -comp $target -maxEvents 1 -filterHashTable @{ Logname='Setup'; id = '4';}).timeCreated
    if (((get-date) - $lastEvent4).totalMinutes -gt 10) {
        "do reboot"
        restart-computer -comp -$target
        $found = $true
    } else {
        "wait"
        start-sleep 60
    }
}

Odniosłem sukces, stosując następujące podejście: Poczekaj, aż system Windows zmieni typ uruchamiania usługi instalatora modułów systemu Windows (inaczej TrustedInstaller) na ręczny (uruchamianie na żądanie) - po ponownym uruchomieniu. W tym momencie aktualizacje zostały zakończone.

Proces zaufanego instalatora czasami nadal działa po zainstalowaniu łat? Jednak typ uruchomienia usługi jest nadal resetowany do ręcznego.

Możesz sam sprawdzić, czy powyższa obserwacja jest spójna / poprawna, przeglądając poprzednie komunikaty dziennika zdarzeń i korelując zdarzenia między dziennikiem systemu a dziennikami instalacji.

Zmiana uruchamiania Instalatora modułów systemu Windows jest rejestrowana jako zdarzenie systemowe 7040 i koreluje z ostatnim zdarzeniem 2 w dzienniku instalacji po ponownym uruchomieniu.

Myślę, że kiedy instalowane są aktualizacje, ta usługa jest ustawiona na „Auto Start” na wypadek, gdyby konieczne było ponowne uruchomienie. Po zainstalowaniu ostatniej poprawki jest ustawiany z powrotem na „Ręczny” (niezależnie od tego, czy wymagane było ponowne uruchomienie).

Na niektórych serwerach zauważyłem, że zaufane uruchomienie Instalatora szybko przełącza się z ręcznego na automatyczne i wstecz, i może się to zdarzać co godzinę. Podejrzewam, że jest to aplikacja, która regularnie sprawdza dostępność aktualizacji. Z mojego doświadczenia wynika jednak, że ogólnie można bezpiecznie założyć, że jeśli uruchamianie odbywa się ręcznie, wówczas nie następuje łatanie.