Wiki: Schlanke Basis VHDx Datei für Hyper-V erzeugen

Schlanke Basis VHDx Datei für Hyper-V erzeugen

Für unsere Schulungs- und Testumgebungen benötige ich immer wieder die gleichen Bausteine. Eine Basis-VHDx Datei mit Windows Server 2016 und eine Basis-VHDx Datei mit Windows 10, damit ich in Hyper-V schnell eine Schulungs- bzw. Testumgebung aufsetzen kann.

Der normale Weg für viele ist: Einfach mit einer .iso-Datei den Server installieren, Scripte drauf, Software installieren UND Windows Update laufen lassen und auf den aktuellsten Stand patchen. Anschließend wird noch eine Unattend.xml reinkopiert und Sysprep gestartet, die VM heruntergefahren und auf die Seite gelegt für die spätere Verwendung.

Für mich hat die Sache nur einen Hacken. Die VHDx-Dateien werden durch den Aufruf von Windows Update massiv aufgebläht (von 15GB auf bis zu 30GB) und benötigen damit viel Platz und es dauert entsprechend länger beim kopieren auf die Zielsysteme (bei uns Schulungsnotebooks).

Daher habe ich mir eine andere Vorgehensweise überlegt, die das ganze Procedere und die Pflege der VHDx-Dateien vereinfacht.

Um eine schlanke virtuelle Maschine (VM) als Basis für Testumgebungen zu erstellen gehe ich normalerweise folgendermaßen vor:

Wir benötigen eine .iso Datei von Windows Server 2016 bzw. die install.wim, die sich auf der DVD befindet. In der install.wim sind die eigentlichen Installationen bzw. Installations-Images enthalten.

Die .iso-Datei kann per Doppelklick gemountet werden und tauch dann mit einem Laufwerksbuchstaben im Windows Explorer auf.
Als nächsten benötigen wir eine Powershell mit administrativen Rechten.

Mit dem Befehl: Get-WindowsImage -ImagePath g:\sources\install.wim ...kann man sich den Inhalt der Datei anzeigen lassen.

Es gibt ein tolles Powershell Script, dass einem die Erstellung der VHDx-Datei fast vollständig abnimmt und viele Parameter zur individuellen Konfiguration der späteren Installation mitbringt. Das Script heißt: Convert-Windowsimage.ps1 und kann in der Powershell Gallery unter https://gallery.technet.microsoft.com/scriptcenter/Convert-WindowsImageps1-0fe23a8f heruntergeladen werden.

Das Script muss als Funktion geladen werden und kann nicht direkt aufgerufen werden.

Achtung! Es gibt einen Bug ab windows 10 1709 bei dem eine Fehlermeldung generiert wird: "ERROR: Ausnahme beim Aufrufen von "Apply" mit 1 Argument(en): "Das Verzeichnis oder die Datei kann nicht erstellt werden" bzw. auf englischen Systemen: ERROR : Exception calling "Apply" with "1" argument(s): "The directory or file cannot be created". Ich erledige diese Aufgaben meist ein einem Windows Server 2016 :-)

Mit: . .\Convert-WindowsImage.ps1 (sprich: Punkt Leerzeichen Punkt Backslash) wird das Script als Funktion geladen und kann anschließend als Befehl Convert-Windowsimage verwendet werden.

Ein Beispiel würde lauten:

Convert-WindowsImage -SourcePath "G:\sources\install.wim" -Edition "Windows Server 2016 Datacenter Evaluation (Desktopdarstellung)" -VHDPath F:\vhdx\SRV2016Eval.vhdx -SizeBytes 120GB -VHDFormat vhdx -VHDType Dynamic -VHDPartitionStyle GPT -ExpandOnNativeBoot:$false -UnattendPath "F:\scripte\Unattend.xml"

Dieser Befehl wird aber mit einer Fehlermeldung quittiert. Leider kann nicht die Bezeichnung verwendet werden, die wir mit dem Befehl Get-WindowsImage erhalten haben. Wir müssen die "interne" Bezeichnung verwenden. Netterweise "verrät" uns das Script die möglichen Werte, wenn wir den oben genannten Befehl OHNE den Parameter "-Edition" aufrufen. Es wird dann folgendes angezeigt:

ERROR : You must specify an Edition or SKU index, since the WIM has more than one image.
ERROR : Valid edition names are:
ERROR : ServerStandardEvalCore
ERROR : ServerStandardEval
ERROR : ServerDataCenterEvalCore
ERROR : ServerDataCenterEval
ERROR : ScriptHalted

Mit angepasstem -Edition Parameter klappt es:

Convert-WindowsImage -SourcePath "G:\sources\install.wim" -Edition ServerDataCenterEval -VHDPath F:\vhdx\SRV2016Eval.vhdx -SizeBytes 120GB -VHDFormat vhdx -VHDType Dynamic -VHDPartitionStyle GPT -ExpandOnNativeBoot:$false -UnattendPath "F:\scripte\Unattend.xml"

Alternativ kann bei dem Parameter "-Edition" auch der Index verwendet werden. Hier in meinem Beispiel die "4".

Bei erfolgreichem Abschluss erhalten wir eine bootfähige VHDX-Datei, die direkt als Hyper-V VM gebootet werden kann. Die Größe beträgt ca. 9,4GB.

Windows Defender deinstallieren:

Da in Schulungs- und Testumgebungen häufig mehrere Server-VMs auf normalen Notebooks bzw. Rechnern laufen, die nicht die Leistung eines professionellen Servers haben, entferne bzw. deinstalliere ich das Feature Windows Defender, also den eingebauten Virenscanner von Windows Server 2016. Das geht ebenfalls recht einfach mit einem Powershell Befehl:

Anzeigen lassen:

Get-WindowsFeature -Vhd "D:\vhdx\SRV2016Eval.vhdx" -Name *defender*

Ergebnis:
Display Name Name Install State
------------ ---- -------------
[X] Windows Defender-Features Windows-Defender-Fea... Installed
[X] Windows Defender Windows-Defender Installed
[X] GUI für Windows Defender Windows-Defender-Gui Installed

Windows Defender entfernen:

Remove-WindowsFeature -Vhd "D:\vhdx\SRV2016Eval.vhdx" -Name Windows-Defender-Features

Hinweis: Analog können die Binärdateien für diverse Rollen und Features hinzugefügt werden, z.B. das Windows Backup mit:
Install-WindowsFeature -Vhd "D:\vhdx\SRV2016Eval.vhdx" -Name Windows-Server-Backup

usw....

Windows Updates zum Image hinzufügen

Da die VHDx-Datei direkt von der DVD erstellt wurde hat diese Installation den Patchlevel Windows Server 2016 RTM und muss aktualisiert werden. Ich glaube jeder hat schon einmal frustriert vor dem Bildschirm gesessen und stundenlang auf die Fertigstellung der Windows Updates gewartet. Das wollen wir uns ersparen.

Ich lade die aktuellen "Cummulative Updates" für die Server und Workstations direkt bei Microsoft unter http://www.catalog.update.microsoft.com/Home.aspx herunter und füge sie der VHDx-Datei hinzu.

Bild: catalog-update-microsoft.PNG einfügen

WICHTIG: Abhängigkeiten beachten!

Wenn eine frische Installation von Windows Server 2016 online per Windows Update aktualisiert wird, wird z.B. erst das Cummulative Update 2018-05 heruntergeladen, dann wird erst das Cummulative Update 2018-12 heruntergeladen und installiert. Das dauert eine halbe Ewigkeit. Der Grund ist folgender: Im Update 2018-05 ist ein spezieller Update für den Windows Installer bzw. für Windows Update selbst, der IMMER zuerst installiert werden muss bevor ein neueres Update eingespielt werden kann.

Ein direkte Einspielen der 2018-12er Updates wird mit der tollen Fehlermeldung quitiert: ...diese Update ist nicht für dieses System geeignet. Das bringt einen nicht wirklich weiter. erst wenn man bei Microsoft nach den Abhängigkeiten schaut bekommt man diese Information.

Die Lösung ist einfach: Als erstes wird das "eigenständige" Update 2018-05 SSU-Update für Windows Server 2016 für x64-basierte Systeme (KB4132216) eingespielt (nur 11MB groß), danach kann das 2018-12 Cumulative Update for Windows Server 2016 for x64-based Systems (KB4483229) hinzugefügt werden.

Vorgehensweise:

Mounten der VHDx-Datei per Doppelklick

Add-WindowsPackage -PackagePath "D:\MSUpdates\2018-05 SSU-Update für Windows Server 2016 für x64-basierte Systeme (KB4132216).msu" -Path K:\

Add-WindowsPackage -PackagePath "D:\MSUpdates\2018-12 Cumulative Update for Windows Server 2016 for x64-based Systems (KB4483229).msu" -Path K:\

Anschließend kann die Datei prima als Basis-VHDx für diverse virtuelle Maschinen verwendet werden. Sollten später neue Cummulative Updates eingespielt werden, wird eben das aktuelle auf die gleiche Art und Weise hinzugefügt.

Die Größe der VHDx-Datei ist durch das hinzufügen der Update auf 13,9GB angewachsen. Bei meinen letzten Tests mit Windows Update stieg die Größe der VHDx-Datei auf fast 30GB. Klar man muss dazu sagen, dass die Auslagerungsdatei einer gestarteten VM natürlich enthalten ist, was bei der nicht gestarteten VHDx-Datei wegfällt.

Wiki: Hyper-V Replikation

In diesem Artikel möchte ich die notwendigen Schritte zeigen, die notwendig sind, um eine oder mehrere virtuelle Maschinen von einem Hyper-V Host zu einem zu replizeren.

Grundsätzlich kann man drei Fälle unterscheiden:

Replikation zwischen zwei Hosts, die nur in einer Arbeitsgruppe sind
Replikation zwischen zwei Servern, die Mitglied der gleichen Domäne sind
Replikaton zwischen zwei Servern bei dem einer oder beide Mitglied eines Failoverclusters ist/sind.

Wir werden alle drei Fälle beschreiben.

Replikation zwischen Hosts einer Arbeitsgruppe

Eine IP-Kommunikation und Namensauflösung zwischen beiden Hosts muss gegeben sein. Notfalls durch Einträge in der Hostsdatei.

Die etwas problematischere Sache ist die Authentifizierung der beiden Hosts, die auf Basis von Zertifikaten erfolgen muss. Sind die Hosts in der gleichen Domäne Mitglied kann die Authentifizierung auf Basis von Kerberos erfolgen.

Es müssen also für beide Hosts Computerzertifikate erzeugt und installliert werden. Um diese Zertifikate zu erhalten gibt es verschiedene Möglichkeiten:

Mit Hilfe von makecert.exe
Mit dem Tool XCA
Mit Hilfe einer Windows Zertifizierungsstelle

Die einfachste Variante wird mit dem Microsoft Tool makecert.exe eingerichtet. Das unter:

https://blogs.microsoft.co.il/files/folders/applisec/entry75829.aspx heruntergeladen werden kann.

Als erstes muss ein Root Zertifikat bzw. eine Root Zertifizierungsstellenzertifikat erzeugt werden:

Achtung die Kommandozeile mit der die Befehle aufgerufen werden muss administrative Rechte haben.

cmd.exe

makecert.exe -n "CN=Hyper-V Test CA,O=Testifari AG,OU=IT,L=Nuernberg,S=By,C=DE" -pe -ss my -sr LocalMachine -sky exchange -m 96 -a sha1 -len 2048 -r HyperVTestCA.cer

Das Zertifikat muss zu den Vertrauenswürdigen Stammzertifizierungsstellen hinzugefügt werden:

certutil.exe -f -addstore Root HyperVTestCA.cer

Das Rootzertifikat sollte spätere Verwendung exportiert bzw. gesichert werden.

certutil.exe -privatekey -exportpfx "Hyper-V Test CA" HyperVTestCA.pfx

Auf der Kommandozeile sieh das bisher folgendermaßen aus.

Als nächstes müssen die Computerzertifikate erzeugt werden:

makecert.exe -n "CN=WS38" -pe -ss my -sr LocalMachine -sky exchange -m 96 -in "Hyper-V Test CA" -is my -ir LocalMachine -a sha1 -eku 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 WS38.cer

----------

makecert.exe -n "CN=WS39" -pe -ss my -sr LocalMachine -sky exchange -m 96 -in "Hyper-V Test CA" -is my -ir LocalMachine -a sha1 -eku 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 WS39.cer

Die Zertifikate müssen noch exportiert werden.

certutil.exe -privatekey -exportpfx "WS38" WS38.pfx

certutil.exe -privatekey -exportpfx "WS39" WS39.pfx

Der ganze Vorgang wurde unter Windows 8.1 Pro durchgeführt, es ist also kein Server oder eine spezielle Konfiguration notwendig. Alle Zertifikate liegen in der lokalen Zertifikatsverwaltung des System auf dem sie erstellt wurden und können bei Bedarf nochmal über die GUI exportiert werden.

Hinweis:

Die werdendete Kennung (OID) 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 beschreibt den Zweck des Zertifikats. Hier eine kleine Liste wichtiger OIDs:

Encrypting File System (1.3.6.1.4.1.311.10.3.4)

Secure Email (1.3.6.1.5.5.7.3.4)

Smart Card Logon (1.3.6.1.4.1.311.20.2.2)

Client Authentication (1.3.6.1.5.5.7.3.2)

Server Authentication (1.3.6.1.5.5.7.3.1)

IP security IKE intermediate (1.3.6.1.5.5.8.2.2)

Zertifikate importieren

Als nächstes muss das Root-Zertifikat auf den Hosts bei den vertrauenswürdigen Stammzertifikaten und die Computerzertifikate bei den "Eigenen Zertifikate" importiert werden.

Auf dem Hyper-V Host sollte das am Ende so aussehen:

Zertifikatssperrlistenprüfung deaktivieren

Die mit makecert.exe erstellten Zertifikate haben einen Nachteil: Sie enthalten keinen Zertifikatssperrlistenpfad. Hyper-V bemängelt das und weigert sich das Zertifikat zu verwenden.

Diese Sperrlistenprüfung kann in der Registry unter:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication

abgeschaltet werden, indem ein REG_DWORD Wert (32Bit) mit dem Namen "DisableCertRevocationCheck" und dem Wert 1 erstellt wird.

Konfiguration der Replikation

Im Hyper-V Manager muss nun die Replikation aktiviert werden: Hyper-Manager - Hyper-V-Einstellungen - Replikatskonfiguration

Ist das richtige Zertifikat auf beiden Servern ausgewählt, muss noch entschieden werden, ob von beliebigen authentifizierten Servern Replikate empfangen werden oder nur von bestimmten:

Sperrprüfung ausschalten:

Wie bereits zuvor angesprochen erhalten wir eine Fehlermeldung, da die Sperrlisstenprüfung fehlgeschlagen ist:

Zum Schluss wird noch ein Hinweis angezeigt, dass an der Firewall Port 443 geöffnet sein muss.

Replikation einer VM einrichten:

Im Hyper-V Manager kann im Kontextmenü der virtuellen Maschine die Replikation eingerichtet werden.

Einige der folgenden Schritte im assistenten sind selbssterklärend, daher beschreibe ich hier nur die wichtigen Punkte.

Der Replikationsserver muss angegeben werden. Zu beachten ist, wenn wegen der Namensauflösung durch DNS eine echter FQDN verwendet wird müssen die "commen names" im Zertifikat entsprechen angepasst bzw. erstellt werden.

Nach Überprüfung bzw. authentifiezierung des Partnerservers muss das eigene Zertifikat ausgewählt werden.

Im nächsten Schritt werden die zu replizierenden Festplatten ausgewählt. Je nach Leitungsgeschwindigkeit sollte folgendes beachtet werden:

Im Alltag werden oft Daten auf den Server kopiert, die nur temporär benötigt werden oder man kopiert z.B. Datenbanken in ein Temp-Verzeichnis um eine Kopie zu haben falls bei einem Update bzw. Upgrade etwas schiefgeht. Oft werden diese Daten dann aber vergessen. Die VHD/VHDX-Datei wurde dadurch vergrößert und wird entsprechend repliziert.

Wenn nun 50GB temporär auf den Server kopiert wurden müssen auch 50GB repliziert werden. Selbst bei einer bei einer 10MBit-Leitung dauert das entsprechend lange. und ist vor allem völlig unnötig.

Daher empfehle ich immer auf dem Server eine eigene virtuelle Festplatte anzufügen, die NICHT repliziert wird und auf der problemlos solche unwichtigen Daten kurzfristig abgelegt werden können.

Die Replikation wird inkrementell, blockbasiert durchgeführt. Je nach Anwendungsszenario muss der Replikationsintervall festgelegt werden.

Um mehrer Zustände aktivieren zu können isst es möglich mehrere Wiederherstellungspunkte erzeugen zu lassen.

Um Replikation auch mit Internetleitung von "Normalmenschen" zu ermöglichen, kann das erste Replikat auch auf eine USB-Festplatte kopiert und am Zielort wieder eingespielt werden.

Nach Fertigstellung des Assistenten werden im laufenden Betrieb die ausgewählten Festplatten mit Hilfe von VSS auf die USB-Festplatte kopiert.

Am Zielserver ist das Objekt "virtuelle Maschine" bereits erstellt worden, nur ohne Daten, die jetzt importiert werden können.

Die Daten weden in den vorher konfigurierten Ordner kopiert.

Leider sind die Datenstrukturen nicht mehr ganz so übersichtlich wie vorher.

Die Festplattenpfade sind nciht mehr schön anzusehen, aber es ist ja auch nur für den Notfall.

Testfailover durchführen

Eine interessante Option ist der "Testfailover", bei dem ein beliebiger Wiederherstellungspunkt ausgewählt und dadurch eine Kopie der virtuellen Maschine erstellt wird, die zu Testzwecken hochgefahren und geprüft werden kann.

Man wählt den entsprechenden Wiederherstellungspunkt aus...

Und erhält dann eine Kopie der virtuellen maschine. Sinnvollerweise ist die Netzwerkkarte in der Kopie-VM nicht verbunden, damit es in keinem Fall zu einem Netzwerkkonflikt kommen kann.

Erweitern der Replikation

Ein Feature das seit Hyper-V 4.0 (Server 2012 R2) hinzugekommen ist, ermöglich die Replikation eines Replikates auf eine weiteren Server. Also ein Replikat vom Replikat...