In neuem Glanz

von Evgenij Smirnov

In virtualisierten Umgebungen ist die Provisionierung neuer virtueller Maschinen ein Standardvorgang, der oft mehrmals pro Tag oder gar pro Stunde stattfindet. Dabei ist sowohl die schnelle Bereitstellung als auch die Standardisierung der erstellten VMs von größter Wichtigkeit. Nicht selten greifen Administratoren dabei auf das altbewährte "Golden Image" zurück. Wir zeigen Ihnen, wie Sie mit Hyper-V-Bordmitteln Ihren Vorlagen neuen Glanz verleihen.

Die Public-Cloud-Angebote machen es vor: Soll eine neue virtuelle Maschine bereitgestellt werden, erwarten die Fachabteilungen eine schnelle Erledigung statt einer ewigen Diskussion über Konfiguration, Dimensionierung und Platzierung. Und die IT-Security besteht darauf, dass jede neue VM, die in Betrieb genommen wird, von vornherein mit aktuellen Sicherheitspatches und anderen unternehmensrelevanten Konfigurationen versorgt ist (etwa Antiviren-Agent, Kryptographie-Einstellungen und zugelassene Authentifizierungsverfahren).

Bei manuellen Installationen von einem ISO-Image ist dieser Widerspruch kaum aufzulösen. Daher greifen IT-Abteilungen gern zu vorgefertigten VM-Vorlagen und klonen sie bei Bedarf mit den erforderlichen Anpassungen. Umgebungen wie VMware vSphere oder Citrix XenServer halten hierfür fertige Mechanismen bereit. Bei Hyper-V hingegen ist diese Funktionalität dem "System Center Virtual Machine Manager" (SCVMM) vorbehalten. Diesen hat allerdings bei weitem nicht jede IT-Organisation eingeführt, die Hyper-V-Virtualisierung betreibt.

Dennoch ist es auch unter Hyper-V möglich, mit einfachen Mitteln einen auf Vorlagen basierenden Bereitstellungmechanismus zu realisieren. Wir konzentrieren uns in diesem Workshop auf die Bereitstellung von Windows-VMs.

Relikt aus vergangenen Zeiten

Das Konzept des "Golden Image" ist so alt wie die zentralisierte Massenbereitstellung von Betriebssystemen – eine fertige Installation wird geklont und ihre Identität (Name, SID, IP-Konfiguration) anschließend geändert, sprich "individualisiert". Diese Vorgehensweise ist insbesondere im Server- und Infrastrukturbereich nicht unumstritten, denn damit gehen folgende Probleme einher:

- In dem Bestreben, die Anzahl der Golden Images gering zu halten, werden potenziell mehr Features und Programme installiert, als für den konkreten Computer notwendig wären. Eines der prominentesten Beispiele im Serverbereich ist das .NET Framework 3.5, das oft "auf Verdacht hin" mit ausgeliefert wird, jedoch eigene Sicherheitslücken mit sich bringt und weitere Updates erforderlich macht.

- Falsche oder nicht optimale Konfigurationen, die einmal durch das Test- und Abnahmeverfahren für das Golden Image durchgerutscht sind, bleiben lange erhalten und werden bei neu provisionierten Maschinen nach deren Bereitstellung jeweils manuell nachgearbeitet – oder eben auch vergessen.

- Die Pflege eines Golden Image erfolgt klassischerweise manuell, und oft sind nicht alle Konfigurationsschritte protokolliert. Muss das Golden Image einmal neu aufgesetzt werden, besteht die Gefahr, dass nicht alle Konfigurationen denen des Vorgängers entsprechen.

- Bei einem klassischen Golden Image, das über Jahre fortgepflegt wird, sammeln sich Updates und Reste von abgelösten Software-Versionen an, die das Image unnötig aufblähen und auch das Individualisierungsverfahren verlängern und potenziell destabilisieren.

Das Konzept des Golden Image hat jedoch nicht per se ausgedient. Beim Einsatz virtueller Desktops (VDI) oder nicht-persistenter Terminalserver ist eine vorgefertigte Installation unabdingbar. Und auch in der Bereitstellung von Infrastruktur-VMs hat eine "Vorlagen-VM" durchaus ihren Platz – Sie müssen jedoch einen Weg finden, die Anforderungen an Standardisierung und Compliance fest in Ihrem Golden-Image-Prozess zu verankern.

Nutzen Sie Ihre vorhandene Softwareverteilung, um eine vollständig geskriptete Installation der Vorlagen-VM aus einem aktuellen Betriebssystem-Image zu erzeugen. Zumindest für Volume-Licensing-Kunden stellt Microsoft in regelmäßigen Abständen fertig gepatchte Images aller Betriebssysteme zum Download bereit. Auf diese Weise erhalten Sie eine schlankere Vorlage mit verbindlich festgelegter Konfiguration sowie die Möglichkeit, Notfall-Patches und dringende Konfigurationsänderungen schneller einzubauen.

Golden Image in Hyper-V erzeugen

Unabhängig vom verwendeten Verfahren ist der Weg von den Installationsquellen über ein Golden Image hin zu einer fertigen VM immer der gleiche:

- Installation des Betriebssystems.

- Aktivieren der für alle Server notwendigen Rollen und Features wie etwa SNMP, falls Sie dieses für Ihr Monitoring verwenden.

- Deaktivieren der nicht benötigten oder aus Security-Sicht nicht erwünschten Features wie etwa SMB1-Unterstützung und PowerShell 2.0.

- Aktualisieren des Betriebssystems mit Microsoft-Patches.

- Installation zusätzlicher Software, zum Beispiel Backup-, Antivirus- oder Monitoring-Agenten, in der jeweils aktuellen Version.

- Verbindliche Anfangskonfiguration (Zeitdienst, Firewall, RDP, zugelassene Kryptographie et cetera).

- Generalisierung des fertigen Betriebssystems mit Sysprep.

- Kopieren der generalisierten VM.

- Individualisieren der neu bereitgestellten VM mit Angaben wie Computernamen, IP-Adresse, Domänen-Mitgliedschaft et cetera.

- Übergabe der VM an den zukünftigen Nutzer zur finalen Konfiguration, Installation weiterer Rollen oder Drittanbieter-Softwareprodukte und letztendlich zur produktiven Inbetriebnahme.

Die initiale Installation der Vorlagen-VM verläuft genau so wie beim Bereitstellen einer einzelnen VM. Legen Sie mit dem Hyper-V-Manager eine neue VM auf einem Host an. Wählen Sie die CPU- und RAM-Zuweisung so, dass die Installation mit guter Performance verläuft. Für moderne Server-Betriebssysteme sind in der Regel zwei vCPUs und 8 GByte vRAM optimal. Einzig die VM-Generation können Sie beim anschließenden Klonen der Vorlage nicht mehr verändern. Es gibt für moderne Windows-Betriebssysteme kaum mehr einen Grund, sie als Generation-1-VMs zu betreiben [1]. Die einzige Ausnahme sind 32-Bit-Versionen von Windows 10 und Windows 8, falls Sie aus Kompatibilitätsgründen auf ein solches 32-Bit-Betriebssystem angewiesen sind. Auch Windows Server 2008 R2 und Windows 7 erfordern eine Generation-1-VM.

Wählen Sie, wenn möglich, einen vSwitch für die Installation aus, der einem VLAN mit DHCP-Unterstützung entspricht. Auf diese Weise müssen Sie keine fixe IP-Konfiguration in Ihrer Vorlage vornehmen, die über die Vorbereitung hinaus erhalten bleiben und beim Starten mehrerer Klone im gleichen Netz zu Kollisionen führen würde.

Dimensionieren Sie die virtuelle Festplatte so, dass ein typischer Server ohne Drittprodukte dort gut Platz findet. Für Server 2016 oder 2019 sollten 60 GByte als Systempartition in der Regel ausreichend sein. Wenn Sie viele VMs mit großer RAM-Zuweisung haben, sollten Sie erwägen, die Systempartition Ihrer Vorlage von vornherein so groß zu gestalten, dass auch größere Auslagerungsdateien dort Platz finden, ohne dass die Platte vollläuft. Das Gleiche gilt auch, falls die Überwachungsrichtlinien Ihrer Organisation größere Ereignisprotokoll-Dateien vorschreiben. Jedes Ereignisprotokoll kann theoretisch bis zu 2 TByte groß werden, empfohlen sind aber maximal 4 GByte [2].

Ist die VM-Konfiguration fertig, booten Sie sie vom ISO-Image der gewünschten Windows-Version und installieren Sie das Betriebssystem wie gewohnt. Fügen Sie die benötigten Rollen und Features hinzu und patchen Sie die VM von Ihrem WSUS-Server oder über Microsoft Update. Falls Sie in Ihren VMs mehrere Sprachen benötigen, sollten Sie die Sprachpakete möglichst vor dem Patchen hinzufügen.

Mit oder ohne Active Directory

Es gibt in der Deployment-Gemeinde sehr gegensätzliche Ansichten darüber, ob die Vorlagen-VM für ein Golden Image Mitglied im Active Directory sein soll oder nicht. Argumente für das Aufnehmen der Template-VMs ins AD beziehen sich meist darauf, dass dort bereits einige Konfigurationen vorgenommen wurden, die dem Unternehmensstandard entsprechen – bis hin zur Installation von Hilfsprogrammen und Agenten mittels Gruppenrichtlinien. Die Argumentation gegen die AD-Mitgliedschaft zielt meistens auf zwei Punkte ab:

- Zu aggressiv konfigurierte Sicherheitseinstellungen können die Konfiguration und die Generalisierung der Vorlage stören oder gar verhindern.

- Falls später Maschinen ohne AD-Mitgliedschaft geklont werden müssen, etwa für den Einsatz in der DMZ, werden sie die Einstellungen aus dem AD ohnehin nicht behalten.

In der Praxis lassen sich robustere Ergebnisse erzielen, wenn die Vorlagen-VM ohne AD-Mitgliedschaft, aber nach denselben Vorgaben wie die im AD geltenden konfiguriert ist. Entscheiden Sie sich für die AD-Mitgliedschaft, sollten Sie ein genaues Verständnis dafür haben, welche Einstellungen nach Austritt aus dem AD verloren gehen und welche erhalten bleiben.

Um für geklonte Windows-VMs, die nicht Mitglied des Active Directory sein sollen, die gleichen Konfigurationen und vor allem Sicherheitseinstellungen durchzusetzen, können Sie auf die lokale Sicherheitsrichtlinie zurückgreifen. Die im AD bestehenden Gruppenrichtlinien lassen sich mithilfe des Werkzeugs "LGPO.EXE" aus dem Security Compliance Toolkit [3] in eine lokale Sicherheitsrichtlinie konvertieren, die bereits beim Erstellen der Vorlage eingespielt wird und damit gleich nach dem Klonen einer VM in Kraft tritt.

Der Klassiker: ein versiegeltes Image

Beim Massenklonen von Workstations mit Werkzeugen wie Norton Ghost hat sich die Vorgehensweise durchgesetzt, das Originalsystem der Generalisierung (Sysprep) zu unterziehen und das generalisierte Image auf die Zielmaschinen auszubringen. Diese Methode können Sie auch bei virtuellen Maschinen einsetzen. Die Windows-eigene SysPrep.exe hält dafür sogar einen speziellen Modus bereit.

Ist Ihre Vorlagen-VM fertig gepatcht und konfiguriert, führen Sie mit erhöhten Rechten den folgenden Befehl aus:

Der letzte Parameter teilt Sysprep mit, dass es sich nicht mit der Erkennung und Einbindung von Gerätetreibern aufhalten soll, da es sich bei der Zielhardware um die gleiche virtuelle Plattform handelt wie bei der Original-VM. Nach der Generalisierung fährt die VM automatisch herunter und ist dann ihrer Identität beraubt, besitzt also weder einen Computernamen noch eine SID noch Bindungen an Gerätetreiber – diese werden beim nächsten Start neu erzeugt. Nach dem Sysprep dürfen Sie die Vorlagen-VM daher so lange nicht wieder hochfahren, bis Sie die virtuelle Festplatte (VHDX) mit dem "versiegelten" Betriebssystem an einen anderen Speicherort kopiert haben.

Um aus dem versiegelten Image neue produktive VMs zu erzeugen, kopieren Sie die Vorlagen-VHDX an den geeigneten Speicherort in Ihrem Hyper-V-Storage. Legen Sie dann eine neue virtuelle Maschine in Hyper-V an. Sie muss zwingend die gleiche Generation (1 oder 2) wie die Vorlagen-VM aufweisen. Ansonsten kann die Hardware-Ausstattung der VM durchaus von der Vorlage abweichen. Sollten Sie heutzutage noch eine VM-Vorlage für Windows XP oder Server 2003 benötigen, achten Sie bitte darauf, dass die Vorlagen-VM über mehr als eine vCPU verfügt, auch wenn die geklonten VMs in vielen Fällen nur mit einer vCPU ausgestattet werden.

Verbinden Sie im letzten Schritt des Assistenten die Festplattenkopie mit der neuen VM und starten Sie diese anschließend. Die Maschine durchläuft nun die "Out Of the Box Experience" und ist

anschließend bereit zum Konfigurieren. Beides ist standardmäßig ein manueller Vorgang, den Sie bereits von der Einzelinstallation kennen.

Platzsparend: Differencing Disks

Ein Szenario, für das sich das versiegelte VM-Image sehr gut eignet, ist der Einsatz von Differencing Disks. Dabei speichert die virtuelle Festplatte einer VM lediglich die Änderungen ausgehend von einer Basisfestplatte. Letztere muss stets verfügbar sein und es können sich mehrere VMs auf ein und dieselbe Basisfestplatte beziehen. In der Regel finden solche Festplattenkonstrukte nicht in Produktion, sondern in Testszenarien Verwendung, da die Basisfestplatte einen Single Point of Failure für einige oder sogar viele VMs darstellt. Auch die Konzentration von Lese-I/O-Operationen auf eine einzelne Datei ist der Performance der so geklonten VMs nicht unbedingt zuträglich. Aber wenn der Speicherplatz knapp ist und die Performance eine untergeordnete Rolle spielt, können Differencing Disks eine gute Hilfe sein.

Und an dieser Stelle lohnt sich die Systemvorbereitung bereits in der Basisfestplatte: Statt ein und dieselbe Sysprep-Prozedur für jede VM einzeln durchzuführen, sparen Sie Zeit und Arbeit, wenn Sie pro VM nur die Individualisierungsphase mitmachen. Auf die Größe der so entstehenden Differenzplatten hat die frühe Systemvorbereitung übrigens durchaus auch einen Einfluss: Bei einem frisch installierten Server 2019 verursacht ein kompletter Sysprep-Zyklus zirka 5,6 GByte an Differenzplatte, während die Individualisierung ohne Sysprep auf knapp die Hälfte davon kommt.

Für schnelles Provisioning stets aktuelle Vorlagen nutzen

Eines der größten Probleme des klassischen Golden Image ist der eingefrorene Patch-Stand der so entstehenden VMs. Je mehr Zeit seit der Versiegelung des Images verstrichen ist, desto mehr Updates müssen nach der Provisionierung nachgeholt werden. Es wäre also sehr wünschenswert, wenn die Vorlage zu jedem Zeitpunkt aktuell gepatcht zur Verfügung stehen würde.

Die offensichtliche Methode, die Vorlagen-VM nach dem Sysprep wieder einzuschalten und die Individualisierung zu wiederholen, ist nur bedingt zielführend. Offiziell lässt sich ein und dasselbe Windows-System nur maximal dreimal einem Sysprep unterziehen. Es gibt zwar Mittel und Wege, diese Beschränkung zu umgehen, aber sie sind alle mit zusätzlichem Aufwand verbunden. Und der Zweck eines Golden Image ist es ja unter anderem, Aufwand zu reduzieren.

Abhilfe schafft die Hyper-V-spezifische Funktion "Snapshot exportieren". Dabei wird der Snapshot-Baum bis zu dem zu exportierenden Snapshot in die Festplatte der exportierten VM integriert. Die Vorgehensweise im Patch-Zyklus ist also wie folgt:

- Fahren Sie die Vorlagen-VM nach dem Anwenden von Patches, Software-Updates und Konfigurationsänderungen herunter und erzeugen Sie einen Snap-shot (Checkpoint).

- Starten Sie danach die Vorlagen-VM und führen Sie Sysprep mit der Option "/shutdown" durch.

- Nach dem Herunterfahren der VM erzeugen Sie einen erneuten Snapshot.

- Stellen Sie nun den ersten Snapshot wieder her.

Anschließend können Sie den zweiten erstellten Snapshot, der den generalisierten Zustand der VM beinhaltet, exportieren. Das gelingt entweder mit dem Befehl "Exportieren…" im Kontextmenü des Snapshots oder mit dem PowerShell-Befehl Export-VMCheckpoint. Die exportierte VM enthält eine konsolidierte Festplatte ohne Snapshots, die Sie bis zum nächsten Patchday als Golden Image verwenden können. Beim nächsten Updatezyklus wiederholen Sie einfach die obige Prozedur. Denken Sie daran, die älteren Snapshots zu löschen und damit die Snapshot-Festplatten in die Basisfestplatte zu konsolidieren.

Eine andere Variante der "stets aktuellen Vorlage" ist eine Vorlagen-VM, die immer eingeschaltet ist und zeitnah Updates von allen dafür verfügbaren Quellen erhält (Antimalware, Monitoring- und Backup-Agents et cetera). Möchten Sie eine neue produktive VM klonen, fahren Sie die Vorlagen-VM herunter, kopieren die Festplatte, binden sie in eine neue VM-Hülle ein und nutzen dann Sysprep mit anschließender Individualisierung. Beachten Sie bei dieser Vorgehensweise unbedingt, dass die Vorlagen-VM und die frisch erstellte Kopie für einen kurzen Zeitraum denselben Computernamen verwenden.

Handarbeit reduzieren

Für einen erfahrenen Hyper-V- und Windows-Administrator sind die oben beschriebenen Verfahren in beiden Varianten gut nachvollziehbar. Dennoch entspricht diese Vorgehensweise noch lange nicht der Vorstellung eines "One-Click-Deployment" einer neuen Windows-VM. Zum Glück lassen sich alle Operationen auf dem Hyper-V-Host mittels PowerShell automatisieren. Das Anlegen einer neuen VM mit 2 vCPUs und 8 GByte statischem vRAM, die auf der kopierten Vorlagen-VHDX basiert, ist mit vier Zeilen erledigt:

Dennoch müssen Sie alle weiteren Vorgänge innerhalb der VM wie Individualisierung, IP-Konfiguration, Computername und Beitritt zum Active Directory manuell durch interaktive Verbindung zur Konsole erledigen. Um auch diese Vorgänge möglichst zu automatisieren, stehen Ihnen zahlreiche Mittel zur Verfügung.

Zwischen dem Kopieren der virtuellen Festplatte und ihrem Einbinden in die neue VM können Sie die Platte auf dem Host mounten und für den Sysprep-Vorgang eine "unattend.xml"-Datei nutzen, die bereits den gewünschten Computernamen und auch die für den Beitritt zum Active Directory notwendigen Angaben enthält. Der AD-Beitritt funktioniert

natürlich nur, wenn das Netzwerk, an das die VM angeschlossen wird, über DHCP-Adressenvergabe verfügt oder Sie in der unattend.xml-Datei die fixe IP-Konfiguration definieren. Am einfachsten klappt es, wenn Sie eine noch nicht generalisierte Festplatte nehmen und nach dem Kopieren der XML-Datei und dem Einbinden in die VM den folgenden Befehl aufrufen:

Die notwendigen Angaben in der XML-Datei sind im Artikel [4] beschrieben, der auch Musterdateien zum Download beinhaltet.

Wenn Sie sich nicht regelmäßig mit der Automatisierung von Windows-Installationen beschäftigen, könnte der Ansatz mit einem Konfigurationsskript für Sie einfacher zu realisieren sein. Dieses Skript können Sie bereits beim Erzeugen der Vorlage mittels eines geplanten Tasks bei jedem Systemstart laufen lassen. Diese Variante eignet sich gut, wenn Sie den Namen des Windows-Betriebssystems gleich dem Namen der VM setzen möchten und DHCP zur Verfügung steht. Das Skript vergleicht bei jedem Start den Systemnamen mit dem Namen der VM, welchen Sie aus dem Registrierungswert "HKLM/SOFTWARE/Microsoft/Virtual Machine/Guest/Parameters/VirtualMachineName" bestimmen können. Stimmt der Name nicht überein, so muss das Gast-Betriebssystem umbenannt werden. Ist der Name identisch, kann das Skript mit weiteren Konfigurationen fortfahren.

Sie können auch PowerShell Direct [5] einsetzen, um Befehle innerhalb der VM auszuführen. Dieses ist standardmäßig aktiviert. Dafür muss die Maschine jedoch den Sysprep-Prozess bereits absolviert haben.

Klonhilfe aus dem Browser

Eine kostenfreie Möglichkeit, den Klonvorgang eines Golden Image mittels einer grafischen Oberfläche abzubilden, bietet das Windows Admin Center [8]. Seit einigen Versionen bietet die Hyper-V-Extension des webbasierten Verwaltungs-Tools die Funktion "Klonen". Diese befindet sich zwar noch im Preview, funktioniert aber bereits zuverlässig. Dabei wird nicht nur der Inhalt der Festplatte, sondern auch die Konfiguration der Vorlagen-VM übernommen.

Das Klonen findet unter der Haube mittels eines Exports der VM statt und beherrscht sogar das Zusammenführen von Snapshots, falls die Vorlagen-VM über Checkpoints verfügt. Dies geschieht jedoch nicht beim Exportieren, sondern in einem separaten Vorgang vor dem Importieren. Zudem können Sie dabei nicht einen bestimmten Snap-shot zum Klonen auswählen.

Vorsicht ist geboten, falls Sie die Vorlagen-VM nicht dem Sysprep unterzogen haben. Dies holt nämlich das Windows Admin Center automatisch nach, womit die Vorlagen-VM – gegebenenfalls ungewollt – am Ende den generalisierten Zustand besitzt. Produktive VMs sollten Sie mit diesem Vehikel jedenfalls nicht klonen, sondern nur dedizierte Vorlagen. Mit der aktuellen WAC-Version 2009 funktioniert das Klonen nicht vorbereiteter VMs allerdings nicht. Sie müssen zwingend bestätigen, dass Sysprep bereits ausgeführt wurde, womit die Vorlagen-VM nicht verändert wird.

Fazit

Microsoft bietet bei reinem Hyper-V-Einsatz ohne den Virtual Machine Manager keinen Vorlagenmechanismus zum Bereitstellen neuer VMs. Dennoch ist es möglich, mithilfe von Golden Images das Provisionieren zu beschleunigen und die Konfiguration erzeugter VMs zu standardisieren. Sie sollten sich dafür mit dem Sysprep-Prozess und der Deployment-Automatisierung von Windows auseinandersetzen. Das Beherrschen der PowerShell ist dabei von großem Vorteil, denn damit können Sie sowohl die Operationen am Hyper-V-Host als auch solche innerhalb der geklonten VM steuern. Für ein schnelles Klonen einer mit Sysprep vorbereiteten Vorlage kann das Windows Admin Center wertvolle Dienste leisten.

Golden Image für Hyper-V