Ich setze gerade meine Office/SharePoint 2010 Demoumgebung auf, die ich auf der ICE im August und auf der Deutschen Partnerkonferenz im September verwenden werde (und bis 19. Oktober auch nur da – weitere Anfragen sind zwecklos).
Dazu habe ich von der Produktgruppe eine Hyper-V virtuelle Maschine mit dem aktuellen Stand bekommen. Diese VM hat alles, was man braucht: Windows Server 2008, Exchange Server 2010, Active Directory, DNS, Office Communication Server, SharePoint Server 2010, Visual Studio und die Office Clientanwendungen.
Wenn ich beim SharePoint 2007 Launch eines gelernt habe ist es, dass so eine Umgebung mit einem physischen Clientrechner, der von der Hyper-V Maschine mit den Servern getrennt ist am performantesten funktioniert. Außerdem kann man dann noch schön Clientfeatures wie Stiftfunktionen beim Tablet PC zeigen. Für den 2007 Launch hatte ich dazu eine zweite Partition mit einer zweiten Windows Vista Installation. Das hatte aber mehrere Probleme: Zum einen ist ein vernünftiger Demo-Reset schwer, da man zwar den Server auf einen Snapshot zurücksetzen kann, den Client aber nicht. Zum anderen verliert man viel Platz auf der Platte durch die zweite Partition. Und zum Dritten ist das hinzufügen eines weiteren Clients (z.B. für gleichzeitiges Bearbeiten von Dokumenten in Word 2010) recht aufwändig.
Die Lösung heißt VHD Boot in Windows 7. Dieses Feature ermöglicht es, einen Rechner direkt von einer VHD zu booten – mit vollem Hardwarezugriff.
Dazu habe ich in Hyper-V ganz normal eine Windows 7 Installation mit allem was ich so brauche (Office 2010 Technical Preview, Communicator R2, Silverlight, Firefox für Kompatibilitäts-Demos) erstellt.
Wenn eine dynamische VHD in Windows 7 oder Windows Server 2008 R2 gebootet wird, so erweitert sie sich normalerweise auf ihre volle Größe, nimmt also bei einer Maximalgröße von 127GB diese 127GB auch dann ein, wenn nur 10GB verwendet werden. Um den Grund dafür zu verstehen muss man sich folgende Situation vorstellen:
- Die physische Platte im Rechner sei 100GB groß, mit 30 GB frei.
- Dann packt man eine dynamische VHD mit einer Maximalgröße von 127GB darauf, die mit 15GB gefüllt ist.
- Die Hostplatte hat jetzt also noch ca. 15GB freien Platz
- Nun fängt das in der VHD installierte Betriebssystem an, Daten zu schreiben und die Platte wird auf 30GB erweitert. Ergebnis: Die Hostplatte ist voll. Das Betriebssystem in der VHD kann nicht auf die Platte schreiben, obwohl diese reichlich freien Platz anzeigt.
Bei Virtualisierung ist das zwar nicht schön, aber die Virtualisierungsumgebung fängt das Problem ab und pausiert die virtuelle Maschine.
Würde dies allerdings bei einem VHD-Boot passieren, wo das Betriebssystem auf physischer Hardware läuft führt die Situation zur Katastrophe: Abstürze und eventuelle Datenverluste sind die Folge. Daher werden dynamische VHDs beim Booten auf die volle Größe erweitert.
Wer das vermeiden möchte, weil er eine vorhandene VHD mit einer zu hohen Maximalgröße physisch booten will, der kann einen Registryschlüssel setzen:
HKLM\System\CurrentControlSet\Services\Fsdepends\Parameters
\VirtualDiskExpandOnMount
REG_DWORD 4
Das muss geschehen, bevor das Betriebssystem auf der VHD zum ersten Mal auf physischer Hardware gestartet wird. Aber Achtung: man muss dann peinlich genau aufpassen, dass die Hostplatte nicht voll läuft.
Nachdem diese Installation nun vorbereitet ist wird sie zum Betrieb auf anderen Rechnern vorbereitet, wie immer mit sysprep. Dieses Tool entfernt alle computerspezifischen Daten und wird normalerweise von Hardwareherstellern und Firmenadministratoren verwendet, um Betriebssystem-Images zur Verteilung vorzubereiten. Es findet sich in c:\windows\system32\sysprep und wird mit diesen Einstellungen ausgeführt:
Diese Einstellungen sorgen dafür, dass nach einem Neustart des Systems die Hardwareerkeennung komplett ausgeführt und die Initialdaten (Computername, Sprache usw.) abgefragt werden. Wichtig ist, “Herunterfahren” als Option zu wählen, damit dieser Prozess nicht gleich nach dem Beenden beginnt.
Am Ende dieses Prozesses hat man eine VHD, aus der man sowohl virtualisierte als auch physische Clients erstellen kann. Wichtig ist nun, dass diese VHD nicht mehr geändert wird. Alles, was darauf aufbaut sollte Differencing VHDs verwenden.
Die VHD wird nun auf die Clientmaschine kopiert, irgendwohin wo genug Platz ist. Nun muss man eine Differencing VHD davon erstellen. Das geht mit diskpart:
diskpart
create vdisk file=”c:\Win7Client\Win7Client1.vhd” parent=”c:\win7Client\Office2010Beta1.vhd”
Dabei ist der Pfad nach file= derjenige, der als Bootdatei eingetragen werden muss (siehe unten), der Pfad nach parent= die VHD, die aus der Virtualisierungsumgebung kopiert wurde.
Zur Sicherheit sollte man jetzt schauen, ob die VHD auf dem Client korrekt lesbar ist. Dazu öffnet man die Datenträgerverwaltung (in der Computerverwaltung) und wählt die neue Differencing VHD per “Aktion”-“Virtuelle Festplatte anfügen” aus
Wenn alles OK ist kann man danach auf die Inhalte der virtuellen Festplatte per Laufwerksbuchstaben zugreifen.
Danach wird die virtuelle Festplatte wieder getrennt (virtuelle Festplatten werden mit blauem Symbol dargestellt):
Nun werden die Einträge im Bootmanager von Windows 7 erstellt. Das Werkzeug dazu ist bcdedit (von einer administrativen Kommandozeile).
Als erstes wird ein neuer Booteintrag namens “VHDBoot” durch Kopieren des aktuellen Eintrags erstellt:
bcdedit /copy {current} /d "VHDBoot"
Der Eintrag wurde erfolgreich in {93098945-34cb-11de-94ae-b3293e16183f} kopiert.
Die hier erhaltene GUID braucht man für die weiteren Kommandos
Nun muss die VHD sowohl aus device als auch als osdevice festgelegt werden:
bcdedit /set {93098945-34cb-11de-94ae-b3293e16183f} device vhd=[locate]\Win7Client\Win7Client1.vhd
bcdedit /set {93098945-34cb-11de-94ae-b3293e16183f} osdevice vhd=[locate]\Win7Client\Win7Client1.vhd
Vom korrekten Ergebnis kann man sich mit bcdedit /v überzeugen.
Nun wird der Rechner einfach neu gestartet und der neue Booteintrag verwendet. Der Rechner startet das Setup von der VHD, die Hardwareerkennung wird ausgeführt und Daten wie Computername und Administratorkonto werden abgefragt.
Nachdem der Computer eingerichtet ist nehme ich ihn in die Domäne meiner Demoumgebung auf und richte Dinge wie das Outlook- und das Communicator-Konto ein.
Jetzt kommt der eigentliche Charme der Lösung: Eine einfach zurücksetzbare Demoumgebung gemischt aus virtuellem Server und physischem Client
- Nachdem alles so ist, wie man es haben möchte fährt man den Clientrechner herunter.
- Dann macht man auf dem Server (der bei mir auf Hyper-V läuft) einen Snapshot und benennt den so, dass man ihn wiederfindet.
- Der Client wird danach im Hauptbetriebssystem (also nicht von der VHD) gestartet.
- Die Differencing VHD (oben Win7Client1.vhd benannt) wird umbenannt, z.B. auf den Namen des Snapshots auf dem Server.
- Es wird eine neue Differencing VHD erstellt, die so heißt wie im Booteintrag angegeben und als Parent die gerade umbenannte VHD hat.
- Von dieser VHD (die nur ca. 1 MB groß ist) wird per Explorer noch eine Kopie erstellt
Wenn man nun später auf einen definierten Demozustand zurücksetzen will braucht man nichts weiter zu tun als auf dem Server den Snapshot wiederherstellen und auf dem Client die Kopie der VHD über den aktuellen Zustand kopieren und booten.
Für mich ist das die ideale Lösung, um in einer gemischten physischen/virtuellen Umgebung ganz definierte, wiederholbarte Demo- oder Testszenarien umzusetzen
Gruß,
Steffen
