Vor und nach dem Windows 10 Inplace Upgrade

Steuerung per Ivanti DSM 7

Windows 10 Upgrade-Gruppen

Vor dem Windows 10 Feature Update sind ein paar Vorbereitungen zu erledigen und auch danach sollte geprüft und nachgearbeitet werden. Aktivierung / Deaktivierung der Verschlüsselung? Deinstallation und Reinstallation von Komponenten, die nicht "upgradebar" sind? Alles, was anfällt, sollte einfach und flexibel ausgeführt werden und zwar auf allen Windows 10 Editionen.

Mit Ivanti DSM haben wir ein leistungsfähiges Werkzeug, mit dessen Hilfe wir die anfallenden Jobs automatisieren können, aber auch hier steckt der Teufel im Detail.

Struktur

Unabhängig davon, was im Einzelnen zu tun ist, bietet es sich an, in DSM ein Softwareset zu bauen.

Das Softwareset kann zum Beispiel immer so aussehen oder bei Bedarf auch weitere Komponenten enthalten:

SWSet - Upgrade Windows 10 auf 1809

  • Patch Scan + Install + Reboot
  • Upgrade-Vorbereitungen 1809
  • Start Upgrade 1809
  • Upgrade-Nachbereitungen 1809
  • Patch Scan + Install + Reboot

Jede einzelne Komponente kann einen oder mehrere Reboots auslösen. Kein Problem - das Softwareset wird solange immer wieder gestartet bis die Installation vollständig durchgelaufen ist oder mit einem Fehler beendet wurde. Das Staging der Komponenten erfolgt bereits am Anfang, also noch unter der alten Betriebssystemversion.

Probleme

Das sieht alles ganz einfach aus, es gibt aber ein paar Knackpunkte - ohne Anspruch auf Vollständigkeit:

  1. Übernahme-Kandidaten
    Damit eine Konfiguration - Datei, Registry-Einträge, Tasks, etc. - von der alten in die neue Installation übernommen wird, muss sie vor dem Start des Setups vorhanden sein.
    Änderungen, die noch im alten Betriebssystem nach dem Abschluss der ersten Setup-Phase (Downlevel Phase), vor dem ersten Reboot, vorgenommen werden, werden nicht übernommen und gehen verloren.

  2. Am Ende des Tunnels
    Der erfolgreiche Abschluss des Pakets "Start Upgrade 1809" - bedeutet nicht, dass alles funktioniert hat. Erfolgreich war bis dahin lediglich der Start - die Downlevel Phase. Danach kann noch jede Menge schief gehen.
    Was am Ende rauskommt - wenn "Upgrade-Nachbereitungen 1809" läuft, kann das gewünschte Ergebnis sein, es kann aber auch wieder die alte Version sein, auf die wegen eines Problems automatisch zurückgerollt wurde.
    Um hier sicher zu gehen, dass das Upgrade tatsächlich erfolgreich war, muss man das prüfen.
    Ist die erkannte Betriebssystemversion die erwartete neue? Ja -> weiter, Nein -> Fehler!

  3. Alles fertig?
    Nein, wenn DSM nach dem Upgrade wieder aktiv wird, dann ist das Upgrade noch nicht fertig!
    Es laufen nämlich auch nach dem letzten Reboot noch eine ganze Reihe von Aktionen bis die neue Betriebssystemkonfiguration vollständig funktionsfähig ist. Vorher funktioniert über weite Strecken noch nicht mal die Netzverbindung. Ungünstig wenn DSM die Policies aktualisieren will oder noch ein paar Pakete herunterzuladen sind.
    Und um es gleich vorweg zu nehmen, direkt einen Reboot auszulösen bevor das Upgrade durch ist, führt regelmäßig zu einem Abbruch des Upgrades und einem Rollback. Und wir wollten eigentlich gar nicht zurück, also besser abwarten.
    Es ist nötig, zu prüfen, ob die Installation auch wirklich fertig ist bevor man weiter macht. Danach kann man rebooten, die nächste Paketinstallation funktioniert aber wahrscheinlich auch ohne das.

Lösungen

Wir müssen also nach dem Upgrade abwarten bis alles fertig ist und bis dahin funktioniert DSM nicht richtig. Das "abwarten bis alles fertig ist" kann DSM also nicht selbst übernehmen, DSM funktioniert zu diesem Zeitpunkt ja noch gar nicht.


Richtig?
Nicht unbedingt.

 

Man kann sicherlich dafür sorgen, dass nach dem Upgrade, z.B. per Scheduled Task ein Script gestartet wird, das dann das Nötige unternimmt um den Fortgang der DSM-Installation sicherzustellen, muss man aber nicht.
Und nachdem auch andere Mechanismen sich mit dem zunächst noch unfertigen Betriebssystem herumschlagen müssen erscheint es mir einfacher, das direkt in DSM zu erledigen.

Eine mögliche Lösung besteht nämlich darin, die Fortsetzung der Installation nach dem Upgrade einfach so lange zu versuchen, bis es klappt. Und zwar so:


Vor dem Start des Upgrade das Service-Pollingintervall verkürzen - ich nehme "alle 5 Minuten". Das lässt sich per Registry Key auch abweichend von den globalen Einstellung in der ICDB konfigurieren. Und das machen wir - siehe 1. - vor dem Start des Upgrades.

Unmittelbar vor dem Start der Upgrade-Installation:

RegModifyDWord('HKEY_LOCAL_MACHINE\SOFTWARE\NetSupport\NetInstall\ServiceSettings','PollingInt','5',mrdwSet)/TS

 

Falls bereits in der Downlevel-Phase etwas schief geht, das ganze vor Verlassen des Pakets wieder rückgängig machen:

RegDeleteKey('HKEY_LOCAL_MACHINE\SOFTWARE\NetSupport\NetInstall\ServiceSettings','PollingInt',)/TS

Nach dem ersten Start des noch nicht fertig installierten, neuen Betriebssystems starten die DSM-Services, fallen aber mangels Netzverbindung und allen möglichen anderen Gründen auf die Nase, d.h. die anstehenden Installationen starten nicht. Macht aber nichts, 5 Minuten später versucht es der Service nochmal. Wieder nichts, egal.
Aber irgendwann klappt's dann auch mit der Installation - ca. 10 Minuten nach dem Start des neuen Betriebssystems ist die Konfiguration und Migration weit genug vorangekommen, dass DSM in der Lage ist das nächste Paket zu starten.
In "Upgrade-Nachbereitungen 1809" wird dann geprüft, ob die Upgrade-Installation abgeschlossen ist (siehe 3.). Und wenn das nicht der Fall ist -> ExitProc Undone, wir versuchen's in 5 Minuten nochmal.
Das Entfernen des Installationsverzeichnisses ist eine der letzten Aktionen des Upgrades - wir benutzen das also als Flag.

If Exist('%SystemDrive%\$WINDOWS.~BT\.')
 ExitProcEx(Undone,'Upgrade still active - retrying at next polling')

Irgendwann ist dann auch die längste Upgrade-Installation durch und es kann weiter gehen.
Und zwar mit der Prüfung des Ergebnisses - siehe Punkt 2.

Set('Desired_Version','10.0.17763')
WMIGetIndexData('\\.\root\cimv2','WIN32_OPERATINGSYSTEM','0','WMI_')
 Version
EndProc
If not %WMI_Version%='%Desired_Version%'
 ExitProcEx(Failed,'ERROR - OS Version = ''%WMI_Version%'' <> ''%Desired_Version%''')
 
Wenn wir die erwartete Betriebssystemversion vorfinden -> gut, wenn nicht -> Fehler. Damit das mit dem Fehler direkt funktioniert, konfigurieren wir dieses Paket so, dass nicht mehr als 1 Installationsversuch unternommen wird - wenn es hier nicht passt, dann ändert sich das auch bei weiteren Versuchen nicht mehr von alleine.
Wenn das Upgrade funktioniert hat, geht's weiter mit weiteren Nachbereitungen, z.B. Reinstallationen von Paketen und am Ende wird nochmal gepatcht und rebootet damit die Maschine sicher auf dem aktuellen Stand ist.

Feedback

Noch etwas unklar?
Probleme?
Andere Ideen und Verbesserungsvorschläge?


Bitte Kommentar hinterlassen!

Kommentar schreiben

Kommentare: 0