Virtualisierung

Automatisieren der Bereitstellung virtueller Computerhosts

Fergus Strachan

Auf einen Blick:

• Hyper-V-Bereitstellung und -Automatisierung
• Lösen von Sysprep-Verallgemeinerungsproblemen
• Bereitstellen virtueller Ressourcen
• Konfigurieren der unbeaufsichtigten Bereitstellung von Gastbetriebssystemen und Servertechnologie
• n

Codedownload verfügbar unter: StrachanHyperV2009_02.exe(1.026 KB)

Inhalt

Bereitstellungsarchitektur
WDS-basierte Hyper-V-Bereitstellung
WMI-basierte Hyper-V-Konfiguration
Virtual Lab-Bereitstellung
Serveranwendungsbereitstellung
Schlussbemerkung

Wahrscheinlich sind Sie schon mit vielen guten Gründen vertraut, eine Hyper-V-Umgebung einzurichten, aber einer, der u. U. von besonderem Interesse ist, ist die Frage, wie durch Hyper-V Produktevaluierungen und Schulungen in Test- und Lernumgebungen vereinfacht werden können, ohne auf 64-Bit-Kompatibilität zu verzichten. Hyper-V kann sogar auf 64-Bit-Einstiegshardware ausgeführt werden, sofern Sie über eine geeignete CPU und eine aktuelle BIOS-Aktualisierung zur Unterstützung der Hardwarevirtualisierung verfügen. Dies ist eine fantastische Möglichkeit, vollständige Testumgebungen auf Grundlage vollständig unterstützter Softwareversionen bereitzustellen, wie z. B. die 64-Bit-Version von Microsoft Exchange Server 2007. Sobald Sie die Bereitstellung einmal eingerichtet haben, kann eine erneute Bereitstellung jederzeit einfach durchgeführt werden, wenn dies notwendig ist, ob zum Testen eines neuen Produkts oder zum Starten einer neuen Klassensitzung.

Selbst wenn Sie eine Testumgebung für einen Kunden mit zwei Domänencontrollern (DCs), einem Computer mit SQL Server, zwei SharePoint-Front-End-Servern, einem Exchange 2007-Postfachserver, einem Hub-Transport-Server und einem Clientzugriffsserver bereitstellen, ist dies eine anspruchsvolle Aufgabe. Stellen Sie sich vor, Sie haben eine viel größere Umgebung mit vielleicht 600 virtuellen Computern (virtual machines, VMs). Können Sie sich vorstellen, diese virtuellen Computer jede Woche oder wann immer eine neue Testumgebung notwendig ist, neu zu installieren? Es ist notwendig, solche Bereitstellungen zu automatisieren, und hierbei kann Hyper-V sehr hilfreich sein.

Hyper-V ist eine Windows-Technologie, die Sie mit der Windows-Verwaltungsinstrumentation (Windows Management Instrumentation, WMI), Windows PowerShell, Windows-Bereitstellungsdiensten (Windows Deployment Services, WDS), Windows Automated Installation Kit (AIK) und Windows Preinstallation Environment 2.0 (Windows PE) kombinieren können, um vollständige Bereitstellungen extrem schnell – oder zumindest ohne viel Aufwand – zu ermöglichen. Möglicherweise finden Sie es interessant, die Installationsbildschirme und Statusanzeigen zu betrachten, während die Systeme bereitgestellt werden und sich selbst konfigurieren, aber Sie müssen dies nicht tun, wenn Sie wichtigere Dinge zu erledigen haben.

In diesem Artikel erfahren Sie, wie Hyper-V-Server, virtuelle Computer, Gastbetriebssysteme und Serveranwendungen ohne Administratoreingriff unter Verwendung von WDS, benutzerdefinierten Installationsabbildern, unattend.xml-Dateien und WMI-Skripts bereitgestellt werden können. Die Gedanke dabei besteht darin, eine WDS-Umgebung einmal vorzukonfigurieren und dann die Testsysteme zu installieren, wenn dies erforderlich ist, wie z. B. beim Neuinstallieren einer Lehrumgebung, bei der Problembehandlung komplizierter Probleme in verschiedenen Konfigurationen und beim Entwickeln und Testen benutzerdefinierter Lösungen.

Der einzige erforderliche Eingriff während der Bereitstellung besteht darin, die Taste F12 zu drücken, um PXE (Preboot eXecution Environment) zu starten, jedoch lässt sich auch dieser Schritt noch beseitigen, indem Sie die Datei „Startrom.n12“ anstelle der standardmäßigen Startdatei „Startrom.com“ in Ihrer WDS-Konfiguration verwenden, wie im TechNet-Artikel Hintergrund des voll automatisierten Installationsentwurfs erläutert wird.

Die übrigen Aufgaben werden dann von WDS, AIK und WMI ausgeführt, nachdem Sie den Autostart der Hyper-V-VMs durchgeführt haben. Sie finden die Konfigurationsdateien und -skripts im Begleitmaterial, das im Codedownloadbereich vom Februar 2009 auf der TechNet Magazin-Website unter technet.microsoft.com/magazine/cc135868 verfügbar ist. Die Installationsabbilder sind nicht enthalten, da sie zu groß sind, aber Sie können die Begleitdateien an Ihre eigene Testumgebung anpassen.

Bereitstellungsarchitektur

Kern meiner Testumgebungs-Bereitstellungsinfrastruktur ist ein WDS-Server, auf dem Active Directory-Domänendienste (AD DS), DNS (Domain Name System), DHCP (Dynamic Host Configuration-Protokoll) und natürlich WDS ausgeführt werden. Aus Gründen der Verwaltungsfreundlichkeit habe ich auch AIK und Hyper-V-Tools zur Remoteverwaltung auf diesem Server installiert. Das ist schon alles, um eine effiziente Hyper-V-Bereitstellung vorzubereiten. Mehr benötigen Sie nicht, aber Sie können zusätzliche WDS-Server hinzufügen, wenn hohe Verfügbarkeit durch Redundanz für Sie wichtig ist. Die übrigen physischen Computer sind Hyper-V-Server, die durch WDS bereitgestellt werden und die virtuellen Computer hosten, die die eigentliche Testumgebung bilden, wie in Abbildung 1 dargestellt.

Abbildung 1 Eine vollständige Testumgebung basierend auf Hyper-V und virtuellen Computern

Anweisungen zum Bereitstellen des WDS-Servers finden Sie im Begleitarbeitsblatt „Bereitstellen von Windows-Bereitstellungsdiensten“ auf der oben erwähnten Downloadwebsite. Wie Sie sehen werden, ist die Installation ganz einfach. Schwierig sind die Bereitstellung und die Konfiguration der Hyper-V-Hosts, aber dazu gleich mehr.

WDS-basierte Hyper-V-Bereitstellung

Einer der Vorteile der Bereitstellung von WDS für Hyper-V besteht darin, dass WDS die Aktualisierung der Windows Server 2008-Installationsmedien vereinfacht, die notwendig ist, weil die ursprünglichen Medien nur eine Vorabversion von Hyper-V enthalten. Die endgültige Version ist als separates Update im Microsoft Download Center verfügbar.

Nachfolgend finden Sie in Kurzfassung die auszuführenden Schritte: Stellen Sie Windows Server 2008 auf einem Referenzcomputer bereit, aktualisieren Sie die Installation mit den aktuellen Hyper-V-Dateien, installieren Sie Hyper-V, und verwenden Sie Sysprep.exe, um die Installation zu verallgemeinern. Zeichnen Sie das verallgemeinerte Installationsabbild auf, und laden Sie es auf den WDS-Server hoch. Automatisieren Sie dann die Standardbereitstellung für Hyper-V für alle Hosts in der physischen Infrastruktur. Ich bevorzuge es, Windows Server 2008 Server Core für Hyper-V zu verwenden, da meine Hyper-V-Server für das Hosten virtueller Computer bestimmt sind und Server Core den Vorteil eines geringen Speicherbedarfs für das Betriebssystem sowie Sicherheit, Zuverlässigkeit und eine bessere Verwaltbarkeit bietet. Zum Aufzeichnen von Installationsabbildern verwende ich natürlich WDS. Sehen Sie sich das Begleitarbeitsblatt „Bereitstellen von Standard-Hyper-V-Hosts mithilfe von Windows-Bereitstellungsdiensten“ an, und erfahren Sie, wie einfach es ist, ein aktualisiertes Hyper-V-Installationsabbild zu erstellen, hochzuladen und zu verwenden. Es könnte einfacher nicht sein.

So weit so gut. Die Standardbereitstellung von Hyper-V auf Grundlage von WDS ist einfach, aber die unbeaufsichtigte Konfiguration ist nicht so unproblematisch. Das Problem besteht darin, dass Sie Sysprep.exe ausführen müssen, um die Referenzinstallation vor dem Aufzeichnen und Hochladen des Installationsabbilds zu verallgemeinern. Sysprep.exe entfernt jedoch wichtige Konfigurationsinformationen aus dem verallgemeinerten Hyper-V-Abbild.

Sysprep.exe verallgemeinert u. a. die Startkonfigurationsdaten (Boot Configuration Data, BCD) und entfernt die Hypervisorstartdirektive aus dem BCD-Speicher. BCD sollte firmwareunabhängig sein, aber das ist nicht der Fall bei Hyper-V. Der Hypervisor ist von den Virtualisierungsfunktionen der zugrunde liegenden Hardware und dem BIOS abhängig. Deshalb muss die Hypervisorstartdirektive entfernt werden, um das Installationsabbild zu verallgemeinern. Es ist möglich, den BCD-Speicher nach der Sysprep-Verallgemeinerung offline zu ändern, aber dies ist keine Lösung.

Wenn Sie das Installationsabbild mithilfe von ImageX.exe (einem Tool aus AIK) bereitstellen, können Sie die Startdirektive mithilfe von BCDEdit.exe erneut eingeben. Allerdings wird diese Direktive während der Verallgemeinerungsphase der eigentlichen Installationsroutine durch Windows Setup wieder entfernt. Somit sind Sie wieder am Anfang.

Es ist eine etwas schwierige Situation, weil Sie die Startdirektive benötigen, um den Hypervisor zu starten. Ohne dass Hypervisor ausgeführt wird, ist der Hyper-V-Server nicht funktionsfähig. Abbildung 2 zeigt die Fehlermeldung, die angezeigt wird, wenn ein virtueller Computer auf einem Hyper-V-Server gestartet wird, der mithilfe eines benutzerdefinierten Installationsabbilds bereitgestellt wurde, jedoch ohne Anpassung der Startkonfiguration.

Abbildung 2 Der virtuelle Computer kann nicht gestartet werden, weil der Hypervisor nicht ausgeführt wird

Eine Möglichkeit, die Hypervisorstartdirektive erneut einzugeben, besteht darin, diese manuell nach der Serverinstallation hinzuzufügen, indem der entsprechende Befehl

bcdedit /set hypervisorlaunchtype auto

ausgeführt und der Hyper-V-Server neu gestartet wird. Dieser manuelle Schritt wäre jedoch ein ernsthaftes Hindernis auf dem Weg zu einer vollständig unbeaufsichtigten Testumgebungsbereitstellung. Glücklicherweise enthält das AIK Windows System Image Manager, mit dem Sie eine unattend.xml-Datei für das Installationsabbild erstellen können, die von WDS während der Installation zusätzlich zur eigenen WDSClientUnattend.xml-Datei angewendet wird. In dieser unattend.xml-Datei können Sie festlegen, dass das Setup sich bei Windows automatisch mit administrativen Anmeldeinformationen anmeldet, die vom WDS-Client bereitgestellt werden, und dann ein Skript ausführt, das die Hypervisorstartdirektive wieder in den BCD-Speicher einfügt und dann den Server neu startet.

Abbildung 3 zeigt den allgemeinen Ansatz, und das Begleitmaterial enthält die Vollversion der unattend.xml-Datei sowie ein vollständiges hypervconfig.vbs-Skript. Das hypervconfig.vbs-Skript kann direkt in das Installationsabbild eingefügt werden, damit es während der Installation verfügbar ist. Sie müssen einfach das Abbild mit ImageX.exe bereitstellen, wie im Begleitarbeitsblatt „Anpassen von Hyper-V-Bereitstellungen“ skizziert ist.

Abbildung 3 Neukonfigurieren und Starten von Hypervisor

WMI-basierte Hyper-V-Konfiguration

Das Aktivieren von Hypervisor ist nicht all zu schwierig, aber wenn Sie mein hypervconfig.vbs-Skript analysieren, werden Sie feststellen, dass es mehr als diese fünf einfachen Zeilen Code enthält. Zusätzlich zur Startdirektive müssen Sie die gesamte Hyper-V-Umgebung konfigurieren, und hier beginnt der schwierige Teil der Bereitstellung.

Sie können nicht einfach virtuelle Computer auf dem Referenzsystem vor der Abbildaufzeichnung erstellen, diese in das Installationsabbild einfügen und dann erwarten, dass nach der Reparatur der Hypervisorstartdirektive alles funktioniert. Die virtuellen Computer werden selbstverständlich auf dem Server sein, aber die Hardwareabhängigkeiten fehlen.

Durch die Abbildverallgemeinerung werden die Ethernet-Anschlüsse Ihrer virtuellen Computer von den physischen Netzwerkschnittstellenkarten (network interface cards, NICs) und den Pass-Through-Laufwerken der zugrunde liegenden Festplatten und CD-/DVD-Geräte getrennt. Sie können die Verallgemeinerung auslassen, aber es ist keine gute Idee, vorinstallierte virtuelle Computer in ein Installationsabbild einzuschließen. Vorinstallierte virtuelle Computer vergrößern das Abbild deutlich, Evaluierungslizenzen bereitgestellter Testserver verlieren schließlich ihre Gültigkeit, und Active Directory-Domänen sollten auch nicht für längere Zeit offline geschaltet werden. Wenn Sie eine Testumgebung mithilfe von Sicherungen virtueller Computer, die vor mehreren Monaten installiert wurden, wiederherstellen, werden mit großer Wahrscheinlichkeit Probleme bei der Active Directory-Authentifizierung und -Replikation auftreten. Es ist besser, jedes Mal ganz neu zu beginnen.

Stellen wir also zuerst virtuelle Computer und zugehörige Ressourcen in der Hyper-V-Umgebung bereit, wie z. B. NICs, Festplatten und DVD-Laufwerke, bevor wir uns mit der eigentlichen Bereitstellung der Testumgebung beschäftigen. Wie Sie vielleicht schon erraten haben, ist die Bereitstellung der virtuellen Ressourcen die Hauptaufgabe des hypervconfig.vbs-Skripts.

Der Ansatz ist ziemlich einfach. Das Skript ermittelt den Namen des lokalen Hyper-V-Servers und konfiguriert dann einen hostspezifischen Satz virtueller Computer. Jeder virtuelle Computer erhält zwei virtuelle DVD-Laufwerke, die einer serverspezifischen .iso-Datei und einer allgemeinen .iso-Installationsdatei zugeordnet werden. Die serverspezifische .iso-Datei entspricht der Start-DVD. Sie umfasst alle notwendigen Skripts und Konfigurationsdateien für eine unbeaufsichtigte Installation eines bestimmten Testumgebungsservers.

Die allgemeine Installationsdatei stellt die eigentlichen Installationsmedien bereit. Durch Freigabe der allgemeinen .iso-Datei für alle virtuellen Computer auf einem Server kann die Größe des Hyper-V-Installationsabbilds einigermaßen unter Kontrolle gehalten werden. Sie können die .iso-Dateien auf einem Netzwerkserver ablegen, aber letztendlich müssen Sie die Dateien für die Installation auf den Hyper-V-Server kopieren. Daher habe ich mich entschieden, sie direkt in das Installationsabbild aufzunehmen. Auf diese Weise sind die .iso-Dateien lokal verfügbar, wenn sie gebraucht werden. Dies kann zum Beispiel nützlich sein, wenn zusätzliche Komponenten installiert werden oder ein bestimmter virtueller Computer neu installiert wird, ohne die gesamte Testumgebung zu zerstören.

Ich werde gleich die serverspezifischen Installations-DVDs erläutern. Zuerst wird jedoch die Konfiguration der Hyper-V-Infrastruktur mithilfe eines WMI-basierten Skripts näher beschrieben. Wie in Abbildung 4 dargestellt, gibt es verschiedene virtuelle Ressourcen, die bereitgestellt werden müssen: u. a. ein virtueller Switch mit internen und externen Switchports, die virtuellen Computer mit ihren virtuellen Ethernet-Karten, virtuelle IDE-Laufwerke, die mit VHD-Dateien (virtual hard disk, virtuelle Festplatte) verbunden sind, sowie die virtuellen DVD-Laufwerke, die mit den .iso-Dateien für die Installation von Gastbetriebssystemen und Serveranwendungen verbunden sind.

Abbildung 4 Bereitstellen virtueller Ressourcen für die Testumgebung

Sie müssen auch die Autostartkonfiguration der virtuellen Computer anpassen und die Startreihenfolge ändern, damit das virtuelle Laufwerk zuerst verwendet wird, gefolgt vom virtuellen DVD-Laufwerk, das mit der serverspezifischen .iso-Datei verbunden ist. In dieser Konfiguration starten die virtuellen Computer von der Installations-DVD, bis das Betriebssystem auf der virtuellen Festplatte installiert ist. Sicherlich sind Sie mit dieser Abfolge vertraut, denn dies ist bei jedem modernen PC der Standard.

Durch das hypervconfig.vbs-Skript werden die virtuellen Computer so konfiguriert, dass sie automatisch starten, wenn der physische Computer gestartet wird. Auf diese Weise werden die virtuellen Computer nach dem Neustart von HypervisorLaunchType online geschaltet, und die Testumgebungsinstallation beginnt. Die virtuellen Computer starten schließlich in die Setuproutinen ihrer Gastbetriebssysteme. Dies ist der Schlüssel zu einer vollständig unbeaufsichtigten Testumgebungsbereitstellung.

Zum größten Teil folgt die Konfiguration virtueller Computer den gleichen Prinzipien, die Sie in Betracht ziehen, wenn physische Computer mit mehreren Laufwerken konfiguriert werden, die mit mehreren IDE-Controllern verbunden sind. Der virtuelle Switch erfordert jedoch noch weitere Erläuterungen, da er eine entscheidende Rolle für die Kommunikation zwischen virtuellen Computern auf dem gleichen Hyper-V-Server und zwischen virtuellen Computern auf separaten Servern über das Computernetzwerk spielt. Im Grunde können Sie einen virtuellen Switch mit seinem physischen Gegenstück vergleichen. Er kann durch Aufrufen der Methode „CreatedVirtualSwitch“ erstellt werden, aber ein Switch ohne Ports ist nicht sehr nützlich.

Um den Switch mit einem physischen Netzwerk zu verbinden, müssen Sie durch Aufrufen der Methode „CreateSwitchPort“ einen Switchport erstellen und diesen Port mit einer verfügbaren Ethernet-Netzwerkkarte auf dem Server verknüpfen. Sie können eine physische Netzwerkkarte nur mit einem virtuellen Switch verbinden, aber Sie können mehrere Switches direkt oder über eine auf den virtuellen Computern ausgeführte Routersoftware miteinander verbinden. Für die Zwecke dieses Artikels ist eine standardmäßige LAN-Umgebung ohne Netzwerkrouter jedoch ausreichend. Ich habe deshalb auf jedem Hyper-V-Server einen einzigen virtuellen Switch konfiguriert, der mit der ersten verfügbaren physischen Ethernet-Karte verbunden wird.

Sie müssen auch die virtuellen Computer mit dem virtuellen Switch verbinden. Beachten Sie, dass Sie durch Aufrufen von CreateSwitchPort für jeden virtuellen Computer einen separaten Switchport erstellen müssen. Sie können dann jeden Switchport mit dem virtuellen Netzwerkadapter eines virtuellen Computers verknüpfen. Vergessen Sie nicht, auch die übergeordnete Partition mit dem virtuellen Switch zu verbinden, wenn externe Netzwerkkonnektivität bereitgestellt werden soll. Sie können diese Aufgabe einfach durch Aufrufen der Methode „SetupSwitch“ durchführen, die einen externen und einen internen Switchport, einen Verweis auf eine verfügbare physische Ethernet-Karte sowie einen eindeutigen Gerätenamen und einen Anzeigenamen als Parameter erwartet.

Durch Aufrufen der Methode „SetupSwitch“ konvertieren Sie den virtuellen Switch von einem privaten Switch in einen externen Switch, wie im hypervconfig.vbs-Skript im Begleitmaterial erläutert wird. Das Skript enthält alle Details, um externe Netzwerkkonnektivität für virtuelle Computer einzurichten. Weitere Informationen finden Sie in der Dokumentation zum WMI-Virtualisierungsanbieter auf MSDN. Wesentliche Teile meines hypervconfig.vbs-Skripts basieren auf den Beispielen, die unter „Verwenden des WMI-Virtualisierungsanbieters“ verfügbar sind.

Virtual Lab-Bereitstellung

Nun, da die Hyper-V-Bereitstellung durchgeführt wurde und die virtuellen Computer nach jedem Systemneustart automatisch starten, kann ich meine Aufmerksamkeit der eigentlichen Bereitstellung der Testumgebung widmen. Für Schulungscenter reicht es wahrscheinlich aus, die virtuelle Netzwerkinfrastruktur und die Gastbetriebssysteme bereitzustellen und die Kursteilnehmer die übrigen Serveranwendungen später bereitstellen zu lassen. Für Entwicklungs-, Test- und Evaluierungszwecke ist es jedoch besser, die gesamte Bereitstellung der Testumgebung zu automatisieren.

Der Gesamtansatz ähnelt der Hyper-V-Methode. Lassen Sie im Anschluss an die unbeaufsichtigte Installation des Betriebssystems die Anmeldung durch das Administratorkonto automatisch durchführen, und führen Sie gegebenenfalls zusätzliche Setupbefehle aus. Sie müssen jedoch die Bereitstellung organisieren.

Alle virtuellen Computer starten praktisch gleichzeitig in ihre Setuproutinen, aber einige Server sind von anderen Servern abhängig, weshalb es nicht möglich ist, alle Installationen gleichzeitig durchzuführen. Sie müssen zum Beispiel AD DS installieren, bevor Sie der Domäne andere Server hinzufügen können, für Exchange Server 2007 ist ebenfalls AD DS erforderlich, SharePoint-Serverfarmen benötigen SQL Server und so weiter. Der einzige virtuelle Computer, auf dem somit in Ihrem Szenario Windows Setup sofort ausgeführt werden kann, ist DC01.Litware.com. Alle anderen virtuellen Computer müssen warten, bis der DC betriebsbereit ist.

Es gibt mehrere Möglichkeiten, eine Installationssequenz zu implementieren. Sie können eine Startverzögerung für virtuelle Computer konfigurieren, aber dieses Verfahren ist erfahrungsgemäß unzuverlässig. Würden Sie darauf wetten, dass die Active Directory-Installation immer innerhalb von 15 Minuten abgeschlossen wird? Wie lange dauert es, danach den ersten Exchange Server zu installieren?

Eine andere Möglichkeit ist ein WMI-basiertes Skript zum Einschalten der virtuellen Computer, wenn die Installationsvoraussetzungen dies ermöglichen. Dies ist eine bessere Alternative, die von Ihnen jedoch erfordert, die zentralisierte Skriptausführung mit der verteilten Bereitstellung virtueller Computer zu koordinieren. Es ist weniger kompliziert, jede einzelne Setuproutine anzupassen und die virtuellen Computer die gegebenen Installationsvoraussetzungen selbst prüfen zu lassen, bevor ihre Windows-Setuproutinen initiiert werden, wie in Abbildung 5 dargestellt.

Abbildung 5 Implementieren einer Bereitstellungssequenz auf Grundlage von Installationsvoraussetzungen

Windows PE ermöglicht es, diese benutzerdefinierten Setuproutinen zu implementieren. Es handelt sich um ein minimales Win32-Betriebssystem mit begrenzten Diensten, aber mit Unterstützung für Windows Script Host (WScript), WMI und Microsoft Data Access Component (MDAC). Sie müssen nur ein benutzerdefiniertes Windows PE-Abbild erstellen, die erforderlichen Windows-Featurepakete hinzufügen, ein benutzerdefiniertes Skript einfügen und dann die Datei „Startnet.cmd“ bearbeiten, die sich im Windows PE-Abbild unter %SYSTEMROOT%\System32 befindet, um das benutzerdefinierte Skript auszuführen.

Das Begleitarbeitsblatt „Erstellen benutzerdefinierter Startabbilder für Serverbereitstellungen“ skizziert, wie ein benutzerdefiniertes Windows PE-Abbild für jeden Server in der Testumgebung erstellt werden kann. Abbildung 6 zeigt Ihnen, wie Sie mithilfe dieses Verfahrens die Bereitstellung eines zweiten DC organisieren können.

Abbildung 6 Organisierte Bereitstellung eines zweiten Domänencontrollers in einer Testumgebung

Die Datei „Startnet.cmd“ enthält den Befehl „netsh“, um eine statische IP-Adresse der Netzwerkschnittstelle des virtuellen Computers zuzuweisen, bevor sie das StartSetup-Skript aufruft. Der Befehl „netsh“ ist in einer DHCP-fähigen Umgebung nicht unbedingt notwendig, aber er ist hilfreich, um Netzwerkfehler hervorzuheben. Wenn Sie für Ihren virtuellen Computer in Ihrem Hyper-V-Konfigurationsskript z. B. eine Standardnetzwerkkarte (Microsoft Synthetic Ethernet Port) anstelle einer Legacynetzwerkkarte (Microsoft Emulated Ethernet Port) bereitstellen, informiert Sie der Befehl „netsh“, dass Windows PE die NIC nicht erkennen kann.

Das StartSetup-Skript informiert Sie nicht über dieses Problem, wenn auf Netzwerkressourcen zugegriffen wird, da die Anweisung „On Error Resume Next“ dem Skript ermöglicht, Laufzeitfehler zu ignorieren. Wenn DC01 aus irgendeinem Grund nicht verfügbar ist, schlagen die Verbindungsversuche fehl, und das Skript endet in einer Endlosschleife. Die Schleife wird nur beendet, wenn ein Verbindungsversuch gelingt und wenn DC01 ein globaler Katalogserver ist, was impliziert, dass AD DS installiert wurde.

Wenn die Schleife beendet wird, wird durch das Skript der eigentliche Setupbefehl aufgerufen, der die Datei „unattend.xml“ mit serverspezifischen Konfigurationseinstellungen angibt. Das Diagramm in Abbildung 6 zeigt, wie auf einen globalen Katalogserver gewartet wird, um online geschaltet zu werden, aber das gleiche Prinzip ist auch in anderen Szenarios anwendbar, wie z. B. beim Prüfen der Verfügbarkeit von Dateifreigaben oder SQL Server-Datenbanken. Versuchen Sie einfach, auf die Ressource zuzugreifen, und beenden Sie die Schleife, wenn der Versuch gelingt.

Hyper-V-Ressourcen

Website für Windows Server 2008 Hyper-V

Teamblog zur Windows-Virtualisierung

Handbuch zu Windows-Bereitstellungsdiensten

Windows Automated Installation Kit

Referenz für das unbeaufsichtigte Windows Setup

Serveranwendungsbereitstellung

Abschließend muss nur noch die Datei „unattend.xml“ konfiguriert werden, damit der Server der Domäne hinzugefügt wird, und die TCP/IP-Einstellungen müssen konfiguriert, das RDP (Remotedesktopprotokoll) aktiviert und <FirstLogonCommands> für die Installation der gewünschten Serveranwendungen konfiguriert werden. Die meisten Microsoft-Serveranwendungen unterstützen unbeaufsichtigte Bereitstellungen.

Für AD DS müssen Sie eine Antwortdatei bereitstellen, wie im Microsoft Knowledge Base-Artikel Verwenden des unbeaufsichtigten Modus zum Installieren und Entfernen von Active Directory-Domänendiensten auf Windows Server 2008-Domänencontrollern erläutert wird. Für Exchange Server 2007 sollten Sie stattdessen Befehlszeilenparameter verwenden (siehe Installieren von Exchange 2007 im unbeaufsichtigten Modus in der Onlinehilfe). Informationen zu SQL Server 2008 finden Sie in den Onlinehilfeanweisungen des Artikels Vorgehensweise: Installieren von SQL Server 2008 von der Eingabeaufforderung. Informationen zu Windows SharePoint Services 3.0 finden Sie unter Config.xml-Referenz (Windows SharePoint Services).

Die Anforderungen unterscheiden sich in ihrer Komplexität, aber Sie können diese Systeme ohne Administratoreingriff bereitstellen. Abschließend muss die Taste F12 gedrückt werden, um das WDS-basierte Bereitstellungssystem zu starten.

Schlussbemerkung

Hyper-V ist eine interessante Technologie. Es ist 64-Bit-kompatibel, d. h., Sie müssen keine 32-Bit-Softwareversion für Evaluierungs- oder Schulungszwecke mehr bereitstellen, wenn eine 64-Bit-Version verfügbar ist. Es ist eine Windows-Technologie, d. h., Sie können sämtliche Vorteile von WDS, AIK und Windows PE für die Bereitstellung nutzen. Es unterstützt WMI und Windows PowerShell durch einen WMI-Virtualisierungsanbieter, mit dem Sie alle Aspekte der virtualisierten Umgebung, einschließlich der Bereitstellung von Ressourcen und virtuellen Computern während des Bereitstellungsprozesses verwalten können. Es verwendet einen Hypervisor anstelle eines VMM (Virtual Machine Monitor), um hohe Leistung und größere Skalierbarkeit bereitzustellen, und es ist in Windows Server 2008 ohne Aufpreis enthalten.

Hyper-V-basierte Umgebungen sind relativ leicht bereitzustellen. Es sind nur einige Mausklicks notwendig, um mit den ersten virtuellen Computern zu starten, und in Verbindung mit den Windows-Bereitstellungstechnologien macht es Spaß, sogar die komplexesten Szenarios zu automatisieren.

Der einzige Nachteil ist für mich die Onlinedokumentation des WMI-Virtualisierungsanbieters, die immer noch in den Kinderschuhen steckt. Aus diesem Grund deckt der Beispielcode nicht alle relevanten Aufgaben ab. Im Hinblick auf die Ergebnisse lohnt sich der Aufwand jedoch. Es macht Spaß zuzusehen, wie sich eine IT-Umgebung selbst bereitstellt, selbst wenn sie weit weniger als 600 virtuelle Computer umfasst.

Fergus Strachan ist ein unabhängiger Berater aus London, der sich auf das Entwerfen und Implementieren von Microsoft-Serverinfrastruktur für Unternehmenskunden in Großbritannien spezialisiert hat. Er hat technische Artikel über Microsoft-Servertechnologie verfasst und ist Autor der Publikation „Integrating ISA Server 2006 with Microsoft Exchange 2007“. Er ist außerdem Mitautor von Microsoft Exchange Server 2003 Resource Kit.