Probieren geht über Studieren

von Raimund Andrée Dr. Jens Söldner

Bevor neue Anwendungen, Dienste oder Hardware ihren Weg in die produktive IT finden, steht der Administrator in der Regel vor der Aufgabe, diese zu testen. Doch dies hat es oft in sich, denn es gilt, Konfigurationen exakt nachzustellen und auch Abhängigkeiten zu berücksichtigen. Viel Zeit spart dabei der kostenlose Dienst AutomatedLab, mit dem IT-Verantwortliche Testumgebungen unter Hyper-V oder für die Azure-Cloud zügig an den Start bringen.

Das Nachstellen komplexer IT-Infrastrukturen im Labor gehört zur täglichen Arbeit von Administratoren und IT-Beratern. Allerdings ist der Aufbau und die Pflege einer solchen Umgebung mit hohem Aufwand verbunden. Windows bietet zwar die Möglichkeit, mit Sysprep zumindest Vorlagen von virtuellen Maschinen inklusive Betriebssystem vorzuhalten, sodass sich die reine Installation des Betriebssystems dann zumindest überspringen lässt. Doch anschließend geht die eigentliche Arbeit erst los: Es gilt, Netzwerkdienste wie DNS oder DHCP aufzusetzen, die Active-Directory-Domänendienste zu konfigurieren und oft auch weiterführende Dienste wie Datenbanken einzurichten.

Häufig müssen Admins diese monotonen Tätigkeiten regelmäßig wiederholen, um verschiedene Konstellationen austesten zu können. Zudem sind oft Dienste erforderlich, mit deren Installation sich der IT-Verantwortliche möglicherweise zu wenig auskennt, um sie korrekt aufzusetzen. All dies sind gute Gründe, die für ein Projekt wie AutomatedLab (AL) [1] sprechen, das wir im Folgenden vorstellen.

Laborumgebung vorbereiten

Die Systemvoraussetzungen für AutomatedLab auf einem mit Hyper-V ausgestatteten Windows-Rechner (Cluster werden nicht unterstützt) sind wie folgt:

- Hostbetriebssystem ab Windows 10 beziehungsweise Windows Server 2019 oder neuer

- Windows Management Framework 5+ oder PowerShell 7 (empfohlen)

- Administratorrechte

- Intel-VT-x- oder AMD/V-fähige CPU

- Hauptspeicher mindestens 8 GByte für den Betrieb mehrerer VMs

- Schnelle Massenspeicher (SSDs)

Darüber hinaus benötigen Sie die ISO-Dateien für die zu verwendenden Betriebssysteme. Diese funktionieren jedoch ausschließlich in Englisch, da der Support mehrerer Sprachen für das rein auf Freiwilligenarbeit basierende Projekt zu aufwendig ist.

Sind die Voraussetzungen erfüllt, können Sie AutomatedLab auf drei Arten installieren: über Chocolatey, als direkten Download vom GitHub-Repository des Projekts [2] oder über die PowerShell Gallery [3]. Der aktuell auf GitHub noch verfügbare MSI-Installer soll in zukünftigen Versionen wegfallen. Wir verwenden den Open-Source-Paketmanager Chocolatey, den Sie mit folgendem Befehl installieren:

Für AutomatedLab greifen wir auf eine frische Installation von Windows 11 Enterprise in englischer Sprache auf einem mit 64 GByte RAM ausgestatteten Rechner zurück. Zunächst installieren Sie nicht standardmäßig enthaltene Komponenten nach, um die Systemvoraussetzungen zu erfüllen. Windows 11 umfasst PowerShell 5.1, PowerShell 7 ist noch nicht vorhanden und lässt sich parallel zur Version 5.1 einrichten. Der einfachste Weg zum Setup führt über die PowerShell – Admin-Berechtigungen sind dabei nicht erforderlich:

Alternativ nutzen Sie:

Haben Sie die PowerShell 7 eingespielt, starten Sie diese als Administrator – alle weiteren Schritte führen Sie in dieser Umgebung aus. Ein klassisches Problem dabei ist, dass standardmäßig das Ausführen von Skripten stark eingeschränkt ist. Damit Sie die Skripte im weiteren Verlauf vollumfänglich nutzen können, falls Sie auf Fehlermeldungen zur "Execution Policy" von PowerShell stoßen, können Sie bei Bedarf diese mit dem folgenden Befehl auf die Einstellung "Unrestricted" setzen:

Hyper-V an den Start bringen

Als nächstes prüfen Sie, ob Hyper-V bereits installiert ist. Unter Windows 11 verwenden Sie hierfür den folgenden Befehl (die Befehle für Windows Server weichen etwas ab):

Als Ergebnis erhalten Sie mehrere Features zurück, die auf einem neu installierten Windows 11 alle auf "Disabled" stehen – bei "Enabled" ist Hyper-V bereits installiert. Die Voraussetzungen für Hyper-V unter Windows 11 sind neben einem 64-Bit-Prozessor mit im BIOS eingeschalteter Unterstützung für Virtualisierung mindestens 4 GByte RAM und TPM 2.0. Ist dies gegeben, spielen Sie Hyper-V und seine Werkzeuge mit folgendem Befehl ein:

Anschließend müssen Sie Ihr System neu starten, wozu es Sie auch automatisch auffordert. Wenn Sie nun den obigen Befehl wiederholen, sollten alle (aktuell sieben) Features auf "Enabled" stehen.

Setup von AutomatedLab

Sind die Voraussetzungen geschaffen, installieren Sie als nächstes AutomatedLab über Chocolatey. Dies erfolgt mittels:

Hilfreich ist, dass sich Chocolatey automatisch um Dependencies kümmert, Upgrades auf kommende Versionen ehr einfach vonstatten gehen und die Integration mit Chocolatey-Workflows möglich ist.

Alternativ dazu installieren Sie AL direkt über die PowerShell Gallery:

Nun überprüfen Sie, ob AutomatedLab korrekt installiert wurde:

Leider sind die Ordnerstruktur und die Modul-Organisation der PowerShell etwas unübersichtlich und inkonsistent. Auf dem englischsprachigen Testsystem finden sich die Verzeichnisse, die AutomatedLab ausmachen, unter "C:\Program Files \ WindowsPowerShell" oder unter "C:\Program Files \ PowerShell \ Modules". Das Ausführen von Get-Module AutomatedLab -ListAvailable listet AutomatedLab als Modul vom Typ "Script" in der Version 5.59.0 für die PowerShell-Editionen Core und Desk auf.

AutomatedLAb mit Ressourcen ausstatten

Als nächsten Schritt müssen Sie die Quellen für das Labor aufsetzen. AutomatedLab benötigt eine eigene Ordnerstruktur, um ISO-Dateien, Softwarepakete und andere Ressourcen zu speichern. Mit

erfahren Sie, wo AL seine Ressourcen sucht. Der Standardspeicherort bei einer Installation via Chocolatey ist "C:\LabSources" und die Ordnerstruktur ist auch bereits vorhanden.

Bei Bedarf können Sie ein anderes Laufwerk nutzen, um die Daten vom Systemlaufwerk zu trennen, mehr Speicherplatz bereitzustellen oder einen Speicherort mit besserer I/O-Leistung auszuwählen. Dies gelingt mit:

Jetzt kopieren Sie Ihre ISO-Dateien sowie Softwarepakete in die jeweiligen Unterverzeichnisse – je nachdem, wo Sie den "\LabSources\"-Ordner beheimatet haben. Dieser stellt die oberste Ebene dar, unter der Sie ein "ISOs"-, ein "SoftwarePackages"- und ein "CustomRoles"-Verzeichnis erzeugen. Anschließend testen Sie, ob AL Ihre ISO-Dateien finden und verarbeiten kann:

Auf unserem Testsystem haben wir ISO-Dateien für Windows Server 2019, 2022 und 2025 sowie für Windows 10 und 11 in den Business-Editionen eingespielt. Pro ISO-File listet der obige Befehl unter dem Spaltennamen "OperatingSystemName" je vier Einträge auf – jeweils für das Serverbetriebssystem in der Standard- und der Datacenter-Edition (mit oder ohne GUI). Windows 10 und 11 erscheinen mit noch mehr Einträgen für die jeweiligen Betriebssysteme, da jede Edition ("Pro", "Pro N", "Enterprise" und so weiter) separat in der Liste auftaucht. Diese Daten benötigen Sie später, um das zu verwendende OS zu spezifizieren.

PowerShell-Remoting konfigurieren

Als Nächstes folgt ein kritischer Schritt, um die Grundeinrichtung zu vervollständigen, denn AutomatedLab basiert stark auf PowerShell-Remoting, um virtuelle Maschinen zu verwalten und zu automatisieren. Daher überprüfen Sie nun mit Test-LabHostRemoting -Verbose, ob Remoting für AutomatedLab korrekt konfiguriert ist. Dieser Befehl führt umfassende Prüfungen der Remoting-Konfi- guration durch und zeigt, wenn Sie den Parameter "-Verbose" hinzufügen, auch alle Abweichungen vom gewünschten Zielzustand auf. In unserem Fall fehlen mehrere notwendige Einstellungen (ohne "-Verbose" liefert der Befehl in einem solchen Fall ein zusammenfassendes "False" als Ergebnis zurück).

Es gilt nun also, Remoting einzuschalten, was über

gelingt. Ein wichtiger Hinweis: Die so vorgenommenen Änderungen sind nur für abgeschottete Laborsysteme empfohlen und können bei wichtigen Systemen die Sicherheit des Systems gefährden. Der Befehl schaltet PowerShell-Remoting ein, konfiguriert den WinRM-Dienst, stellt die Authentifizierungsmethoden ein, setzt die "Trusted Hosts"-Eigenschaft auf "*" und schaltet die CredSSP-Authentifizierung ein (wichtig für "Double Hop"-Szenarien).

Danach testen Sie die Konfiguration über den obigen Befehl erneut, nun sollte das Ergebnis "true" lauten. Im einzelnen können Sie die Authentifizierungsmethoden und ihren Zustand mit dem Befehl

auflisten. Alle sechs Methoden von "Basic" bis "CredSSP" sollten nun auf "true" stehen. Dabei ist CredSSP (Credential Security Support Provider) besonders wichtig, da es AL erlaubt, eine Authentifizierung über "zwei Ecken" (Double Hop) durchzuführen, sodass Befehle, die in Labor-VMs laufen, auf Netzwerkressourcen mit den Zugangsdaten des ursprünglichen Nutzers zugreifen können.

Die Konfiguration der vertrauten Rechner (Trusted Hosts) ermitteln Sie mit:

Hier sollte ein "*" als Value-Eigenschaft erscheinen. Das Wildcard-Zeichen erlaubt dabei Verbindungen auf jeden Zielrechner. In produktiven Umgebungen sollten Sie dies auf bestimmte Rechner oder Netzwerke beschränken, um keine Sicherheitsprobleme zu verursachen. In einem Labor erleichtert es natürlich den Umgang mit AL.

Erzeugen einer Testumgebung vorbereiten

Nun geht es daran, mit AutomatedLab eine Testumgebungen zu erzeugen. Dabei folgt die Software einem strukturierten Arbeitsprozess:

1. Definieren der Laborstruktur und der Anforderungen.

2. Konfigurieren von virtuellen Netzwerken und Maschinen.

3. Ausrollen der Testinfrastruktur.

4. Verwalten von laufenden Umgebungen.

5. Erweitern der Labore mit Softwarepaketen und benutzerdefinierten Konfigurationen.

Jede Bereitstellung eines Labors beginnt mit einer Definition der jeweiligen Umgebung, die die Konfiguration beschreibt. Diese erzeugen Sie mit:

Der Parameter "-Name" ist dabei ein eindeutiger Bezeichner für Ihr Labor (wird verwendet für Speicher und Verwaltung) und mit "-DefaultVirtualizationEngine" wählen Sie zwischen "HyperV" (lokaler Betrieb) oder "Azure" (Cloud). Der Befehl löst zunächst eine Aktualisierung und den Download von Werkzeugen aus. Dazu gehört auch die SysInternals-Suite, die im Unterverzeichnis "Tools" in unserer Ordnerstruktur unter "C:\LabSources" wandert. Die ISO-Dateien werden ebenfalls nochmal neu eingelesen.

Netzwerk konfigurieren

Im nächsten Schritt konfigurieren Sie virtuelle Netzwerke. Für unsere Testinfrastruktur möchten wir eine Maschine erzeugen, die über Hyper-V per NAT ins Internet gelangt. Ein Blick in den "Virtual Switch Manager" von Hyper-V unter Windows 11 verrät uns, dass ein einziger Switch namens "Default Switch" existiert. Dieser ist bereits so eingestellt, dass er über die Netzwerkkarte, die Windows aktuell zum Internetzugriff verwendet, auch ins Internet über NAT gebridged ist. In unserem Fall erfolgt das über WiFi, der zugehörige Netzwerkadapter heißt "Wi-Fi" in Windows, was Sie über den PowerShell-Befehl Get-NetAdapter überprüfen. Mit dem Befehl

konfigurieren Sie das Labornetzwerk so, dass die virtuellen Maschinen, die dieses verwenden, über NAT durch Hyper-V nach außen kommunizieren können.

Für einen ersten Test legen Sie nun die Definition einer VM an, die als Betriebssystem Windows 10 Pro verwenden soll. Sie soll auf den Namen "Client1" hören, 1 GByte RAM erhalten und das soeben definierte Netzwerk verwenden:

Der Parameter "-OperatingSystem" bezieht sich auf die Liste von Betriebssystemnamen, die Sie mit Get-LabAvailableOperatingSystem auf Basis der vorher bereit- gestellten ISO-Images abrufen. Gut 50 weitere optionale Parameter wie "-IpAddress" oder "-Gateway" nutzen Sie, um die Konfiguration der einzelnen Labormaschinen zu spezifizieren.

Anschließend lassen Sie mit Install-Lab das AutomatedLab-Toolkit loslaufen, das dann die Befehle umsetzt und die Testumgebung erzeugt. Folgende Schritte werden dadurch ausgelöst: Zunächst misst das Projekt die Geschwindigkeit der verschiedenen Platten Ihres Systems, um die schnellste Platte (falls mehrere vorhanden sind) als Speicherort für die virtuellen Labormaschinen festzulegen. Alternativ setzen Sie bereits bei der Definition des Labors mit dem Parameter "-VmPath" für das New-LabDefinition-Cmdlet einen benutzerdefinierten Pfad als Speicherort der VMs.

Als Nächstes überprüft dieser Schritt nun die Definition der Testumgebung. Hier erhalten wir eine Warnmeldung zum Default-Switch, die besagt, dass dieser unter dem gleichen Namen aber mit unterschiedlichem SwitchTyp bereits existiert. Das ist den Besonderheiten des NAT-Netzwerks unter Windows 10 oder 11 geschuldet und Sie können dies ignorieren.

Laborrechner in Betrieb nehmen

Danach entsteht bei der ersten Bereitstellung eines Betriebssystems (in unserem Beispiel Windows 10 Pro) ein sogenanntes Base-Image. AL greift hierzu auf die "Differencing Disks"-Technik von Hyper-V zurück, die es erlaubt, mehrere VMs aus einem einzigen, nur lesbaren (read-only) Base-Image heraus zu betreiben. Jede virtuelle Maschine, die auf dieses Base-Image zurückgreift, verwendet dann für ihre spezifischen Änderungen gegenüber den Blöcken des Base-Images Differencing Disks, die nur die geänderten Blöcke festhalten. Dies hilft, den Plattenspeicherverbrauch in Laborumgebungen klein zu halten.

Das erstmalige Erzeugen des Base-Images dauert wenige Minuten, AutomatedLab mountet hierzu das ISO-Image als DVD-Laufwerk und die Festplatte des Base-Images als weiteren Laufwerksbuchstaben. Nachdem dieser Vorgang abge- schlossen ist, verschwinden die Laufwerke für DVD und Image wieder. Danach werden in Hyper-V die VMs erzeugt – in unserem ersten Test eine einzige – und diesen das Base-Image beziehungsweise die Differencing Disk zugewiesen. All dies passiert automatisch und lässt sich bei den PowerShell-Meldungen im Terminal-Fenster mitverfolgen.

Sind die VMs erzeugt, starten diese nach und nach und die Anpassungen anhand der zuvor gemachten Konfiguration (Hostname, Netzwerkkonfiguration und so weiter) erfolgen. Abschließend entstehen noch die Zertifikate für die Remote Desktop Services für die VMs und die Einträge in der lokalen Hostdatei im Wirtsbetriebssystem. Dies erlaubt Ihnen, sich anschließend über Remote Desktop unter Verwendung des Hostnamens der VM ohne weitere Meldungen und Rückfragen auf die VMs aufzuschalten. Dies ist deutlich bequemer als die Remote-Konsolenfunktion von Hyper-V zu verwenden. Da wir kein explizites Passwort in unserem Skript festgelegt haben, kommt das im AL-Projekt verwendete Standardpasswort "Somepass1" zum Einsatz.

Komplexe Umgebungen anlegen

Nachdem Sie nun ein erstes, sehr einfaches Labor, bestehend aus einer einzigen VM, erzeugt haben, ist der Schritt zu komplexeren Laboren sehr einfach. Zunächst entfernen Sie die gerade erzeugte Testumgebung mit Remove-Lab -Name <Name>, was AL veranlasst, alles wieder rückgängig zu machen, inklusive der Einträge in der Hostdatei, den virtuellen Netzwerken und der XML-Dateien, die das Labor beschreiben. Lediglich die beim Erstellen erstmalig erzeugten Base-Disks bleiben erhalten, was das Anlegen weiterer Umgebungen deutlich beschleunigt.

Die Definition des Labors, seiner zugehörigen VMs, Netzwerke und Domänen ist weiterhin mit Get-LabDefinition abruf- und veränderbar und eine neue Instanz lässt sich darüber starten. Mit dem Schließen des Terminal- oder PowerShell-Fensters gerät auch die Labordefinition in Vergessenheit, da diese an den PowerShell-Kontext gebunden ist.

Mit dem Skript aus dem Listing erzeugen Sie eine Testumgebung bestehend aus einem Domänencontroller und SQL Server 2019. Beide Server-VMs sind über ein internes Netzwerk verbunden, das den Adressraum "10.0.1.0/24" verwendet. Da es sich bei dem ISO-Image für die SQL-Server-Installation nicht um ein Betriebssystem-ISO handelt, müssen Sie es über den Add-LabIsoImageDefinition-Befehl vor der Verwendung bekannt machen.

Diese Skript ist natürlich noch deutlich ausbaufähig, der SQL-Server lässt sich selbstverständlich automatisch in die Domäne aufnehmen und auch komplexere Gesamtstrukturen können Sie ohne Weiteres aufbauen – Beispielskripte dazu liefert [4]. In der Praxis bietet es sich an, sich beim Erstellen der Skripte von LLMs helfen zu lassen.

Der Install-Lab-Befehl im Skript löst einige Aktionen aus. Zunächst wählt AutomatedLab automatisch die schnellste verfügbare Platte zur Speicherung der VMs, indem es die Geschwindigkeiten der Platten misst. Das lässt sich bei Bedarf mit dem Parameter "-DiskName" bei der Definition der VMs übergehen. Danach erzeugt AL die VMs anhand ihrer spezifizierten Konfiguration. Die Betriebssysteme erstellt AL beim ersten Erzeugen einer VM aus ihren ISO-Dateien heraus in Form von Base-Images, bei jeder weiteren ähnlich gelagerten VM zieht AL das bereits erstellte Base-Image heran. Dann folgt die Konfiguration der Domänendienste, falls in der Spezifikation angefordert. Schließlich entsteht die definierte Netzwerkkonnektivität und Rollen und Features werden installiert.

Die Bereitstellung einfacher Labore (bestehend aus ein oder zwei VMs) dauert typischerweise 15 bis 30 Minuten, komplexe Umgebungen mit fünf oder mehr VMs und verschiedenen Rollen circa eine bis drei Stunden. Diese Angaben hängen natürlich von der Hardwareleistung und Netzwerkgeschwindigkeit ab.

AutomatedLab speichert die Laborkonfiguration als XML-Dateien, um das Management einfach zu halten und eine Wiederverwendung zu ermöglichen. Stan- dardmäßig liegen diese unter " C:\ProgramData \ AutomatedLab \ Labs \" und dann in den Unterverzeichnissen der jeweiligen Testumgebungen. Nach einem Neustart des Systems oder des Terminals importieren Sie ein bestehendes Labor mit:

Der "-NoValidation"-Parameter ist hilfreich, um den Importprozess zu beschleunigen und Validierungsprüfungen zu übergehen, wenn Labore durch direkten Eingriff in die Dateien geändert wurden.

Fazit

Viel schneller als mit dem kostenlosen AutomatedLab gelangen Admins wohl kaum an eine vollständig konfigurierte Testumgebung. Diese ist nicht nur zügig am Start, sondern lässt sich Dank der XML-Ablage auch wiederverwenden. Somit hat der IT-Verantwortliche am Ende des Tages mehr Zeit für sein eigentliches Vorhaben, nämlich dem Test neuer Software, Dienste oder Konfigurationen. Und in absehbarer Zeit soll der Dienst auch ein GUI [5] erhalten, um die Arbeit damit weiter zu vereinfachen – eine Vorschau darauf zeigt Bild 2.

Hyper-V- und Azure-Testumgebungen mit AutomatedLab

Probieren geht über Studieren

Laborumgebung vorbereiten

Laborumgebung vorbereiten

Hyper-V an den Start bringen

Setup von AutomatedLab

AutomatedLAb mit Ressourcen ausstatten

PowerShell-Remoting konfigurieren

Erzeugen einer Testumgebung vorbereiten

Netzwerk konfigurieren

Laborrechner in Betrieb nehmen

Komplexe Umgebungen anlegen

Fazit