Inhaltsverzeichnis
Zielsetzung
Bei meiner letzten Migration konnte sich mein neuer Server nicht mit den Updates meines WSUS aktualisieren. Sei Patchlevel war zu alt bzw. der WSUS hatte die dafür erforderlichen Updates nicht mehr gespeichert. Daher musste ich den Server gegen das Internet aktualisieren.
Da ich noch weitere neue Server benötige, möchte ich mein Basis-Image aktualisieren. Technisch betrachtet ist das Image nichts weiter als ein vorbereitetes Windows Server 2019 System, das ich in einer VHDX-Datei generalisiert habe.
Meine aktuelle Basefile hat das Patchlevel 2019-08. Mit dieser Aktualisierung komme ich auf das Patchlevel 2020-05.
Erstellen einer neuen Basefile
Zuerst erstelle ich einen neunen virtuellen Computer in meinem Hyper-V-Host:
Das aktuelle Basefile verwendet UEFI für den Start. Daher muss die VM mit der Generation 2 konfiguriert werden:
Mehr Arbeitsspeicher kann die Aktualisierung beschleunigen:
Die neue VM muss ins Internet kommunizieren können. Daher patche ich sie in mein Client-Netzwerk:
Die VHDX konfiguriere ich im Anschluss:
Jetzt kopiere ich die alte Basefile in den Ordner der neuen VM. Falls etwas schief läuft, habe ich immer noch das vorherige Image:
Die VHDX benenne ich im Windows Explorer um. Danach integriere ich sie in der neuen VM. Das Client-Netzwerk verwendet ein VLAN. Ebenso passe ich die Anzahl der vCPU an:
Die Startreihenfolge würde mit der Netzwerkkarte beginnen, da ich die virtuelle Festplatte erst später integriert habe. Das verlangsamt den Start. Daher passe ich das an:
Jetzt kann ich die VM starten. Der Windows Server 2019 durchläuft die Grundkonfiguration:
Den Productkey gebe ich nicht ein:
Nach der Eingabe des Passwortes kann ich mich anmelden. Der neue Server erhält eine IP-Adresse von einem meiner DHCP-Server:
Da ich bei jedem Server die Windows Server Sicherung benötige, werde ich diese im neuen Basefile vorab installieren. Das geht einfach im Server Manager. Zusätzlich installiere ich System Insights für das Windows Admin Center:
Nach der Feature-Installation und einem Neustart geht es auf Update-Suche. Diese wird direkt gegen den Online microsoft Update Service ausgeführt. In meinem Client-Netzwerk ist das freigeschaltet:
Die Updates werden aus dem Internet heruntergeladen und installiert:
Praxistipp: Dennoch muss man beachten, dass der Kontakt mit dem öffentlichen Update Service von Microsoft alle verfügbaren Updates installieren wird. Da können natürlich auch fehlerhafte oder nicht getestete Updates dabei sein. Alternativ können die Updates auch manuell über den Windows Update Katalog heruntergeladen werden. Da hat man die genaue Kontrolle. Zudem wäre dieser Prozess ohne eine Internetverbindung vom neuen Server aus möglich. Das ist mir aber aktuell zu viel Aufwand. Zudem installiere ich über den WSUS eh alle Updates. Also spare ich mir den Mehraufwand. Die Updates wurden installiert: Nachdem Neustart prüfe ich auf mögliche Folgeupdates. Hier gibt es aber nichts zum Nachholen: Ebenso kontrolliere ich den Stand der Windows Defender Signaturen. Auch diese wurden erneuert:
Die Updates beziehe ich nicht von meinem WSUS-Server. Sollten bei diesem Server durch Überlagerungen oder Bereinigungen ältere Updates fehlen, dann könnten ggf. neuere Updates ignoriert werden. Das passiert, wenn das neuere Update ein älteres, nicht mehr vorhandenes Update als Voraussetzung hat. Leider werden diese neueren Updates dann wirklich ignoriert und der neuen Server meldet ein „Up-to-date“ – was definitiv nicht stimmt!
Optional könnte man an dieser Stelle wieder zusätzlichen Speicherplatz freigeben:
Dieser Prozess hat mir aber zu lange gedauert. Daher habe ich ihn beendet. Zum Abschluss generalisiere ich das Betriebssystem mit sysprep.exe. Dabei werden viele Individualmerkmale entfernt und der Server geht beim nächsten Start in den Out-Of-Box-Experience Mode (OOBE) über. Er wird die Hardware neu kennenlernen und die Ersteinrichtung starten. Das ist Perfekt für eine Vervielfältigung. Sysprep ist einfach zu bedienen:
Nach der Generalisierung fährt der Server wie gewünscht herunter. Die neue Basefile ist etwas größer als die vorherige:
Wer mag, kann die VHDX noch verkleinern. Das geht bequem mit dem Hyper-V-Manager:
In meinem Fall hat es nur 100MB freigegeben. Aber es hat auch nicht lange gedauert:
Die neue Basefile verschiebe ich in mein Repository:
Und dann muss ich nur noch etwas aufräumen. Die temporäre VM benötige ich nicht mehr:
Ebenso lösche ich den Ordner der VM:
Zusammenfassung
Der Prozess ist nicht schwer. Natürlich gibt es auch die Offline-Variante mit dism, aber die ist manueller und daher durchaus zeitaufwändiger.
Und noch einige Hinweise:
- Vor der Generalisierung könnten weitere Anpassungen erfolgen. Z.B. könnte ein anderer Virenscanner installiert werden. In diesen Fällen müssen die Anpassungen ggf. für die Generalisierung vorbereitet werden. Viele AV-Hersteller haben da beispielsweise eigene Verfahrensanleitungen. Prüft das bitte vorab.
- Beim Kontakt mit der Infrastruktur können weitere Spuren die Generalisierung überleben. Der WSUS-Kontakt speichert in der Registry eine SUSID ab. Diese muss unbedingt entfernt werden, da sonst alle neuen Server im WSUS im gleichen Computerobjekt auftreten.
Den Artikel gibt es hier wieder als PDF-Datei zum downloaden.
Stay tuned!
Hier geht es zum Übersichtsbeitrag meiner Serie „Migration auf Windows Server 2019“