Das Remote-Erkennen von Windows hat die Patch-Konfiguration nach dem Neustart abgeschlossen

Wir planen, die Erstellung von VMs für unsere Build-Infrastruktur zu automatisieren, damit wir:

1. Skalieren Sie die Build-Ressourcen nach Bedarf, indem Sie beispielsweise bei Bedarf weitere Build-Agenten hinzufügen und bei Bedarf entfernen
2. Erstellen Sie die gesamte oder einen Teil der Build-Umgebung neu, wenn Maschinen ausfallen
3. Duplizieren Sie die Build-Umgebung, wenn ein Test eingerichtet werden muss

Einer der Schritte in diesem Prozess ist die Automatisierung der Erstellung der VM-Basisimages (in unserem Fall mit Hyper-V). Dafür haben wir ein Skript, das:

1. Erstellt neues VHDX aus ISO mit dem Skript Convert-WindowsImage . Wir verwenden derzeit Windows 2012R2, werden jedoch versuchen, mit 2016 zu beginnen, sobald es verfügbar ist.
2. Fügt dem neuen VHDX ein unbeaufsichtigtes Skript mit der gesamten erforderlichen Basiskonfiguration hinzu
3. Aktualisiert die VHDX mit den neuesten Windows-Patches mithilfe des Apply-WindowsUpdate- Skripts
4. Erstellt eine neue Hyper-V-VM basierend auf der VHDX und startet sie
5. Wartet auf den Start der VM und darauf, dass der WinRM-Dienst bereit ist, Remoteverbindungen zu akzeptieren
6. Wartet darauf, dass Windows die Erstkonfiguration und die Konfiguration der neuen Patches abschließt
7. Wendet weitere Patches an
8. Startet neu, um die Konfiguration der neuesten Patches abzuschließen
9. Wartet, bis Windows die Konfiguration der Patches abgeschlossen hat
10. Überträgt ein Sysprep-Skript auf den Computer und ruft dieses Skript auf. Dadurch wird sysprep ausgeführt und der Computer dann ausgeschaltet
11. Löscht die VM, behält aber die VHDX bei
12. Entfernt Sysprep- und unbeaufsichtigte Dateien von der VHDX und komprimiert dann die VHDX
13. Verschiebt VHDX an den Speicherort der Vorlage und markiert es als schreibgeschützt

Das Problem tritt in den Schritten 6 und 9 auf. Im Idealfall warten wir, bis die gesamte Konfiguration abgeschlossen ist, bevor wir den Computer neu starten / herunterfahren. Es scheint jedoch keine Möglichkeit zu geben, zu erkennen, dass Windows die Konfigurationsphase abgeschlossen hat.

Wenn Sie die Benutzeroberfläche durchlaufen, ist sehr klar, wann einer der beiden Schritte ausgeführt wird, da die Anmelde-Benutzeroberfläche erst angezeigt wird, wenn der Vorgang abgeschlossen ist. Wenn Sie jedoch WinRM verwenden, um eine Remoteverbindung zum Computer herzustellen, ist dies weniger klar, da WinRM den Zugriff auf den Computer ermöglicht, bevor die Konfigurationsarbeiten abgeschlossen sind.

Die Frage ist also, wie man über eine Remoteverbindung am besten erkennen kann, dass Windows die Konfiguration von Updates usw. abgeschlossen hat, damit wir den Computer neu starten / herunterfahren können, ohne später Probleme zu verursachen.

------ EDIT -----

Am Ende verwenden wir eine modifizierte Version von Katherines Antwort, indem unser Skript auch darauf wartet windeployund ngenabgeschlossen wird. Da ngendies erst lange nach Abschluss der Initialisierung des Betriebssystems abgeschlossen ist, wird das endgültige VHDX über das gesamte .NET-Framework verfügen, was bedeutet, dass wir uns beim Erstellen neuer Betriebssysteme nicht darum kümmern müssen VMs der Vorlagenfestplatte. Sowohl das Skript, das wir zum Erstellen der VHDX-Vorlage verwenden, als auch die Skripte zum Erstellen der lokalen Testumgebung befinden sich auf Github, falls jemand interessiert ist.

Das klingt vielleicht nach einer seltsamen Antwort, aber ...

Es gibt ein PowerShell-Skript, mit dem überprüft werden kann, ob Updates für Nagios verfügbar sind . Sie könnten dieses Skript oder eine Variante wahrscheinlich ohne Nagios für Ihre Zwecke verwenden.

Überprüfen Sie, ob Wuauclt und TrustedInstaller ausgeführt werden, um festzustellen, ob sie ausgeführt werden. Der Rat von Microsoft zu Updates für Server Core kann hier hilfreich sein :

Abhängig von den installierten Updates müssen Sie den Computer möglicherweise neu starten, obwohl das System Sie nicht darüber informiert. Um festzustellen, ob der Installationsprozess abgeschlossen ist, überprüfen Sie mithilfe des Task-Managers, ob die Prozesse Wuauclt oder Trusted Installer nicht aktiv ausgeführt werden. Sie können auch die Methoden im Abschnitt "Anzeigen installierter Updates" verwenden, um die Liste der installierten Updates zu überprüfen.

Sie können diese Informationen wahrscheinlich mit so etwas abrufen Get-Process -Computername YourImage TrustedInstaller.exe. Nachdem sowohl der Wuauclt- als auch der TrustedInstaller-Prozess abgeschlossen sind, sollte der Neustart sicher sein.

Jeder Windows Update-Patch schreibt mehrere Ereignisse in das Setup-Ereignisprotokoll.

• Ereignis-ID 1 - Initiieren von Änderungen für Paket KB ####
• Ereignis-ID 4 - Ein Neustart ist erforderlich, bevor die Paket-KB #### in den installierten Zustand geändert werden kann
• Ereignis-ID 2 - Paket-KB #### wurde erfolgreich in den Status "Installiert" geändert

Eine Möglichkeit, festzustellen, ob alle Patches angewendet wurden, besteht darin, die Ereignis-ID 4 zu überprüfen. Vergleichen Sie die Zeit dieses Ereignisses mit der aktuellen Zeit. Wenn 5 oder 10 Minuten lang keine Ereignis-ID 4 geschrieben wurden, sind wahrscheinlich alle Pataches erledigt und können neu gestartet werden.

Mir ist nicht klar, ob Sie den ersten Neustart durchführen möchten, wenn die Patches installiert sind (Ereignis 4), oder den zweiten Neustart, nachdem die Konfiguration abgeschlossen ist (Ereignis 2). Dieser Code macht das erstere. Ändern Sie einfach die filterHashTable für den anderen Neustart vor Schritt 10 in Ereignis-ID 2.

$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
    }
}

Ich habe mit dem folgenden Ansatz gute Erfolge erzielt: Warten Sie, bis Windows den Starttyp des Windows-Modulinstallationsdienstes (auch bekannt als TrustedInstaller) nach einem Neustart in Manuell (Anforderungsstart) ändert. Zu diesem Zeitpunkt sind die Updates abgeschlossen.

Der Trusted Installer-Prozess wird manchmal fortgesetzt, nachdem Patches installiert wurden. Der Dienststarttyp wird jedoch weiterhin auf Manuell zurückgesetzt.

Sie können selbst überprüfen, ob die obige Beobachtung konsistent / korrekt ist, indem Sie frühere Ereignisprotokollmeldungen anzeigen und Ereignisse zwischen den System- und Setup-Protokollen korrelieren.

Die Startänderung an Windows Module Installer wird als 7040-Systemereignis protokolliert und korreliert nach einem Neustart mit dem letzten Ereignis 2 im Setup-Protokoll.

Ich denke, dass bei der Erstinstallation von Updates dieser Dienst auf "Auto Start" gesetzt ist, falls ein Neustart erforderlich ist. Es wird bei der Installation des letzten Patches auf "Manuell" zurückgesetzt (unabhängig davon, ob ein Neustart erforderlich war).

Auf einigen Servern ist mir aufgefallen, dass der vertrauenswürdige Start des Installationsprogramms schnell von manuell auf automatisch und zurück umgeschaltet wird. Dies kann etwa jede Stunde auftreten. Ich vermute, es ist eine Anwendung, die regelmäßig nach Updates sucht. Ich habe jedoch die Erfahrung gemacht, dass im Allgemeinen davon ausgegangen werden kann, dass bei einem manuellen Start kein Patching stattfindet.