XENMASTER
In einem ersten Schritt haben wir eine kleine Testumgebung mit dem Citrix™ Provisioning Server in einer Citrix™ XenServer Infrastruktur erstellt. Jetzt wollen wir uns damit beschäftigen, wie wir die Provisioning Server Umgebung auch administrieren können. In erster Linie schaue ich mir hier die fehlenden Features an, die meiner Ansicht nach des Produkt Citrix™ Provisioning Server als nicht Enterprise Ready einstufen. Aber ich will nicht kritisieren ohne einen entsprechenden Workaround. Deshalb soll dieser Artikel kein „Finger pointing“ sein, sondern eher ein Fahrplan wie wir die noch bestehenden Stolpersteine umgehen können.
Aktuell ist der Citrix Provisioning Server 5.0 released.
Kommen wir erstmal zu einer kleinen Aufstellung der fehlenden Features. Natürlich alles ohne Anspruch auf Vollständigkeit, nur das was mir so aufgefallen ist.
Jedem der sich mit unserer kleinen Testumgebung auseinander gesetzt hat wird gemerkt haben, dass neue Server nicht automatisch in die Domäne aufgenommen werden. Obwohl das Master Target Device von dem wir unsere vDisk erstellt haben bereits Mitglied der Domäne war, werden keine Computerkonten im Active Directory vom Provisioning Server für Maschinen die von dieser vDisk starten angelegt. Dies ist ein manueller Schritt, der über die Citrix™ Provisioning Server Konsole oder über das Kommandozeilen Interfaces gemacht werden muss.
Natürlich können auch gleich mehrere Maschinen in die Domäne aufgenommen werden, in dem man auf der linken Seite den Knoten markiert und dann rechts mit SHIFT oder STRG einzelne oder alle Server markiert.
Danach muss lediglich noch der entsprechende Domänen Controller sowie die Ziel OU angegeben werden und schon werden die Computerkonten angelegt.
Diejenigen von euch die jetzt aufgepasst haben werden sich Fragen, „Wie, keine Passwort Abfrage?“ Nein, der Provision Server geht davon aus, dass ihr mit einem Konto arbeiten das alle nötigen Berechtigungen hat. In meinen Tests konnte ein normaler User die Konsole nicht starten, weil entsprechende Rechte auf die Datenbank (standardmäßig unter C:\Program Files\Citrix\Provisioning Server\vld.mdb) fehlen.
Ein lokaler Administrator (auf dem Provisioning Server) kann zwar die Konsole starten, neue Maschinen anlegen sowie vDisks zuweisen. Bei der Aufnahme der Maschine in die Domäne scheitert dann auch der lokale Administrator.
Um jetzt nicht mit Domänenadministrator Rechten arbeiten zu müssen, hilft nur der Umweg über die Berechtigungen von Windows. Also einen User anlegen (hier cpsuser) und diesem User über GPOs das Recht geben Computer in die Domäne aufzunehmen sowie weitere Rechte (Aufnahme in die Gruppe Lokale Administratoren, Fileberechtigungen setzen etc.) vergeben. Wie das genau funktioniert brauche ich an dieser Stelle nicht weiter erklären.
Was uns Citrix™ für den Provisioning Server als CLI anbietet kann nur ein Scherz sein. Ich gehe davon aus, dass sich dieses Manko in einer kommenden Version ändern wird, aber vorerst müssen wir damit arbeiten (oder auch nicht). An dieser Stelle will ich einige Wege aufzeigen wie es trotzdem geht.
Das eigentliche Command Line Interface ist eine Telnet Konsole, auf der sich relativ einfach Komandos ausführen lassen. Der dafür benötigte Telnet Server wird per default nicht gestartet. Dieser besteht aus den Dateien cli.exe bzw. cliservice.exe. Die cli.exe lässt sich einfach starten, wobei die cliservice.exe als Service laufen kann (z.B. mit Srvinstw.exe oder sc.exe aus dem Resource Kit).
Um das Command Line Interface zu nutzen muss also zuerst die cli.exe gestartet werden und dann mit einem Telnet Client (telnet.exe im Beispiel) eine Verbindung auf Port 23 hergestellt werden. Nach der Installation vom Provisioning Server ist der Benutzername Admin und das Passwort MAPI2007. Benutzername, Passwort sowie der Port können in der Registry geändert werden.
Nachdem wir uns an der Konsole angemeldet haben, erscheint ein relativ unspektakulärer Prompt.
Die komplette Kommandozeilen Referenz kann direkt bei Citrix herunter geladen werden. Innerhalb der Konsole funktioniert auch immer das “?“ für Hilfe (ähnlich CISCO OS).
Wir wollen uns an dieser Stelle nur mal mit den Basics beschäftigen. Als erstes legen wir mal ein neues Target Device mit dem Namen VM004 an.
client add Name=VM004 Mac=7e-be-93-45-ed-12
Wenn ihr die MAC Adresse aus dem XenServer kopiert unbedingt beachten, die CLI möchte die MAC Adresse getrennt durch “-“ nicht durch “:“.
Auch in der Provisioning Server Konsole taucht unsere neue Maschine auf, allerdings ist noch keine Disk zugeordnet.
Unsere Standard-Disk ordnen wir jetzt mit folgendem Kommando zu:
vDisk assign Name=pvs001:W2K3R2 client=VM004 BeFirstDisk=yes
Nicht wundern, das Kommando gibt keine Antwort zurück. In der Provisioning Server Konsole sehen wir aber jetzt unseren VM004 mit richtig zugeordneter Disk.
Aber startet unserer Server auch?
Ja macht er (wenn die Bootreihenfolge auf Netzwerk zuerst eingestellt war). Allerdings ist dieser Rechner noch nicht in der Domäne, was wir noch nachholen müssen. Dazu verlassen wir die Telnet Konsole und beenden unseren Telnet Server. Auf der DOS Konsole können wir dann wieder die folgenden Kommandos ausführen:
SetComputerAccount /c VM004 SetComputerAccount /m VM004 /p
Wie kann man das ganze jetzt automatisieren. Zuerst benötigen wir ja einen laufenden Telnet Server auf unserem Provisioning Server. Diesen dauerhaft als Service laufen zu lassen ist doch etwas bedenklich was die Sicherheit angeht. Um das auch remote machen zu können würde ich zuerst mit dem Tool psexec.exe die cli.exe starten.
Danach benötigen wir nur einen Telnet Client der sich Skripten bzw. mit Macros füttern lässt und dort können wir dann automatisiert Server anlegen. Danach noch mit pskill.exe den cli.exe Prozess wieder beenden.
Ok, keine wirkliche Lösung. Aber über z.B. AutoIt lässt sich das ganze auch etwas eleganter lösen. Alles was man dafür braucht, ist hier zu lesen.
Die von der vDisk gestarteten System sind ja alle gleich (sogar die SID). Um hier Anpassungen vornehmen zu können, benötigen wir ja Informationen die von der Konsole in die Maschinen übertragen werden. Der Provisioning Server erzeugt hierfür auf jedem System eine Datei mit dem Namen ClientPersonality.ini. Diese Datei liegt direkt im Rootverzeichnis der entsprechenden vDisk.
Die ClientPersonality.ini hat nach der Installation folgenden Inhalt:
[StringData] $DiskName=W2K3R2 $DiskMode=Shared [ArdenceData] _EnablePrinterSettings=0 _DiskMode=S
Aus der Provisioning Server Konsole füllen wir diese Datei mit Informationen. Dazu klicken wir mit der rechten Maustaste auf einen unserer Server und wählen [Properties]. Unter dem Reiter [Personality} können wir nun Schlüssel=Wert Felder erfassen, die später so in die *.ini Datei geschrieben werden.
Nach einem Reboot der entsprechenden Maschine finden wir unseren Eintrag in der *.ini Datei wieder.
Was können wir nun mit diesen Werten anfangen. Einfach gesagt können wir in das Master Target Device mit dem wir unsere vDisk erstellt haben gleich ein Tool einbauen, dass diese Informationen auswertet und entsprechend reagiert. Ein denkbares Beispiel ist z.B. das Setzen des Standard-Druckers.
Sicherlich sind hier wieder AutoIt Skripte denkbar, jedoch hat uns Citrix ein Tool spendiert das sie auch gleich auf die vDisk Maschinen legen. Im Programmverzeichniss jeder Maschine liegt unter Citrix\Provisioning Server\ ein kleines Tool mit dem Namen GetClientInfo.exe. Die Hilfe verrät uns einiges über die Verwendung des Tools.
GetClientInfo FieldName /r=RegistryKeyPath <- Place field in registry GetClientInfo FieldName /f=FileName <- Place field in file GetClientInfo FieldName /o <- Output field to stdout GetClientInfo /? Or /help <- Display help
Bleiben wir bei dem Beispiel mit dem Standard-Drucker. Wir könnten jetzt eine Variable für die entsprechende Maschine in der Provisioning Server Konsole erstellen:
Diese Feld erscheint jetzt auf dem Client in der ClientPersonality.ini.
Jetzt können wir auf dem Client (z.B. per psexec.exe) mit folgendem Kommando den Drucker in die Registry schreiben.
GetClientInfo DefaultDrucker /r=HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Device
Dieses Feature bietet sicherlich ausreichend Raum für eigene Experimente. Mit AutoIt können zum Beispiel, abhängig vom Inhalt des Schlüssel (true/false oder 1/0), andere Skripte gestartet und Aktionen ausgeführt werden. Eines aber bitte nicht vergessen. Die vDisk ist im Shared Mode read-only, also alles was wir in die Registry oder in Files schreiben ist nach einem Reboot weg.
Wir müssen also bei jedem Reboot die GetClientInfo Batch starten oder mit einem anderen Skript Tool diese Informationen wieder setzen. Deshalb sollten diese Post-Steps auch nicht zu umfangreich sein, da diese ja bei jedem Reboot ausgeführt werden müssen.