Wer für die automatische Installation von Software LoginAM einsetzt, muss aktuell immer noch die virtuellen (oder physischen) Maschinen vorher installieren und in die Domäne aufnehmen. Dafür gibt es zwar auch Tools wie z.B. MDT oder WDS, es wäre aber schöner, es direkt aus LoginAM zu machen. Da LoginAM komplett PowerShell basierend ist und es mittlerweile auch ein “relativ” gut zu nutzendes PowerShell Modul für den XenServer gibt, habe ich mal diesen Weg versucht.
Natürlich installiere ich keine virtuelle Maschine auf dem XenServer, sondern erstelle neue VM’s aus einem Template. Das setzt an erster Stelle voraus, dass ein entsprechendes Template auch vorhanden ist. Um dieses Template automatisiert zu verwenden, darf natürlich beim starten der aus diesem Template erstellten VM’s keine weitere Benutzeraktion mehr erforderlich sein.
Dafür installiere ich zuerst manuell eine virtuelle Maschine mit Windows, installiere alle verfügbaren Updates sowie weitere benötigte Software. In diesem Beispiel, und da ja LoginAM die weitere Installation durchführen soll, installiere ich lediglich die aktuellen XenServer Tools. Sobald alles installiert ist, wird die Maschine mit einem Sysprep herunter gefahren und in ein Template konvertiert. Der Trick hier, ist die Antwortdatei die ich für das Sysprep verwende. Hier konfiguriere ich bereits alles (.NET Framework installieren, PowerShell Remoting aktivieren usw.), damit die virtuelle Maschine bei einem Neustart auch wirklich ohne jeglichen Benutzereingriff bereitsteht. Eine Beispiel Antwortdatei stelle ich natürlich zur Verfügung.
Was muss das Skript, dass wir in dem LoginAM Paket verwenden nun alles machen?
Nun zuerst müssen wir uns mit einem XenServer verbinden und die benötigten Maschinen aus dem Template erstellen. Um das mit PowerShell zu erledigen, installieren wir zuerst das XenServer PowerShell SDK.
Das entsprechende PowerShell Modul aus dem SDK wird einfach in das Module Verzeichnis, normalerweise C:\Windows\System32\WindowsPowerShell\v1.0\Modules, kopiert.
Ob das Modul auch funktioniert, können wir in einer PowerShell Konsole testen und das Modul mit folgendem Kommando importieren.
Import-Module XenServerPSModule
In dem Skript benötigen wir ein paar Parameter, die wir im Paket als Umgebungsvariablen speichern. Im Paket erfassen wir noch eine ganze Reihe mehr an Parametern, für diesen Teil benötigen wir nur ein Array mit den Namen der zu erzeugenden virtuellen Maschinen, den Hostname (oder die IP-Adresse) des XenServers (im Pool natürlich der Pool-Master) sowie die Zugangsdaten zum XenServer.
Das Skript macht nun nichts weiter als sich mit dem XenServer zu verbinden und aus dem angegebenen Template die virtuellen Maschinen aus dem ebenfalls angegebenen Array zu erzeugen. So bald die Maschinen erstellt wurden, werden diese auch gleich gestartet.
Als Ergebnis haben wir jetzt einige virtuelle Maschinen. Allerdings haben diese noch einen generischen Hostnamen, eine dynamische IP-Adresse (die wir nicht kennen) und sind noch nicht in der Domäne. Hier kommt ein weiteres Skript zum Einsatz.
Bevor dieses allerdings starten kann, müssen die virtuellen Maschinen komplett erzeugt worden sein. Mir fiel jetzt kein wirklich guter Trigger ein, deshalb habe ich ein kleines ActionItem geschrieben (ist auch im Download enthalten). Dieses ActionItem macht nichts weiter als eine bestimmte Zeit zu warten. Im Paket warte ich 1200 Sekunden (20 Minuten) bevor ich das zweite Skript ausführen lasse.
Dieses zweite Skript benötigt weitere Parameter wie die lokalen Administrator (zum Anmelden) und die Domänen-Administrator Informationen (für den Domain Join). Das Problem an dieser Stelle ist, dass wir von den neu erstellten Maschinen weder den Hostnamen noch die IP-Adresse kennen.
Die Lösung des Problems ist an dieser Stelle den DHCP Server zu befragen, denn der kennt sowohl den Hostnamen als auch die IP-Adresse der Maschinen. Das ist auch der Grund warum wir in den Parametern des Pakets die Informationen zum DHCP Server benötigen.
Normalerweise werden die virtuellen Maschinen mit einem generischen Hostnamen durch das Sysprep erstellt. Standardmäßig beginnt dieser mit WIN-, weshalb wir einfach Hostnamen, IP-Adresse sowie MAC Adresse von allen Maschinen abfragen die mit dem Prefix WIN- im DHCP Server registriert sind.
Um sicher zu stellen, dass nicht eventuell auch andere Maschinen dabei sind, frage ich den XenServer, ob die entsprechende Maschine mit der MAC Adresse auch dort vorhanden ist. Ist dies der Fall lese ich den Namen der entsprechenden Maschine aus (dieser entspricht dem zukünftigen Hostnamen). Was dann passiert ist lediglich das Ändern des Hostnamens sowie die Maschine in die Domäne aufzunehmen. Aus meinem Sysprep bleiben auf der Maschine noch ein paar Reste zurück, die ich im Bereich „Housekeeping“ noch entferne.
Jetzt fehlt nur noch der letzte Schritt, die Maschinen müssen den richtigen LoginAM Collections zugewiesen werden. Dafür verwende ich ein ein bereits vorhandenes (aber undokumentiertes) PowerShell Modul von LoginAM. Da aber der Domain Join und anschließender Reboot auch etwas dauern können (immer abhängig von der Leistung des Hypervisors) warte ich auch hier nochmal 300 Sekunden (5 Minuten) bevor ich das letzte Skript starte.
Irgendwie müssen wir jetzt noch das Paket ausführen. Zuerst importieren wir das Paket in das entsprechende LoginAM Environment. Als nächstes erstellen wir einen Layer und fügen das importierte Paket hinzu.
Jetzt benötigen wir noch eine Collection der wir den zuvor erstellten Layer zuweisen.
Als Computer weisen wir der Collection die lokale LoginAM Maschine zu, da wir das Paket lokal ausführen wollen.
Unter Package Settings erfassen wir jetzt noch alle benötigten Parameter. Nicht vergessen, das Deployment zu aktivieren.
Nun können wir die Collection ausrollen. Allerdings dürfen wir das nicht über das Dashboard machen. Ein Initialize AM im Dashboard würde mit einem Reboot beginnen, was bei einem lokalen Rollout den Ast absägen würde auf dem wir sitzen. Stattdessen öffnen wir eine administrative PowerShell und führen das folgende Kommando aus.
\\lab-am-01\AM$\(environmentID)\Initialize-AM.ps1 -NoReboot
Das LoginAM Skript müssen wir nur beim ersten mal ausführen. Nachdem die lokale Maschine initialisiert ist, können wir das Deployment ausführen lassen.
Import-Module amclient; Update-AMCache; Enable-AMMaintenance; Invoke-AMEvent -Name Startup; shutdown -a
Die Installation sollte jetzt auch im Dashboard zu sehen sein und irgendwann Ready melden.
An einigen Stellen ist sicher noch „room for improvement“ – aber die virtuellen Maschinen stehen zur Verfügung und können sofort über andere Pakete mit LoginAM installiert werden.
Hier noch alle benötigten Dateien zum Download.