Nachdem nun endlich meine neue Hardware geliefert wurde kann meine Migration auf Windows Server 2019 starten!

Im ersten Schritt soll ein neuer Hyper-V-Server bereitgestellt werden, damit für die weiteren Migrationen genügend Ressourcen zur Verfügung stehen.

Aktuell besteht meine Infrastruktur aus den beiden Hyper-V-Hosts WS-HV1 und WS-HV2. Beide laufen mit Windows Server 2016. Der neue Server soll Windows Server 2019 ausführen. Für das neue Betriebssystem wird neue Hardware angeschafft. Somit ist also ein Side-By-Side-Migrationsszenario möglich:

• Der neue Server wird als WS-HV3 eingerichtet
• alle VMs von WS-HV werden auf WS-HV3 verschoben
• Die Hardware von WS-HV2 wird aus dem Serverschrank ausgebaut.
• Die neue Hardware von WS-HV3 wird in den Serverschrank integriert.

Die neue Plattform weist einen anderen Prozessor auf. Daher ist keine LiveMigration möglich. Alle VMs müssen während der Verschiebung ausgeschaltet sein. Da aber alle wichtigen Services von redundanten VMs betrieben werden sollte es keine Dienstunterbrechungen geben.

Der neue Server verfügt über kein DVD-Laufwerk. Über USB möchte ich auch nicht installieren. Daher muss ich im Vorfeld in meinem Windows Deployment Service das aktuelle Image vom Windows Server 2019 integrieren.

Das Image wird ganz klassisch im WDS bereitgestellt:

Ich verwende nur die grafische Variante in der Verteilung über meinen WSUS:

Und auf die gleiche Weise füge ich das neue Boot-Image dazu. Mein WDS kann nur mit einem bestimmten Account verwendet werden. Dieser ist deaktiviert. Für die Installation aktiviere ich ihn temporär:

Die Installation des Betriebssystems möchte ich mit UEFI-SecureBoot via PXE ausführen. Dazu kontrolliere ich die UEFI-Einstellungen des neuen Servers.

Und dann geht’s auch schon los:

Hier kommt nun mein WDS-Benutzeraccount zum Einsatz:

Das war keine große Sache.

Die Installation der Treiber war ebenfalls ein Standardtask. Updates für das Betriebssystem holte ich mir von Microsoft im Internet. Die Installation ging sehr schnell. Während der Installation bereitete ich die Partitionen auf den Datenträgern vor.

Nun fehlte noch die Integration in die Domain. Der neue Name des Servers soll WS-HV3 lauten. Nach dem erfolgreichen DomainJoin platzierte ich das Computerkonto in der richtigen OU:

Der Server verwendet derzeit 3 Netzwerkkarten. Für das Servermanagement bekommt er die feste IPv4 192.168.110.41/24. Zusätzlich benenne ich die Netzwerkadapter um:

Die eigentliche Aufteilung in Netzwerkteams erfolgt später.

Nun werden die Rollen- und Feature installiert:

Nach dem Neustart steht der Hyper-V-Service bereit.

Die Netzwerkkonfiguration wird nun verfeinert. 2 der Adapter sollen mit einem Netzwerkteam an einen Hyper-V-Switch gebunden werden. Der 3. Adapter soll direkt an einem vSwitch gebunden sein. Im Bereich Teaming fallen mir keine Unterschiede zu Windows Server 2016 auf:

Auch im Hyper-V-Manager gibt es keine großen Veränderungen. Der vSwitch lässt sich wie gewohnt erstellen. Wichtig ist für die Bestands-VMs, dass die Namen der alten vSwitches im neuen Server identisch sind.

• ich erstelle den vSwitch LAN-100 auf dem NIC-Team-Adapter:
  
• ich entferne die IPv4 192.168.100.41/24 von NIC1 und konfiguriere diese IPv4 auf dem vSwitch-Port des neuen teamed-Switches
• ich erstelle den vSwitch LAN-110,DMZ auf dem internen Adapter:
  

Nun fehlen noch einige grundlegende Hyper-V-Einstellungen:

Für die Verschiebung der alten VMs auf den neuen Server müssen beide Hyper-V-Hosts vorbereitet werden. Im WS-HV2 (alt) ändere ich die Einstellungen für die LiveMigration auf Kerberos, da alle administrativen Accounts Mitglied der Gruppe „Protected Users“ sind. Und diese können kein CredSSP verwenden:

Dazu muss aber auch dem DomainController mitgeteilt werden, dass Anmeldeinformationen zwischen den Hosts delegiert werden sollen:

Für einen Testlauf sollte meine PKI-VM herhalten. Diese muss ausgeschaltet sein, da die Hardware-Plattform beider Hosts unterschiedlich ist. Der erste Lauf schlägt fehl, da ich im WS-HV3 (neu) die Option „LiveMigration“ vergessen hatte. Aber nun funktioniert es:

Die VM lässt sich auf dem neuen Host einfach wieder einschalten. Die VM ist anschließend im Netzwerk erreichbar:

Nun sind die anderen VMs dran. Diese möchte ich nicht von Hand ausschalten, verschieben und wieder einschalten. Da hilft die PowerShell:

Einige Stunden später sind alle VMs auf der neuen Hardware angekommen.

Der alte Server hatte noch eine zusätzliche Festplatte verbaut, auf der einige Daten abgelegt waren. Diese hab ich in den neuen Server umgebaut.

WS-HV2 war Mitglied in einem Hyper-V-FailoverCluster zusammen mit WS-HV1. Der Cluster wird nicht mehr benötigt. Daher nahm ich zuerst WS-HV2 als Knoten heraus und entfernte abschließend auf WS-HV1 den Cluster.

Nun musste der neue Server in den Serverschrank eingebaut werden. Dazu entfernte ich zuerst WS-HV2.

Die Partitionierung auf dem neuen Hyper-V-Host wollte ich noch etwas anpassen. Da ich unterschiedliche Speichertypen mit sehr unterschiedlichen Geschwindigkeiten verbaut habe, verlangte es nach einer neuen Speicherplatzbereitstellung:

Tier-Gold ist ein Volume auf einer Corsair Force MP600 (NVMe am PCIe Gen4). Tier-Silver ist eine ältere Samsung NVMe, Tier-Bronce eine normale Samsung-SSD und das Datenlufwerk ist eine normale HDD. So kann ich alle Daten nach deren Geschwindigkeitsanforderung gezielt ablegen.

Dann kam natürlich noch die Einbindung in mein Monitoring. Hier setze ich auf PRTG:

Die Integration in die Datensicherung war auch recht einfach. Dafür habe ich eine scriptgesteuerte Variante des integrierten Windows Backups. Virtuelle Maschinen erhalten eine Gastsicherung. Lediglich die VM-Konfigurationsdateien werden über einen robocopy-Task gesichert. Dieser war aber ebenfalls schnell wieder importiert:

Dann richtete ich noch einen Notfall-Account ein, mit dem ich die grundlegenden Dienste nach einem Ausfall der gesamten Infrastruktur wieder reaktivieren kann (das ist ein auf diesen Host beschränkter Benutzeraccount, der keine Verbindung zu einem DomainController benötigt und nach einer Anmeldung nur VMs einschalten darf).