Das Dokument ist ein umfassender Leitfaden zur Installation und Konfiguration von Citrix VDI-in-a-Box, einer Desktop-Virtualisierungslösung, die vor allem für kleine und mittelständische Unternehmen konzipiert wurde. Es werden detaillierte Informationen zu den Systemanforderungen, unterstützten Hypervisoren und der Verwaltung virtueller Desktops bereitgestellt und die Vorteile der Lösung, wie einfache Integration und Hochverfügbarkeit, hervorgehoben. Zudem ist das Smartbook kostenlos als PDF und EPUB auf der Website des Autors erhältlich.

1. Citrix VDI-in-a-Box
Installation - Konfiguration - Management
© 2011 Thomas Krampe - Alle Rechte vorbehalten.

2. Vorwort
Dieses SmartBook richtet sich vor allem an Leser, die die Konzepte von Desktop-
virtualisierung bereits kennen und sich einen Überblick über die von Citrix VDI-in-a-Box
verwendeten Konzepte und Technologien verschaffen wollen. Basierend auf dem Citrix
XenServer erklärt dieses SmartBook von der Installation über die Einrichtung bis zum
Betrieb einer VDI-in-a-Box basierten Virtual Desktop Infrastructure Lösung alle nötigen
Schritte.
Das Importieren der virtuellen VDI-in-a-Box Manager Appliance, das Erstellen von
Basisimages oder auch das Anlegen von Templates unterscheiden sich bei den
unterstützten Hypervisor Plattformen nur unwesentlich, weshalb hier nur die Vorgänge auf
einem Citrix XenServer beschrieben werden. Die Grundlage für dieses Buch ist die aktuell
erhältliche VDI-in-a-Box Beta Version 4.9.91 v5b0r1. Als Basis für die virtuelle VDI-in-a-
Box Appliance dienen Hewlett-Packard BL 460 C-Class Blades mit jeweils zwei Intel Xeon
L5640 6-core CPU‘s (24 Kerne mit Hyper Threading) sowie 24 GB Hauptspeicher. Der
verwendete Citrix XenServer ist eine Enterprise Edition in der Version 6.0 Build 50762p.
Allerdings funktioniert die VDI-in-a-Box Lösung auch problemlos mit dem Citrix XenServer
in der kostenlosen Edition.
Da Citrix auch in dieses Produkt ständig neue Features integriert, wird es auch von diesem
SmartBook weitere Versionen geben. Diese Buch steht kostenlos, ganz nach dem Motto
„Information should be free“, als PDF und EPUB Version auf meiner Website unter
www.thomas-krampe.com zum download zur Verfügung.
An dieser Stelle möchte ich noch meiner Familie für die Unterstützung und ganz besonders
meiner Frau für die vielen Reviews und Korrekturen danken. Wo wir gerade bei der
Unterstützung sind, geht mein Dank auch an alle Citrix Technology Professionals, die mich
über unsere internen E-Mails immer mit Rat und Tat unterstützt haben. Anmerkungen,
Kritik oder auch mal ein virtuelles Schulterklopfen kann jederzeit als Kommentar in
meinem Blog unter blog.thomas-krampe.com hinterlassen werden.
Thomas Krampe
Königstein, den 15.12.2011
2

3. Einleitung 5
Architekturübersicht 6
Systemvoraussetzungen 8
Hypervisor 8
Citrix XenServer 8
Microsoft Hyper-V 8
VMware ESXi / VMware vSphere 8
Hardware Voraussetzungen 9
VDI-in-a-Box Manager 9
Prozessor 9
Hauptspeicher 9
Festplatten 10
Unterstützte Betriebssysteme für Basisimages 11
Unterstützte Endgeräte/ Betriebssysteme 12
Client Betriebssysteme 12
Thin Clients 12
VDI-in-a-Box Manager importieren 13
Import mit dem Citrix XenCenter 14
Konfigurieren des VDI-in-a-Box Manager 16
Schritt 1 - Hypervisor Setup 17
Schritt 2 - Erstellen des Basisimages 20
Schritt 3 - Erstellen eines Templates 31
Desktop Refresh Policies 33
Schritt 4 - Benutzer anlegen und zuordnen 35
Verbindung testen 37
Verbinden mit dem Citrix Receiver 37
Verbinden mit dem Java Client 37
VDI-in-a-Box Verwaltung 39
Verwalten von Images 39
Neues Image erstellen 39
Vorhandenes Image kopieren 39
Vorhandenes Image bearbeiten 40
Vorhandenes Image reparieren 42
Vorhandenes Image löschen 43
Verwalten von Templates 44
3

4. Neues Template erstellen 44
Templates kopieren 44
Templates bearbeiten 44
Templates löschen 45
Verwalten von Desktops, Sessions und Benutzern 45
Summery 45
User Sessions 46
Verwalten des VDI-in-a-Box Managers 48
Verwalten der Server 48
Administration der Umgebung 54
Advanced Properties 54
Grid Time 57
Grid Maintenance 58
Grid Upgrade 58
Edit Grid Name 59
Configure User Database 59
View Audit Log 59
Download Debug Log 60
Change Console Password 60
Reset Server 60
Erweiterte Konzepte 62
Kiosk Mode 62
Generic User Support 63
Sicherer Remote Access 63
Benutzer Profil Management 65
VDI-in-a-Box Command Line Interface 65
Konfiguration der Endgeräte 67
Microsoft Windows, Mac OS X oder Linux 68
Apple iOS oder Android 68
Anhang A: Nützliche Links 69
Weitere kostenlose Whitepaper 69
Über den Autor 70
4

5. Einleitung
Im Sommer 2011 übernahm Citrix die VDI-in-a-Box Lösung des Herstellers Kaviza und
bietet nun neben seinem Enterprise Produkt Citrix XenDesktop, dass sich Aufgrund seiner
Komplexität nur für große Unternehmen eignet, nun auch eine „kleinere“ Lösung für die
Installation einiger hundert Arbeitsplätze. Bei Citrix VDI-in-a-Box, aktuell in der Version
5.0, handelt es sich um eine Lösung zur Desktop-Virtualisierung, die ohne Shared Storage
auskommt und sich daher vornehmlich an kleine und mittelständische Unternehmen
richtet. Aber auch große Unternehmen, die noch keine Enterprise Lösung zur
Virtualisierung von Desktops nutzen, können mit Citrix VDI-in-a-Box eine kleinere Anzahl
von Arbeitsplätzen z.B. externe oder mobile Mitarbeiter schnell und kostengünstig mit
virtuellen Desktops unterstützen.
VDI-in-a-Box wird als eine virtuelle Appliance für den Citrix XenServer, VMware ESX und
seit Version 5 auch für Microsoft Hyper-V zur Verfügung gestellt. Das besondere an der
Lösung ist, dass alle benötigten Funktionen zur Einrichtung einer virtuellen Desktop
Infrastruktur auf einer einzigen virtuellen Maschine betrieben werden. Werden weitere
Kapazitäten für virtuelle Desktops benötigt, können zusätzliche Server zu den bestehenden
hinzugefügt werden und bilden so ein VDI-in-a-Box Grid. Der Vorteil dieser Lösung ist der
schnelle und kostengünstige Einstieg in eine VDI1 Lösung für eine geringere Zahl von
Benutzern, aber auch die schnelle Pilotierung für z.B. BYOD2 Programme in kleinen oder
mittelständigen Unternehmen.
Als Protokoll für den Zugriff der Endgeräte steht natürlich in erster Linie das Citrix HDX™
Protokoll zusammen mit dem Citrix Receiver zur Verfügung. Alternativ können die Benutzer
aber auch RDP 6.0 (bei virtuellen Desktops unter Windows 7 auch RDP 7.0) als
Zugriffsprotokoll nutzen. Durch die Nutzung von Citrix HDX™ als Zugangsprotokoll, kann
mit dem Citrix Receiver von nahezu jedem Betriebssystem, einschließlich dem mobiler
Geräte (iOS, Android, Blackberry), sowie von vielen ThinClients direkt auf die virtuellen
Desktops zugegriffen werden. Dabei bietet die Citrix HDX™ Technologie auch für die VDI-
in-a-Box Lösung den gleichen Funktionsumfang z.B. für Flash Multimedia und
Anwendungen, 3D-Grafiken, Webcam, Video- und Audioübertragungen, wie sie auch bei
anderen Citrix Produkten zur Verfügung stehen. Weitere Informationen und Links zum
Citrix Receiver sowie der Citrix HDX™ Technologie habe ich im Anhang zusammen gefasst.
1 Virtual Desktop Infrastructure
2 Bring Your Own Device
5

6. Architekturübersicht
Die Architektur der Citrix VDI-in-a-Box Lösung ist sehr einfach und besteht im wesent-
lichen aus einer oder mehreren virtuellen Maschinen, hier vdiManager genannt, die auf
einem unterstützten Hypervisor3 betrieben werden. Zur Erweiterung der Kapazitäten
können jederzeit weitere vdiManager hinzugefügt werden und bilden so eine VDI-in-a-Box
Grid genannte Farm.
Jeder vdiManager kann die folgenden Funktionen zur Verfügung stellen:
‣ Erstellen von virtuellen Desktops basierend auf Templates. Ein Template besteht dabei
aus:
1. Einem Basisimage, welches das Betriebssystem, Basisapplikationen sowie den VDI-
in-a-Box Agent enthält. Der VDI-in-a-Box Agent ist für die Kommunikation mit dem
vdiManager zuständig und kümmert sich dabei um Verbindungen der einzelnen
3 Citrix XenServer, VMware ESXi oder Microsoft Hyper-V
6

7. Benutzer sowie den Zustand des virtuellen Desktops. Es können dabei mehrere
Templates basierend auf nur einem Basisimage erstellt werden.
2. Richtlinien, die bestimmte Eigenschaften des Templates bestimmen z.B. die Anzahl
des verwendeten Hauptspeichers, Zugriff auf externe Geräte, Anzahl von virtuellen
Desktops pro vdiManager. Das Thema Templates und Images wird im weiteren
Verlauf noch eingehend beschrieben.
‣ Integrierte Lastverteilung (WLB4) zwischen allen in einem Grid vorhandenen
vdiManagern. Basierend auf den verfügbaren Ressourcen (RAM und CPU Kernen) wird
beim Anmelden eines Benutzers der virtuelle Desktop von dem vdiManager gestartet,
der zu diesem Zeitpunkt die geringste Last aufweist.
‣ Integrierte Hochverfügbarkeit zwischen allen in einem Grid vorhandenen vdiManagern.
Dabei werden die nötigen Informationen (Templates und Images) auf alle im Grid
vorhandenen vdiManager repliziert. Fällt ein vdiManager aus, können die verbleibenden
vdiManager die entsprechenden virtuellen Desktops zur Verfügung stellen. Wird der
ausgefallene Server ersetzt und wieder dem Grid hinzugefügt, werden die benötigten
Informationen repliziert und sofort wieder virtuelle Desktops von diesem Server zur
Verfügung gestellt werden.
‣ Management über eine web-basierte Konsole. Jeder vdiManager kann dabei einzeln
oder als komplettes Grid konfiguriert werden. Die VDI-in-a-Box Konsole wird für alle
administrativen Aufgaben wie z.B. Verwalten von vdiManagern, Usern, Templates und
Images verwendet. Updates müssen dabei nur auf einem vdiManager durchgeführt
werden, Änderungen werden sofort auf alle anderen vdiManager repliziert.
‣ Integrierte User Authentifizierung entweder über ein vorhandenes Active Directory in
einer Windows Domäne oder über die eigene Benutzerdatenbank bei einer Windows
Workgroup. Das User Profile Management z.B. Mit Roaming Profiles kann entweder über
ein vorhandenes Active Directory oder auch mit Produkten von Drittherstellern
abgebildet werden. In diesem Fall muss lediglich die entsprechende Clientkomponente
in das Basisimage integriert werden.
‣ Shared Storage ist für den Betrieb nicht zwingend erforderlich, da die virtuellen
Maschinen im lokalen Storage der jeweiligen physikalischen Maschine abgelegt werden.
Hier muss lediglich ausreichend Platz für die gewünschte Anzahl virtueller Desktops
vorhanden sein. Für die Personalisierung der einzelnen virtuellen Desktops und die
Benutzerdaten sollte aber ein externes Filesystem, außerhalb der physikalischen Server,
auf denen der Hypervisor und der vdiManager betrieben wird, zur Verfügung stehen.
4 Work Load Balancing
7

8. Systemvoraussetzungen
Hypervisor
Für den Betrieb von VDI-in-a-Box ist ein unterstützer Hypervisor erforderlich. Folgende
Hypervisor werden in der aktuellen Version unterstützt:
Citrix XenServer
‣ Citrix XenServer 6.0
‣ Citrix XenServer 5.6 FP1
‣ Citrix XenServer 5.6
VDI-in-a-Box unterstützt keinen XenServer Pool, sondern benötigt stand-
alone XenServer. Entsprechende Ausfallsicherheit wird durch das VDI-in-a-
Box Grid zur Verfügung gestellt.
Microsoft Hyper-V
‣ Microsoft Hyper-V Server 2008 R2 mit Service Pack 1
‣ Microsoft Windows Server 2008 R2 mit Service Pack 1 Enterprise
• mit aktivierter Hyper-V Rolle, DHCP, Active Directory
‣ Microsoft Windows Server 2008 R2 mit Service Pack 1 Server Core
• mit aktivierter Hyper-V Rolle, DHCP, Active Directory
VMware ESXi / VMware vSphere
‣ VMware ESXi 5.0
‣ VMware ESXi 4.1
VMware Essentials Lizenz erforderlich.
8

9. Hardware Voraussetzungen
Für die Hardwarevoraussetzungen der physikalischen Server sind die Vorgaben und Best
Practices in Bezug auf CPU, RAM und Festplattenbedarf des entsprechenden Hypervisor
Herstellers zu beachten.
VDI-in-a-Box Manager
Die virtuelle vdiManager Appliance benötigt die folgenden Ressourcen auf dem physischen
System:
‣ 1 vCPU
‣ 1 GB RAM
‣ 74 GB im lokalen Storage (2 vDisks, 8 GB System, 66 GB Export)
Prozessor
Typischerweise rechnet man mit 6 - 10 virtuellen Desktops pro Prozessorkern. Abhängig
von den Richtlinien des Hypervisor Herstellers zeigt die folgende Tabelle die ungefähre
Anzahl von virtuellen Desktops pro physikalischem Prozessorkern.
Taskworker Knowledgeworker Power User
Ohne Hyper-Threading 10 8 6
Mit Hyper-Threading 20 16 12
Hauptspeicher
Die Anforderungen an den erforderlichen Hauptspeicher ist die Summe aus dem Speicher,
welcher für den Hypervisor, der vdiManager Appliance sowie den virtuellen Desktops
benötigt wird.
‣ 1 GB für den Hypervisor
‣ 1 GB für die vdiManager Appliance
‣ 1,5 GB pro virtuellem Windows 7 Desktop
‣ 0,5 GB pro virtuellem Windows XP Desktop
Beispiel:
Bei 40 virtuellen Desktops mit Windows 7 auf einen physischen System werden ca. 70 GB
RAM benötigt (40 x 1,5 GB = 60 GB + 1 GB Hypervisor + 1 GB vdiManager + 10%
Reserve). Auch hier sollte man beim Hauptspeicher nicht sparen: zu wenig RAM resultiert
in langsamen Antwortzeiten der virtuellen Desktops und somit zu einer schlechten
Benutzererfahrung. Ein QuadCore System ist mit 96 GB RAM sicher die richtige Wahl.
9

10. Festplatten
Die erforderliche Festplattenkapazität ist abhängig von der Anzahl der virtuellen Desktops
pro System, der Anzahl der verwendeten Basisimages sowie des vdiManagers selbst. Für
die Gesamtkapazität der erforderlichen Festplattenkapazität ist ebenfalls die eingesetzte
Technologie sowie der verwendete Hypervisor ausschlaggebend. Nachfolgend einige
Beispiele:
Citrix XenServer mit Thin Provisioning und VMware ESXi
‣ Pro Basisimage wird der doppelte Speicherplatz für die Unterstützung von mehreren
Basisimage-Versionen benötigt.
‣ Durch die Linked Clone Technologie werden pro nicht persistentem virtuellen Desktop
15% des verwendeten Images benötigt. Persistente virtuelle Desktops benötigen 100%
des verwendeten Images.
‣ Der vdiManager benötigt 74 GB für sich selbst und unterstützt Basisimages bis zu einer
Gesamtgröße von 60 GB.
Beispiel 1:
25 virtuelle Desktops mit 3 Basisimages à 20 GB benötigen 269 GB im lokalen Storage.
3 Basisimages à 20 GB = 60 GB * 2 (doppelter Platz) = 120,0 GB
+ 25 * 3 GB (15% von 20 GB) = 75,0 GB
+ vdiManager 74,0 GB
Beispiel 2:
10 persistente und 15 nicht-persistente Desktops mit einem Basisimage à 20 GB benötigen
359 GB im lokalen Storage.
1 Basisimage à 20 GB = 20 GB * 2 (doppelter Platz) = 40,0 GB
+ 10 persistente Desktops * 20 GB (100% von 20 GB) = 200,0 GB
+ 15 nicht-persistente Desktops * 3 GB (15% von 20 GB) = 45,0 GB
+ vdiManager 74,0 GB
Citrix XenServer ohne Thin Provisioning und Microsoft Hyper-V
Beim Einsatz von Citrix XenServer ohne bzw. mit deaktiviertem Thin Provisioning wird von
jedem virtuellen Desktop 100% des Basisimages benötigt.
Beispiel 2:
25 virtuelle Desktops mit 3 Basisimages à 20 GB benötigen 694 GB im lokalen Storage.
10

11. 3 Basisimages à 20 GB = 60 GB * 2 (doppelter Platz) = 120,0 GB
+ 25 virtuelle Desktops * 20 GB = 500,0 GB
+ vdiManager 74,0 GB
Citrix empfiehlt bei Verwendung von bis zu 25 virtuellen Desktops pro System mind. 4
Platten und bei 50 oder mehr Desktops pro System 6 - 8 Platten. Diese sollten aus
Geschwindigkeitsgründen als RAID 0 bzw. RAID 1+0 betrieben werden, da Redundanzen
bereits durch den VDI-in-a-Box Manager zur Verfügung gestellt werden.
Unterstützte Betriebssysteme für Basisimages
Aktuell werden von Citrix VDI-in-a-Box nur die folgenden Betriebssystem für virtuelle
Desktops unterstützt:
‣ Windows 7 Service Pack 1 (32-bit oder 64-bit) Professional oder Enterprise Version
‣ Windows XP Service Pack 3 (32-bit) Professional oder Enterprise Version
Virtuelle Maschinen unter Linux werden derzeit noch nicht unterstützt.
11

12. Unterstützte Endgeräte/ Betriebssysteme
Zugriffe auf virtuelle Desktops einer VDI-in-a-Box Umgebung, können per Web-Browser,
Citrix Receiver oder dem VDI-in-a-Box Java Desktop Client (Java Runtime Environment 1.6
oder besser) erfolgen. Die folgenden Betriebssystem werden dabei unterstützt:
Client Betriebssysteme
‣ Windows XP, Windows Vista oder Windows 7 (32-bit oder 64-bit)
‣ RHEL 5.x, CentOS 5.x oder Ubuntu 10.x (32-bit)
‣ Mac OS X 10.5 oder besser
‣ iOS 4.2.3 oder besser (iPhone oder iPad)
‣ Android 3.1 oder besser
Thin Clients
‣ Thin Clients mit Windows XP embedded oder Linux
‣ Unterstützte, zertifizierte Thin Clients z.B.
• Wyse C10LE, Wyse R10L, Wyse R90L7,Wyse R90LE, Wyse Xenith, Wyse
Xenith Pro
• 10ZiG 5682v/5672v, 10ZiG 5617v, 10ZiG 5616v
• Devon IT TC5Xc, Devon IT TC5Dc
• OptiPlex FX130, OptiPlex FX170
• Hewlett-Packard t5740e
12

13. VDI-in-a-Box Manager importieren
Bevor wir den VDI-in-a-Box Manager importieren können, müssen wir uns natürlich
erstmal die virtuelle Appliance herunterladen. Dazu gehen wir mit einem Browser zu
http://www.citrix.com, klicken auf Downloads und wählen im Feld „Search Downloads by
Product“ VDI-in-a-Box aus. Hier klicken wir dann auf „View VDI-in-a-Box Trial“.
Danach müssen in einem Formular noch einige persönliche Informationen erfasst und auf
einer weiteren Seite bestätigt werden. Nach Überprüfung der Informationen erscheinen
dann die Download Informationen. Hier befinden sich drei Links zu den virtuellen
Appliances für die jeweils unterstützten Hypervisor. Die Downloads liegen alle als ZIP
Archive vor. Nach dem Download und dem Entpacken des Archivs steht die virtuelle
Appliance für den Import auf dem gewählten Hypervisor zur Verfügung. Für den Import
muss natürlich darauf geachtet werden, dass die ausgepackte virtuelle Appliance auch auf
einem Filesystem verfügbar ist, auf welches die Management Konsole des Hypervisor für
den Import zugreifen kann.
13

14. Import mit dem Citrix XenCenter
Für den Import muss im Citrix XenCenter lediglich über File ➟ Import die entpackte XVA
Datei importiert werden.
Danach muss noch der XenServer für die virtuelle Appliance ausgewählt werden. Hier ist
unbedingt darauf zu achten, dass es sich um einen einzelnen XenServer und nicht um
einen Server, der Mitglied eines XenServer Pools ist, handelt.
14

15. Die Schritte für Storage und Netzwerk können wie vorgeschlagen übernommen und der
Import mit Finish abgeschlossen werden.
Der eigentliche Import dauert je nach Netzwerkgeschwindigkeit etwa 6 Minuten. Danach
steht die Konsole des VDI-in-a-Box Manager über https://<IP-Adresse>/admin zur
Verfügung. Hier ist darauf zu achten, dass der vdiManager eine IP-Adresse von einem
DHCP Server benötigt. Diese kann später in eine statische IP-Adresse geändert werden
oder auf dem entsprechenden DHCP Server wird eine Reservierung erstellt.
15

16. Konfigurieren des VDI-in-a-Box Manager
Zur Einrichtung des Citrix VDI-in-a-Box Manager rufen wir zuerst die Webkonsole unter
https://<IP-Adresse>/admin auf und melden uns dort an. Der Standardbenutzer
lautet vdiadmin mit dem Passwort kaviza.
Nach der Anmeldung startet sofort ein kurzer Assistent, der uns durch die vier
erforderlichen Einrichtungsschritte führt.
16

17. Schritt 1 - Hypervisor Setup
Zuerst wird im initialen Setup die Verbindung zum Hypervisor konfiguriert. Hier ist lediglich
die IP-Adresse des Citrix XenServers sowie Benutzername und Passwort, dass bei der
Installation des XenServer vergeben wurde, erforderlich.
Sobald die Verbindung zu XenServer überprüft wurde, muss noch das für den Datastore
verwendete Storage sowie das zu benutzende Netzwerk ausgewählt werden. Im folgenden
Bild nutzen wir das lokale Storage Repository des XenServers sowie das Standard
Netzwerk.
Jetzt haben wir jetzt die Möglichkeit, ein neues VDI-in-a-Box Grid zu erstellen oder einem
bereits bestehenden Grid beizutreten. Sollte der VDI-in-a-Box Manager einem bereits
bestehendem Grid hinzugefügt werden, wird die Konfiguration des Grids auf diesen Server
repliziert. Hier muss dann noch der Name und die IP-Adresse eines Servers im
bestehenden Grid, sowie Benutzername und Passwort des Administrators angegeben
werden. Erstellen wir ein neues VDI-in-a-Box Grid, müssen wir dieses noch konfigurieren.
17

18. Beim Erstellen eines neuen Grids, müssen wir einen Namen vergeben sowie die zu
verwendende Benutzer Datenbank auswählen. Soll für die Authorisierung und
Authentifizierung eine Windows Domäne verwendet werden, wählen wir Microsoft Active
Directory. Andernfalls kann auch eine lokale Benutzer Datenbank (z.B. bei Workgroups)
verwendet werden.
Wenn als Benutzer Databank ein Microsoft Active Directory gewählt wird, müssen natürlich
noch weitere Informationen (Domainname sowie Anmeldeinformationen des Domain-
Administrators) angegeben werden.
Im letzten Schritt werden wir noch darauf hingewiesen, dass der Server eine dynamische
IP-Adresse hat. Hier müssen wir die Frage beantworten, ob wir in unserem DHCP Server
eine Reservierung für den VDI-in-a-Box Manager vergeben haben. Damit der VDI-in-a-Box
Manager erreichbar bleibt, ist es sinnvoll, mit einer Reservierung oder einer statischen IP-
Adresse zu arbeiten.
18

19. Wählen wir an dieser Stelle „No“, werden wir noch auf dieses Problem hingewiesen.
Nach einem Klick auf „Next“ kommen wir zum Erstellen des ersten Basisimage.
19

20. Schritt 2 - Erstellen des Basisimages
Bevor wir mit dem Erstellen eines Basisimages im VDI-in-a-Box Manager beginnen
können, benötigen wir erstmal eine virtuelle Maschine, die uns als Basisimage dienen
kann. Diese Maschine muss verschiedene Voraussetzungen erfüllen:
‣ Betriebssystem Windows XP Professional (32-bit) oder Windows 7 Professional oder
Enterprise (32-bit oder 64-bit)
‣ Aktivierte Remote Desktop Unterstützung (RDP)
‣ Nur eine Netzwerkschnittstelle (NIC) als Device 0
‣ Nur ein Festplattenimage
‣ Die virtuelle Maschine muss gestartet sein
‣ DHCP muss in dem Netzwerksegment verfügbar sein
Vorbereiten der virtuellen Maschine für den Import
‣ Aktivieren des Betriebssystems mit einem gültigen Microsoft Volume Activation Key
‣ Aktivieren des lokalen Administrators
‣ Installieren der XenTools
‣ Falls nötig, die Maschine in die entsprechende Active Directory Domain aufnehmen
‣ Aktivieren der Remote Verbindungen für alle Benutzer
‣ Öffnen der Windows Firewall für Remote Verbindungen aus allen Netzen
‣ Installation von allen Windows Updates
Importieren des Basisimages
Sobald die virtuelle Maschine alle vorgenannten Voraussetzungen erfüllt, kann sie über
den VDI-in-a-Box Manager importiert werden. Dazu muss im „Import new VM“ die
entsprechende virtuelle Maschine ausgewählt werden, ein Name für das Basisimage sowie
eine Beschreibung eingegeben werden.
Sollte ein Problem mit der virtuellen Maschine bestehen, wird diese im VDI-in-a-Box
Manager als „Not importable“ gekennzeichnet. Man kann die Maschine in der
Auswahlbox trotzdem auswählen und bekommt dazu einen Hilfetext, warum die Maschine
nicht importiert werden kann (z.B. weil sie ausgeschaltet ist o.ä.).
20

21. Wenn alle Informationen erfasst wurden, startet der Import nach einem Klick auf
„Import“.
Sofort nach dem Abschluss des Imports, der je nach Größe des Images bis zu 5 Minuten
dauert, startet der Assistent für die Installation des VDI-in-a-Box Agents. Dieser gliedert
sich in zwei Schritte.
21

22. Mit dem ersten Schritt wird das neue Basisimage mit dem VDI-in-a-Box Manager
verbunden. Ein Klick auf den „Connect“ Button startet das neue Image und verbindet es
mit dem VDI-in-a-Box Manager. Im XenCenter ist dann auch das gestartete Image als
laufende virtuelle Maschine sichtbar. Die ursprüngliche Maschine, von der wir das Image
erstellt haben, ist vom VDI-in-a-Box Manager herunter gefahren worden.
Wenn das Image mit dem VDI-in-a-Box Manager verbunden ist, gehen wir zum zweiten
Schritt. Hierfür müssen wir uns als Administrator auf der laufenden Maschine anmelden,
einen Browser starten und die Installationsseite des VDI-in-a-Box Agent aufrufen. Wie im
Assistenten angezeigt gehen wir zu https://<IP-Adresse des vdiManagers>/dt/
dtagent und installieren den VDI-in-a-Box Agent mit einem Klick auf „Install“.
22

23. Sobald wir alle Warnmeldungen bestätigt haben, startet die Installation des VDI-in-a-Box
Agents. Die Installationsroutine weist uns noch mal auf die Öffnung der benötigten Ports
für die Kommunikation mit dem VDI-in-a-Box Manager sowie der Clients hin. Ein Klick auf
„Weiter“ startet die Installation.
23

24. Im wesentlichen installiert der VDI-in-a-Box Agent zwei Pakete: die HDX Unterstützung für
das entsprechende Betriebssystem sowie den VDI-in-a-Box HDX Connector.
Nach Abschluss der Installation muss die Maschine mit dem Basisimage noch einmal neu
gestartet werden und wir können zurück zum VDI-in-a-Box Manager. Dort sollte immer
noch der Assistent für die Installation des Agents auf uns warten. Diesen Schritt können
wir, sobald die Maschine mit dem Image wieder gestartet ist, mit „Next“ beenden und
zum Testen der Verbindung übergehen.
Zu beachten ist hier, dass auf der Maschine, auf der der Browser mit dem geöffneten VDI-
in-a-Box Manager läuft, auch ein entsprechender Citrix Receiver installiert ist. Sollte dies
nicht der Fall sein, muss dieser noch von der Citrix Website herunter geladen und
installiert werden. Andernfalls kann der Test nicht durchgeführt werden.
24

25. Ist der Test erfolgreich abgeschlossen worden, erscheint eine Meldung „Test succeeded“
und der „Next“ Button steht zur Verfügung.
Als nächstes besteht die Möglichkeit, das Image zu bearbeiten. Hier können wir z.B. noch
zusätzlich benötigte Applikationen oder Agents installieren. Hierfür verbinden wir uns
direkt aus der VDI-in-a-Box Manager Konsole mit dem Image per HDX oder RDP und
nehmen die entsprechenden Installationen vor. Um danach weiter zu kommen, müssen wir
noch fünf Einstellungen verifizieren und diese in einem Formular bestätigen.
25

26. Diese Fragen beziehen sich alle auf die bereits erwähnten Voraussetzungen und müssen
alle mit „Yes“ bestätigt werden.
Erst danach steht uns der „Next“ Button zur Verfügung und wir können zur Vorbereitung
des Images gehen. Noch ein kleiner Hinweis: In meiner Testumgebung reagierte die
Webkonsole nicht wie erwartet. So brachte ein Klick auf den „Done“ Button keine
Reaktion. Ich musste das Formular über das „X“ schließen, um zurück zum Assistenten zu
kommen. Die Eingaben wurden aber gespeichert. Bei solchen kleineren Problemen mit
dem Webinterface, kann es helfen, den Browser zu beenden und den VDI-in-a-Box
Manager neu aufzurufen. Nach dem Anmelden lassen wir uns die Basisimages über den
„Images“ Link im oberen Teil des Webinterfaces anzeigen. Hier taucht dann auch unser
Basisimage auf. Wir sehen dort auch den aktuellen Zustand (in diesem Fall Prepare
image) und können mit einem Klick auf „Edit“ wieder zurück zum Assistenten.
Im vorletzten Schritt müssen wir das Image vorbereiten. Dazu gehören die Daten des
Domain Administrators (mit dem Recht Maschinen in die Domain aufzunehmen) sowie die
entsprechende Organizational Unit (OU), natürlich nur, wenn in den vorherigen Schritten
26

27. eine Domain als Benutzerdatenbank ausgewählt wurde. Maschinen, die nicht Mitglied einer
Domain sind, benötigen diese Informationen natürlich nicht. Jetzt muss noch die
entsprechende Zeitzone ausgewählt sowie ein Schema für die Computernamen
eingetragen werden. Wer hier keine besonderen Vorstellungen hat, kann den Vorschlag
übernehmen. Standardmäßig wird das Profil des lokalen Administrators als Standardprofil
in die virtuellen Desktops kopiert. Wer das nicht möchte, kann das Häkchen entfernen. Die
Aktivierung des Betriebssystem wird bei jedem Start eines Desktops durchgeführt,
weshalb auch mehrfach dieser Volume Lincense Key überprüft werden muss. An dieser
Stelle muss nun festlegt werden, welcher Key verwendet werden soll. Ist man nicht zu
100% sicher, dass man einen KMS Key verwendet, sollte man diese Einstellung bei MAK
Key belassen. Die letzten beiden Häkchen bewirken zum einen, dass beim Sysprep
jedesmal die Gerätetreiber neu installiert werden. Beim „Fast Refresh“ werden die
Maschinen nach der Benutzerabmeldung sofort entfernt.
Wenn nun alles unseren Wünschen entspricht, wird mit einem Klick auf den „Prepare“
Button das Basisimage für die Verwendung vorbereitet. Es folgt noch ein Hinweis, der uns
auf eine längere Wartezeit einstimmt. Mit einem Klick auf „Confirm“ wird das Image
vorbereitet.
27

28. Der VDI-in-a-Box Manager wechselt dann auch zu einer Status-Seite, die uns den
Fortschritt der Vorbereitung unseres ersten Images zeigt. Auch dieser Vorgang dauert,
abhängig von der Größe des Images und den installierten Applikationen wieder ein paar
Minuten.
Nach dem Abschluss startet der Assistent neu und zeigt uns wieder den bekannten
Assistenten mit dem letzten Schritt.
28

29. Hat im vorherigen Schritt alles problemlos funktioniert, können wir jetzt das Basisimage
testen.
Ein Klick auf den „Connect“ Button öffnet ein weiteres Dialogfenster, in dem wir uns mit
dem Image über HDX oder RDP verbinden können.
29

30. Hier können wir auch noch lokale Geräte, die mit in die Sitzung eingebunden werden
sollen, auswählen sowie die Bildschirmauflösung einstellen. An dieser Stelle startet ein
Klick auf den „Connect“ Button die gewählte Verbindung und der virtuelle Desktop sollte
starten.
Sollte es Probleme beim starten einer HDX Verbindung geben, könnte es an einem
fehlenden Citrix Receiver liegen. Beim Testen des Images sollten HDX und RDP getestet
werden. Funktioniert alles wie gewünscht, können wir uns von dem virtuellen Desktop
abmelden und im Assistenten die Vorbereitung des Images mit einem Klick auf „Save“
abschließen. Hier folgt dann noch eine Bestätigung und das Image wird gespeichert.
Befindet sich der gerade installierte VDI-in-a-Box Manager in einem Grid, wird das Image
auch auf alle anderen Server im Grid repliziert.
Diesen Vorgang können wir auch im Bereich „Activity“ in der VDI-in-a-Box Manager
Konsole nachvollziehen. Sobald der Status „Published“ oder „Distributed“ erscheint,
können wir mit der Erstellung des ersten Templates fortfahren.
Schauen wir uns das im Citrix XenCenter an, existiert neben der virtuellen Maschine, die
wir für das Basisimage benutzt haben, nun auch ein XenServer VM Template. Im
Hintergrund wurde auf dem XenServer lediglich die virtuelle Maschine für das Basisimage
kopiert, unsere Anpassungen vorgenommen und diese Maschine dann zu einem Template
konvertiert.
30

31. Schritt 3 - Erstellen eines Templates
Virtuelle Desktops für Benutzer werden über VDI-in-a-Box Templates zur Verfügung
gestellt. Mit dem dritten Schritt erstellen wir auf Basis des gerade erstellten Images unser
erstes Template. Wichtig dabei ist: Wir können mehrere Templates erstellen, die alle auf
das gleiche Basisimage aufgebaut sind. Für den Anfang erstellen wir erstmal ein einziges.
Wie zu Beginn bereits erwähnt, enthält ein Template nur ein paar wenige Informationen
und Richtlinien. Deshalb ist die Erstellung in nur zwei Schritten erledigt. Außer einem
Namen für das Template, müssen wir natürlich noch das zugrundeliegende Image
auswählen. Da in unserem Fall nur ein Basisimage existiert, ist dieses bereits ausgewählt.
Zur besseren Unterscheidung der einzelnen Templates und als kurzen Hinweis, was in dem
Template eigentlich konfiguriert wurde, sollte man noch die Beschreibung aussagekräftig
ausfüllen. Dann folgt lediglich noch die Größe des Hauptspeichers, ob und welche lokalen
Geräte mit in die Sitzung verbunden werden sollen und welche Farbtiefe die virtuellen
Desktops haben sollen.
31

32. Mit einem Klick auf „Next“ kommen wir dann zur Template Policy, die ebenfalls schnell
erstellt ist. Hier kann die maximale Anzahl der Desktops und ebenso die Anzahl der
maximal zu startenden Desktops festgelegt werden.
Wir können noch das Template als Standard definieren und festlegen, ob Desktops, die
den Status „On Hold“ haben, gleich wieder neuen Benutzern zugeordnet werden können.
Abschließend legen wir noch fest, wann ein neuer Desktop erzeugt werden soll. In diesem
Fall wird der Desktop nach dem Logout eines Benutzers neu erstellt.
32

33. Mit einem Klick auf „Save“ steht unser Template zur Verfügung.
Die Wirkungsweise unseres Templates können wir im XenCenter nachvollziehen. Hier sind
die im Template angegebenen fünf „Pre-started Desktops“ bereits gestartet worden und
stehen zur Anmeldung zur Verfügung.
Desktop Refresh Policies
Es stehen verschiedene Richtlinien für die Aktualisierung von virtuellen Desktops zur
Verfügung. Diese Richtlinien legen fest, wann der Desktop eines Benutzers neu erzeugt
wird.
‣ On Logout
Beim Abmelden eines Benutzers wird der Desktop gelöscht. Beim erneuten Anmelden
des Benutzers wird ein neuer Desktop für den Benutzer erzeugt.
‣ Scheduled
Hier kann auf Tage-, Wochen- oder Monatsbasis eine geplante Aktualisierung definiert
werden. Zusätzlich kann angegeben werden, ob der Desktop auch dann aktualisiert
33

34. werden soll, wenn er in Benutzung ist. Werden Desktops in Benutzung ausgenommen,
aktualisieren sich diese erst bei Abmeldung des Benutzer.
‣ Scheduled or On Logout
Diese Richtlinie eignet sich für Umgebungen, in denen die Benutzer über einen längeren
Zeitraum angemeldet bleiben. Hier wird der Desktop immer nach dem konfigurierten
Zeitplan sowie bei jedem Logout aktualisiert.
‣ Manual
Diese Einstellung erzeugt einen persistenten Desktop, der nur manuell von einem
Administrator aktualisiert werden kann. Virtuelle Desktops mit dieser Einstellung bleiben
auch beim Abmelden erhalten.
34

35. Schritt 4 - Benutzer anlegen und zuordnen
Zuvor erstellte und verfügbare Templates können den Benutzern auf verschiedene Arten
zugeordnet werden:
‣ Als Default Template
‣ Basierend auf Benutzer
‣ Basierend auf Gruppen
‣ Basierend auf IP-Adressen
Neue Gruppen, Benutzer oder IP-Adressbereiche werden einfach über den „Add“ Link
angelegt. Hier muss dann noch bei Gruppen der entsprechende Gruppenname, eine
Beschreibung sowie ein oder mehrere Templates zugeordnet werden. Bei Benutzern ist
neben der User ID noch Vor- und Nachname sowie die entsprechende Gruppe erforderlich.
Auch Benutzern kann, falls erforderlich, ein oder mehrere Templates zugeordnet werden.
Active Directory Security Groups wie z.B. Domain Admins oder Domain
Benutzer sind keine gültigen Gruppennamen in Gruppen- oder
Benutzereinträgen.
Virtuelle Desktops können aber auch über IP-Adressbereiche zugeordnet werden. Hier
kann eine einzelne IP-Adresse (192.168.0.1), ein IP-Adress Prefix (192.168) oder auch ein
Bereich (192.168.0.1-99) eingetragen werden. Mehrere Bereich können per Space oder
einer neuen Zeile getrennt werden (192.168.0.1-99 192.168.0.110-150).
35

36. Benutzern und Gruppen können mehrere Templates zugeordnet werden. Eine Zuordnung
per IP-Adressbereich kann jeweils nur mit einem Template erfolgen. Ist einem User weder
per User-Account, Gruppen-Account oder IP-Adressbereich ein Template zugeordnet, wird
ihm das definierte Default Template zur Verfügung gestellt. Sollte kein Default Template
definiert sein, wird die Anmeldung abgewiesen.
Werden einem Benutzer oder einer Gruppe mehrere Templates zugeordnet, kann der User
nach dem Anmelden auswählen, welchen virtuellen Desktop er starten möchte.
36

37. Verbindung testen
Um die Verbindung als Benutzer zu testen, muss auf dem Endgerät, das zum Testen
verwendet wird, ein aktueller Citrix Receiver bereits installiert sein. Für Endgeräte ohne
Citrix Receiver steht auch ein VDI-in-a-Box Java Client zur Verfügung. Für die Nutzung des
Java Clients muss auf dem Endgerät mindestens das Java Runtime Environment (JRE) in
der Version 1.6 oder höher installiert sein.
Verbinden mit dem Citrix Receiver
1. Öffnen eines Browsers
2. In der Adresszeile https://<IP-Adresse oder Name des vdiManagers>/
eingeben. (Den Sicherheitshinweis des Website Zertifikates bestätigen und als
vertauenswürdig akzeptieren)
3. Benutzername und Kennwort am Webinterface eingeben und auf „Anmelden“ klicken
4. Sollte dem Benutzer nur ein Desktop Template zugeordnet sein, startet dieses nun
automatisch. Falls der Benutzer mehrere zugeordnete Templates hat, muss der zu
startende Desktop noch ausgewählt werden.
5. Der entsprechende Desktop startet nun im Citrix Receiver
Verbinden mit dem Java Client
1. Öffnen eines Browsers
2. In der Adresszeile https://<IP-Adresse oder Name des vdiManagers>/dt/
vdiclient.jnlp eingeben. (Den Sicherheitshinweis des Website Zertifikates bestätigen
und als vertrauenswürdig akzeptieren)
3. Die Java Sicherheitsmeldung akzeptieren
4. Benutzername und Kennwort beim Java Client eingeben und auf „Log On“ klicken
37

38. 5. Sollte dem Benutzer nur ein Desktop Template zugeordnet sein, startet dieses nun
automatisch. Falls der Benutzer mehrere zugeordnete Templates hat, muss der zu
startende Desktop noch ausgewählt werden.
6. Der entsprechende virtuelle Desktop startet nun mit dem Java Client
Der Java Client bietet im Log On Fenster neben den Einstellungen (Preferences) für die
Desktop Größe zusätzlich noch die Möglichkeit, das Protokoll für den Zugriff festzulegen.
Natürlich entspricht die Performance des Java Clients nicht der des nativen Citrix
Receivers. Deshalb sollte, falls möglich, der Citrix Receiver verwendet werden.
38

39. VDI-in-a-Box Verwaltung
Verwalten von Images
Neues Image erstellen
Um ein neues Image zu erstellen, muss lediglich auf der Reiter „Images“ auf den „Add“
Link geklickt werden. Hier startet der bereits bekannte Dialog zur Erstellung eines
Basisimages.
Auch hier muss natürlich eine virtuelle Maschine mit einem unterstützen Betriebssystem
(Win7, WinXP), installierten Hypervisor Tools bzw. Treibern sowie zusätzlich benötigten
Anwendungen zur Verfügung stehen, um importiert werden zu können. Alle weiteren
Schritte unterscheiden sich nicht von der Einrichtung eines Basisimages im Kapitel Schritt
2 - Erstellen eines Basisimages.
Vorhandenes Image kopieren
Das Kopieren eines Images erstellt, wie der Name schon sagt, eine exakte Kopie des
vorhandenen Images. Diese Kopie kann dann als neues Basisimages z.B. mit zusätzlichen
Applikationen für spezielle Benutzer verwendet werden. Das Kopieren erzeugt auch auf der
Hypervisor Schicht eine neue virtuelle Maschine, die unabhängig vom ursprünglichen
Basisimage bearbeitet werden kann.
39

40. Nach Abschluss des Kopiervorgangs kann dieses Images, genau wie im Kapitel Schritt 2 -
Erstellen eines Basisimages beschrieben, bearbeitet und abschließend mit einem Klick auf
„Prepare“ vorbereitet werden. Im Citrix XenCenter steht dann ein neues Template zur
Verfügung
Vorhandenes Image bearbeiten
Einer der wesentlichen Punkte bei virtuellen Desktops ist das Management der
Basisimages (oder auch Golden Master Image genannt) z.B. das Patchen und Updaten des
Betriebssystems sowie der installierten Applikationen. Zu diesem Zweck lässt sich jedes
Image auch direkt bearbeiten.
40

41. Über den Link „Edit“ wird ebenfalls eine Kopie des Basisimages erstellt. Dieses kann dann
verbunden und mit den entsprechenden Patches oder Updates auf den aktuellen Stand
gebracht werden. Der einzige Unterschied zum Kopieren eines Images ist, dass dieses
Image nach einem Prepare eine neue Versions-Nummer erhält und sofort mit den
zugehörigen Templates verbunden wird. Nach dem Kopiervorgang kann mit dem
bekannten Assistenten dann das Basisimage entsprechend editiert bzw. gepatcht werden.
Dieser Schritt ist wieder identisch mit der Erstellung eines Basisimages aus Kapitel Schritt
2 - Erstellen eines Basisimages. Abschließend wird mit einem Klick auf „Prepare“ das
Image wieder vorbereitet. Im Citrix XenCenter steht dann ein neues Template zur
Verfügung. Innerhalb der VDI-in-a-Box Manager Konsole erscheint, anders als beim
Kopieren, kein neues Basisimage in der Liste.
41

42. Der Unterschied hierbei ist, dass dieses Basisimage bereits den vorhandenen Templates
zugeordnet ist. Benutzer erhalten abhängig von der konfigurierten „Refresh Policy“ im
Template, bei z.B. einem Reboot, virtuelle Desktops auf Basis des geänderten Images.
Vorhandenes Image reparieren
In einzelnen Fällen kann es vorkommen, dass ein Image nicht zuverlässig auf alle VDI-in-
a-Box Manager repliziert wurde. Diese Images erscheinen dann in der Konsole unter
„Images“ als „Broken“.
42

43. Mit einem Klick auf den „Broken“ Link startet ein Dialog, der weitere Informationen über
das Image zur Verfügung stellt. Hier kann dann mit einem weiteren Klick auf das
Schraubenschlüssel Icon das Image repariert werden.
Nach einer Bestätigung wird das Basisimage erneut an alle VDI-in-a-Box Manager verteilt.
Vorhandenes Image löschen
Vorhandene Basisimages können mit einem Klick auf „Delete“ gelöscht werden. Natürlich
folgt noch eine Warnung, die mit „Confirm“ bestätigt werden muss.
Es gibt keinen Papierkorb! Ein einmal gelöschtes Image wird endgültig
entfernt und lässt sich nicht wieder herstellen. Alle erstellten virtuellen
Desktops werden ebenfalls entfernt und stehen den Benutzern nicht mehr
zur Verfügung.
43

44. Verwalten von Templates
Neues Template erstellen
Ähnlich wie bei dem vorangegangenen Abschnitt wird ein neues Template auf der
Karteikarte „Templates“ mit einem Klick auf „Add“ erstellt.
Dieser Vorgang ist identisch mit der Beschreibung in Kapitel Schritt 3 - Erstellen eines
Templates.
Templates kopieren
Kopieren von Templates funktioniert ebenso unkompliziert wie das Anlegen von neuen
Templates. Einfach den „Copy“ Link anklicken und der bekannte Assistent öffnet sich mit
den bereits vorbelegten Feldern. Nach dem Speichern steht das Template zur
Konfiguration neuer oder vorhandener Benutzer, Gruppen oder IP-Adressbereichen zur
Verfügung.
Templates bearbeiten
Templates können natürlich auch bearbeitet werden. Auch hier reicht ein Klick auf den
Namen des Templates, um das Template im Assistenten zu bearbeiten. Ein Klick auf
„Save“ speichert das Template wieder. Die Änderungen werden, abhängig von der
konfigurierten „Refresh Policy“, auf die virtuellen Desktops angewendet. Manchmal kann
44

45. es erforderlich sein, den Browser zu beenden und das Webinterface erneut aufzurufen, um
die Änderungen zu sehen.
Templates löschen
Mit einem Klick auf den „Delete“ Link kann ein Template gelöscht werden. Auch hier muss
noch der Sicherheitshinweis mit „Confirm“ bestätigt werden, bevor das Template
endgültig gelöscht wird.
Verwalten von Desktops, Sessions und Benutzern
Das komplette Management von Desktops, Sessions und aktiven Benutzern wird unter
dem Reiter „Desktops“ vorgenommen. Hier stehen zwei weitere Reiter zur Verfügung, die
eine Art Dashboard bereitstellen.
Summery
Wie der Name schon sagt, finden wir hier eine Zusammenfassung der VDI-in-a-Box
Umgebung. Im oberen Teil befindet sich eine Kapazitätsanzeige, in der man sich schnell
einen Überblick über die Auslastung der Umgebung verschaffen kann.
In dieser kleinen Balkengrafik sehen wir relativ übersichtlich, welche Kapazitäten in der
VDI-in-a-Box Umgebung belegt sind und welche uns für virtuelle Desktops noch zur
Verfügung stehen. Die Prozentzahl am Ende der Grafik gibt die aktuelle Auslastung an und
die einzelnen Desktops werden farblich wie folgt gekennzeichnet:
45

46. ‣ Grün = gestarteter Desktop
‣ Gelb = Vorab gestarteter Desktop
‣ Dunkelgrau = Anzahl max. Startbarer Desktops
Direkt unter der Balkengrafik stehen dann die Informationen zu den konfigurierten
Templates.
Hier sehen wir dann auch die maximale Anzahl von Desktops pro Template, wie viele
davon gestartet werden und natürlich die Anzahl der benutzen, gestarteten oder defekten
virtuellen Desktops. In der letzte Spalte ist die konfigurierte Refresh Policy zu sehen. Mit
einem Klick auf diese Links, können wir in die Policy eingreifen und alle Desktops, die sich
aktuell in Verwendung befinden, sofort manuell erneuern.
Mit einem Klick auf „Confirm“ werden alle Desktops mit dem Status „In Use“ erneuert.
Über den erfolgreichen oder auch fehlgeschlagenen Refresh informiert dann noch ein
kleines zusätzliches Fenster.
User Sessions
Auf der Seite „User Sessions“ erhalten wir einen schnellen Überblick über alle gestarteten
virtuellen Desktops. Hier finden wir die Zuordnung von User ID, verwendetes Template,
Name der virtuellen Maschine und deren IP-Adresse. Außerdem noch die Logon Zeit sowie
die Zeit in Stunden und Minuten, die der virtuelle Desktop bereits aktiv ist.
46

47. In der letzten Spalte, mit der Bezeichnung „Ops“, können wir noch einige Aktionen
durchführen. Mit einem Klick auf den Link „Actions“ haben wir die Möglichkeit, den User
abzumelden oder den kompletten virtuellen Desktop zu vernichten.
Je nach im Template konfigurierten Refresh Policy wird der User bei Log Off abgemeldet,
was bei der Policy Einstellung „On Logout“ ebenso wie bei „Destroy“ zum Löschen des
Desktops inklusive der virtuellen Maschine führt. Steht die Refresh Policy auf „Scheduled“
oder „Manual“ wird der User nur abgemeldet und die virtuelle Maschine steht beim
nächsten Logon wieder zur Verfügung.
Bei vielen gestarteten virtuellen Desktops verliert man schnell die Übersicht. Deshalb ist
innerhalb des Reiters „User Sessions“ noch eine Suche integriert. Interessant ist dabei
die Suche nach Server bzw. Template sowie nach dem Status der virtuellen Desktops.
47

48. Verwalten des VDI-in-a-Box Managers
Für die Verwaltung der virtuellen VDI-in-a-Box Manager steht der Reiter „Server“ zur
Verfügung. Hier können fast alle administrativen Tätigkeiten durchgeführt werden. Citrix
hat für die erweiterte Administration auch noch den Reiter „Admin“, wo dann zum
Beispiel die Konfiguration von IP-Adresse des VDI-in-a-Box Manager bearbeitet werden.
Verwalten der Server
Die Serververwaltung ist optisch sehr einfach gehalten. Neben den Informationen, die
schon aus der Desktopverwaltung bekannt sein sollten, finden wir auch hier die
Balkengrafik mit den Kapazitätswerten sowie die Anzahl der einzelnen Desktops. Allerdings
nicht gruppiert nach Template sondern hier eben nach Server.
Ein Klick auf den Namen bzw. die IP-Adresse öffnet die Eigenschaften des gewählten
Servers.
48

49. Neben diversen Informationen zur IP Konfiguration, Servernamen und Hypervisor Daten,
erfahren wir auch die Versionsnummer des aktuell verwendeten VDI-in-a-Box Managers.
Unter „Manage the VDI-in-a-Box server“ können wir den aktuell gewählten Server
deaktivieren und natürlich dann auch wieder aktivieren. Zusätzlich können wir den Server
auch aus dem Grid entfernen. Der Button „Leave Grid“ steht erst dann zur Verfügung,
wenn der Server zuvor mit dem Button „Quiesce“ stillgelegt wurde.
Mit dem dem Button „Configure“ unter „Configure Hypervisor Connection“ können
wir die Verbindung zum Hypervisor konfigurieren.
Die einzelnen Werte stammen aus dem Konfigurationsassistenten und können an dieser
Stelle bearbeitet werden. Auch hier sollte man wissen, was man tut, denn überschreibt
man hier Daten, kann es dazu führen, dass virtuelle Desktops für die Benutzer nicht mehr
erreichbar sind.
Der Abschnitt „Modify VDI-in-a-Box Manager network settings“ gibt uns die
Möglichkeit, die aktuelle Netzwerkeinstellungen des VDI-in-a-Box Managers zu ändern.
Nach dem Import der virtuellen VDI-in-a-Box Appliance steht die Netzwerkschnittstelle der
Appliance auf DHCP. Deshalb werden wir bei der Ersteinrichtung darauf hingewiesen, für
den VDI-in-a-Box Manager eine Reservierung im DHCP Server anzulegen oder eine
statische IP-Adresse zu konfigurieren. Genau diese statische IP-Adresse können wir an
diese Stelle konfigurieren.
49

50. Zusätzlich zu einer dynamischen oder statischen IP-Adresse, können wir hier auch noch
eine manuelle Konfiguration auswählen. Dies macht dann Sinn, wenn eine komplizierte
Netzwerkkonfiguration direkt auf der Konsole in den Linux Netzwerkskripts verwendet
werden soll. Der VDI-in-a-Box Manager kümmert sich in diesem Fall dann nicht um die
Netzwerkkonfiguration. Mehr Informationen dazu befinden sich im Kapitel VDI-in-a-Box
Konsole.
Der letzte Abschnitt, „Manage the VDI-in-a-Box Manager service“ bietet uns neben
einem Reboot und dem Herunterfahren des Servers auch noch einen Selbsttest des
Servers. Das Ergebnis dieses Test erscheint dann unmittelbar im Server Log, das auf jeder
Seite im unteren Bereich zu sehen ist.
50

51. Zusätzlich dazu gibt es auf der Seite „Server“ noch zwei Links zu „Desktops“ und
„Images“. Der Link „Desktops“ öffnet die Desktops Seite. Die Ausgabe unterscheidet
sich nicht von dem, was uns die Seite mit der Desktopverwaltung zeigt.
Die wesentliche Funktion versteckt sich hier hinter dem „Adjust“ Button.
Nach dem Import des VDI-in-a-Box Managers auf einem unterstützten Hypervisor, geht
dieser davon aus, dass alle vorhandenen Ressourcen für virtuelle Desktops zur Verfügung
stehen. In manchen Fällen ist dies jedoch nicht der Fall, z.B. wenn auf dem Hypervisor
51

52. noch andere Server betrieben werden. Die erforderlichen Anpassungen können dann
genau an dieser Stelle vorgenommen werden.
‣ Memory Overhead (MB)
Mit diesem Wert kann Hauptspeicher für andere Maschinen reserviert werden. Die
Werte werden in MB angegeben und können von 0 bis zur Größe des physisch
vorhandenen RAM eingegeben werden. In einer Standardinstallation wird hier bereits 1
GB (1024 MB) für den VDI-in-a-Box Manager reserviert.
‣ Memory Scale Factor
Dieser Wert gibt den Faktor an, wie viel RAM den virtuellen Maschinen basierend auf
dem vorhandenen physischen Speicher zugeordnet werden kann. Die Werte reichen von
0,5 bis 8. Der Standardwert hier ist 1, also pro MB physischen RAM wird einem
virtuellen Desktop 1 MB RAM zugeteilt. Wird der Wert z.B. auf 2 geändert, geht der
VDI-in-a-Box Manager davon aus, dass er bei 24 GB physischen RAM 48 GB an die
virtuellen Desktops verteilen kann. Bei diesem Wert ist Vorsicht geboten. Wie auch bei
allen anderen virtualisierten Umgebungen, ist es keine gute Idee, mehr Speicher zu
vergeben als tatsächlich physikalisch vorhanden ist.
‣ Core Overhead
Dieser Wert entspricht dem Memory Overhead Wert. Hier können basierend auf den
physikalischen CPU Kernen (bei aktivierten Hyper Threading natürlich die doppelte
Anzahl), CPU Kerne für andere virtuelle Maschinen reserviert werden. Die Werte gehen
von 0 bis zur maximalen Anzahl der physisch vorhandenen CPU Kerne. Der
Standardwert ist 0.
‣ Core Scale Factor
Dieser Wert gibt die Anzahl der virtuellen CPUs an, der basierend auf den physisch
vorhandenen CPU Kernen verteilt wird. Die Werte gehen von 1 bis 20, der Standardwert
dabei ist 6. Das bedeutet pro physischen CPU Kern können 6 virtuelle Desktops mit
jeweils einer vCPU gestartet werden. Weitere Informationen zu den vorgeschlagenen
Werten sind im Kapitel Systemvoraussetzungen - Prozessor zu finden.
Alle, die gern mit diesen Werten rumspielen, können den Button „Defaults“ oder natürlich
den vorangegangen Abschnitt verwenden. Mit einem Klick auf diese Button werden alle
Werte wieder auf ihre Standardwerte zurückgesetzt.
52

53. Der letzte Link mit dem Titel „Images“ öffnet eine Übersicht über die auf dem Server
vorhandenen Images. Auch diese Ansicht sehen wir in ähnlicher Form schon unter dem
Reiter „Images“ in der Webkonsole.
Wie im Kapitel Verwalten von Images - Vorhandenes Image reparieren können wir an
dieser Stelle ein Image mit dem Status „Broken“ versuchen, zu reparieren. Interessant an
dieser Ausgabe ist auch die Zuordnung von Images zu Image-Versionen, die wir mit
diesem Namen als Template auch auf dem Hypervisor finden. Zusätzlich sehen wir auch
den Zustand der Images anhand des grünen oder auch roten Lämpchens und auch, ob die
letzte gültige Image-Version auf dem gewählten Server vorhanden ist.
53

54. Administration der Umgebung
Natürlich gibt es noch weitere Parameter zu konfigurieren, die wir unter dem Reiter
„Admin“ finden.
Advanced Properties
Die wesentlichen Einstellungen finden wir unter „Advanced Properties“. Hier gibt es
einige Einstellungen, welche man unbedingt noch kennen sollte.
54

55. Syslog
Falls man einen externen Syslog-Server betreibt, macht es Sinn, die Logs des kompletten
Grids an eine zentrale Instanz zu schicken. An dieser Stelle wird dieser Server definiert.
Die möglichen Variablen stehen im Feld Syslog-Format und können an die eigenen
Bedürfnisse angepasst werden.
Grid
An dieser Stelle wird die Hochverfügbarkeit eines VDI-in-a-Box Grid konfiguriert. Zuerst
kann festgelegt werden, ob der Server einen Failover beim Verlust des Heartbeats
durchführen soll. Der zweite Parameter gibt an, wie lange der Server beim Verlust des
Heartbeats warten soll, bevor der Failover eingeleitet wird.
MAC Address Pool
In einigen Umgebungen kann es vorkommen, dass z.B. DHCP Server einen Adresspool zur
Verfügung stellen, welcher Adressen auf Basis der MAC Adressen verteilt. Da der VDI-in-a-
Box Manager den virtuellen Desktops dynamisch MAC Adressen zuweist, kann man hier
dieses Verhalten etwas beeinflussen. Allerdings kann man hier nicht völlig eigenständig
agieren, sondern muss sich an gewisse Vorgaben halten. Das Feld „MAC address range
start“ muss mit 00:50:56:[0-3]x:xx:xx beginnen und sollte im Feld „MAC address
range length“ natürlich ausreichend Adressen für die konfigurierten virtuellen Desktops
enthalten.
55

56. SSL Gateway
Falls ein SSL Gateway für den Zugriff auf die Umgebung verwendet wird, können hier die
internen sowie externen IP-Adressen des SSL Gateways konfiguriert werden.
Desktop Sessions
An dieser Stelle können Vorgaben für die Auflösung des virtuellen Desktops hinterlegt
werden. Der Benutzer kann dies im Citrix Receiver bzw. JAVA Client auch selbst wieder
ändern. Möchte man die PassThrough Authentifizierung nicht nutzen, und den Benutzer
zwingen, am Windows Logon Screen erneut sein Passwort einzugeben, dann ist der Haken
bei „Require users to re-enter password on Windows logon screen“ zu setzen.
Miscellaneous
Im unteren Bereich finden sich noch verschiedene, aber nicht ganz unwichtige
Einstellungen.
‣ Enable generic user
aktiviert virtuelle Desktops für z.B. Guest-Accounts. Dieser Punkt wird im weiteren
Verlauf noch eingehend beschrieben.
‣ Retain user credentials
zeigt den Benutzernamen und das maskierte Passwort nach dem Logon an. Diese
Einstellung ist standardmäßig deaktiviert.
56

57. ‣ Max server load (%)
Konfiguriert die physische Auslastung des Server, ab welcher der VDI-in-a-Box Manager
Vollast meldet.
‣ Max server capacity starting desktops (%)
Der Standardwert ist 0.
‣ Users can restart ,active‘ or ,on hold‘ desktops assigned to them
Dieser Wert ist standardmäßig aktiviert und erlaubt einem Benutzer seinen virtuellen
Desktop neu zu starten, solange dieser im Status „active“ oder „On hold“ ist. Leider
wird diese Option in der Dokumentation von Citrix nicht eingehender beschrieben und
ich finde auch keinen tieferen Sinn in dieser Option.
‣ Externally available VDI-in-a-Box Manager address(es)
Sollte noch ein weiterer VDI-in-a-Box Manager existieren, so ist dieser hier einzutragen.
Grid Time
An dieser Stelle können wir die Zeiteinstellungen konfigurieren. Allerdings müssen wir hier
noch einen manuellen Eintrag vornehmen. NTP wird derzeit noch nicht unterstützt.
Zeiteinträge können auch direkt in der Linux Konsole vorgenommen werden.
57

58. Grid Maintenance
Wollen wir Updates installieren oder eine neue Lizenz hochladen, muss das Grid zuerst in
den Wartungsmodus versetzt werden. Im Wartungsmodus kann dieser Server keine
virtuellen Desktops mehr zur Verfügung stellen.
Grid Upgrade
An dieser Stelle werden Updates oder Lizenzen zum Grid hinzugefügt. Zuvor muss
allerdings der Maintenance Mode aktiviert werden.
Sollte der Maintenance Mode noch nicht aktiviert sein, bekommen wir das mit einer
Fehlermeldung auch mitgeteilt.
58

59. Edit Grid Name
Möchte man nach der Installation den Namen der VDI-in-a-Box Umgebung ändern, kann
das hier vorgenommen werden.
Configure User Database
Auch die Benutzerdatenbank kann hier von Workgroup zu Active Directory und auch
wieder zurück geändert werden. Aber Vorsicht: danach sind noch weitere Schritte
erforderlich.
View Audit Log
Für die Fehlersuche sehr hilfreich. An dieser Stelle gibt der VDI-in-a-Box Manager das
Audit Log innerhalb eines zu definierenden Zeitraums aus. Lässt man die Felder leer,
bekommt man das komplette Log angezeigt.
59

60. Download Debug Log
Selbstverständlich können wir auch ein ausführliches Debug Log herunterladen.
Change Console Password
Hinter diesem Link können wir das Passwort des Administrators ändern. Standardmäßig
wird das Passwort „kaviza“ für den Benutzer „vdiadmin“ vergeben. An dieser Stelle
können wir das ändern.
Leider lässt sich hier weder der Benutzername ändern noch weitere administrative
Benutzer hinzufügen. In den folgenden Versionen wird es hoffentlich noch eine
rollenbasierte Administration geben. Aktuell wird das jedoch nicht unterstützt.
Reset Server
Haben wir unseren Server komplett kaputt konfiguriert, können wir mit diesem Link den
VDI-in-a-Box Manager zurücksetzen. Vorsicht, der Server befindet sich nach einem
Neustart im gleichen Zustand wie nach dem Import. Das heißt, es werden sämtliche
Images, Templates, Benutzerinformationen sowie Konfigurationen gnadenlos und
unwiederbringlich gelöscht. Zwar weist uns noch eine Meldung auf diesen Umstand hin,
jedoch setzt ein Klick auf „Confirm“ den Server ohne weitere Rückfrage auf den
Auslieferungszustand zurück.
60

61. Alle Änderungen an der Konfiguration eines VDI-in-a-Box Servers erfordern in der Regel
noch weitere Schritte. Wird die Benutzerdatenbank z.B. von Workgroup auf Active
Directory geändert, müssen natürlich zusätzlich noch die Informationen zur
Authentifizierung am Active Directory (Adminstrator Account, Passwort, Domain, OU etc.)
konfiguriert werden. Umgekehrt erfordern Änderungen von Zugangsdaten an anderen
Komponenten auch zusätzliche Schritte in der VDI-in-a-Box Manager Konsole.
Zugangsdaten Wo anzupassen Wenn nicht angepasst
Zugangsdaten vom Unter dem Reiter Server den entsprech- Keine Verbindung zum
Hypervisor enden Server anklicken und bei Hypervisor mehr
„Configure hypervisor connection“ möglich.
den Button „Configure“ anklicken.
Zugangsdaten des Unter dem Reiter „Admin“ den Link Keine Benutzer
Active Directory „Configure User Database“ anklicken. Authentifizierung mehr
möglich.
Zugangsdaten vom Unter dem Reiter „Images“ bei jedem Neue virtuelle
Domain Controller betroffen Image den Link „Edit“ Desktops können nicht
anklicken. Mit dem Assistenten müssen mehr in die Domäne
alle betroffenen Images angepasst aufgenommen
werden. werden.
61

62. Erweiterte Konzepte
In einigen Umgebungen sind noch andere Konzepte möglich, um eine VDI-in-a-Box
Umgebung in die vorhandene Infrastruktur zu integrieren. Diese Konzepte und deren
Konfiguration beschreibe ich im folgenden.
Kiosk Mode
Der Kiosk Mode ist prinzipiell nichts anderes als nicht persistente virtuelle Desktops.
Überall, wo eine größere Anzahl an Standard Desktops benötigt wird, z.B. in Klassen- oder
Konferenzräumen, kann dieses Szenario eingesetzt werden. Wie jeder andere virtuelle
Desktop basieren auch diese Standard Desktops auf ganz normalen Templates. In der
Regel werden diese Templates jedoch basierend auf den IP-Adressen der Endgeräte
zugewiesen.
Ist dieser „Kiosk Mode“ konfiguriert, und es kommt zu einem Konflikt zwischen einem
Benutzer und der verwendeten IP Adresse seines Endgeräts, bekommt der Kiosk Mode die
höhere Priorität.
In einem Kiosk Mode Deployment ist es besonders wichtig, die Zahl der verwendeten
Images und Templates so klein wie möglich zu halten. Idealerweise benutz man lediglich
ein Basisimage mit einem einzigen Template. Dieses Template wird dann einem IP
Adressbereich zugeordnet. Wenn diese Trennung von Templates für Kiosk Mode Desktops
und Templates für andere Benutzer beibehalten wird, ist das Monitoring von Desktops im
Kiosk Mode über den Reiter „User Sessions“ innerhalb des Reiters „Desktops“ sehr
einfach.
Templates für virtuelle Desktops sollten per „Refresh Policy“ im Templates täglich,
vorzugsweise nachts, neu erstellt werden. Bei öffentlichen Terminals sollte die „Refresh
Policy“ auf „On Logout“ stehen, um sicherzustellen, dass neue Benutzer einen frischen
Desktop bekommen. Sollte es bei einigen Benutzern zu lange dauern, bis ein neuer
Desktop zur Verfügung steht, kann auch der Haken bei „Fast desktop refresh“ im
Template gesetzt werden.
Im Template sollte auch darauf geachtet werden, dass eine ausreichende Anzahl von
Desktops bereits gestartet wurde („Pre started desktops“) und mit dem Windows Logon
Screen wartet. Steht dieser Wert z.B. auf 5, werden 5 Desktops vorab gestartet. Melden
sich jetzt zwei neue Benutzer an, werden ihnen bereits gestartete Desktops zur Verfügung
gestellt. Der VDI-in-a-Box Manager startet dann zwei neue Desktops, damit die Zahl der
verfügbaren Desktops wieder 5 beträgt. Dies wird solange durchgeführt, bis der Wert in
„Maximal Desktops“ erreicht ist.
62

63. Im reinen Kiosk Mode muss sich der Benutzer immer noch mit einem gültigen User
Account am virtuellen Desktop anmelden.
Generic User Support
Ein etwas anderes Konzept verfolgt die „Enable generic user“ Option in den „Advanced
Properties“. Der VDI-in-a-Box Manager kann jedoch auch zur Benutzung mit einem
generischen User Account (z.B. Guest) konfiguriert werden. Standardmäßig lassen es die
Sicherheitseinstellungen des VDI-in-a-Box Manager nicht zu, dass ein Benutzer mehrere
Desktops startet. Bleibt ein Benutzer auf einem Gerät an einem virtuellen Desktop
angemeldet und meldet sich zusätzlich an einem anderen Endgerät an, wird seine
bestehende Session auf das neue Gerät übertragen (Session Reconnect). Die „Enable
generic user“ Option überschreibt diese Einstellung und ermöglicht es so, dass sich
mehrere User mit dem gleichen Benutzerdaten anmelden können und jeweils einen neuen
virtuellen Desktop erhalten. Die Refresh Policy in den Template Einstellungen muss hierbei
auf „On Logout“ gestellt werden, damit jeder generische Benutzer auch einen neuen
virtuellen Desktop erhält. Anders als beim Kiosk Mode werden die entsprechenden
Templates für für generische Benutzer auf Benutzerbasis zugeordnet.
Auch hier gilt es, die Anzahl der verwendeten Images und Templates auf ein Minimum zu
reduzieren. In der Regel sollte ein Basisimage sowie ein Template für generische Benutzer
ausreichend sein. Für generische Benutzer gelten die gleichen Bedingungen im Bezug auf
Pre-started und max. Desktops, wie zuvor im Abschnitt Konfiguration des Kiosk Mode
beschrieben. Zu beachten ist aber bei beiden Konzepten, dass entsprechende
Benutzerkonten innerhalb des Images konfiguriert sind (z.B. aktivieren und konfigurieren
des Guest Accounts, der ja standardmäßig bei Windows deaktiviert ist).
Sicherer Remote Access
Für den sicheren Zugang auch außerhalb des Unternehmens kann an dieser Stelle ein
Citrix Access Gateway eingesetzt werden. Das Access Gateway steht als virtuelle Appliance
63

64. mit der Bezeichnung Citrix Access Gateway VPX auf den Citrix Webseiten zum download
bereit. Für einen einfachen Einstieg existiert auch eine kostenlose Express Version, die es
erlaubt, erstmal ohne Lizenzkosten das Produkt auch im Zusammenspiel mit VDI-in-a-Box
zu testen.
Die Beschreibung der Konfiguration eines Citrix Access Gateway VPX würde dieses
SmartBook sprengen. Tiefergehende Informationen erhalten sie auf der Website von
Citrix, entsprechende Links dazu finden sie im Anhang. Auf eine kurze Einleitung, gerade
im Zusammenhang mit VDI-in-a-Box, möchte ich jedoch nicht verzichten.
Wenn die Basiskonfiguration des Citrix Access Gateways abgeschlossen ist, sind einige
wesentliche Konfigurationen zu erledigen. Wichtig an dieser Stelle ist, dass aus Sicht des
Access Gateway, alle VDI-in-a-Box Zugangspunkte als einfache Webinterfaces behandelt
werden. In der Access Gateway Konsole wird dann „Authenticate with Web Interface“
gewählt, um die Kommunikation mit dem VDI-in-a-Box Manager zu erlauben. Als Logon
Point wird die URL des VDI-in-a-Box Managers (z.B. https://<IP-Adresse>) und für den
Java Client der vollständige Pfad (z.B. https://<IP-Adresse>/dt/vdiclient.jnlp) verwendet.
Abschließend muss noch festgelegt werden, welcher Logon Point als Standard benutzt
werden soll. Zusätzlich muss jeder VDI-in-a-Box Manager innerhalb des Grid als Secure
Ticket Authority hinzugefügt werden, wobei der Connetion Type „unsecure“ gewählt
werden muss. Der Port wird dabei auf 80 (oder falls ein eigener Port verwendet wird
natürlich dieser) und der Pfad auf /dta/sta gesetzt.
Abschließend müssen noch die IP-Adressen der virtuellen Desktops unter „ICA Access
Control Entry“ eingetragen und als Protokoll „ICA und CGP“ gewählt werden. Die
Konfiguration ist damit abgeschlossen. Jetzt muss das Citrix Access Gateway noch im VDI-
in-a-Box Manager konfiguriert werden.
64

65. Die Einstellungen dafür sind in den „Advanced Properties“ unter dem Reiter „Admin“
zu finden.
Im Abschnitt „SSL Gateway“ muss unter „External SSL gateway address(es)“ noch
der FQDN des Access Gateways (inkl. Port z.B. https://<CAG-FQDN>:443) eingetragen
werden. Sind mehrere Gateway FQDNs konfiguriert, werden hier alle, getrennt durch ein
Semikolon eingetragen. Die „Internal SSL gateway IP address(es)“ des Citrix Access
Gateway müssen in der gleichen Reihenfolge eingegeben werden, wie bereits bei
„External SSL gateway address(es)“ angegeben. Für den Zugriff der Endgeräte auf
virtuelle Desktops wird nun die folgende URL verwendet:
https://<CAG-FQDN>/http/<vdiManager IP-Adresse>/dt/PNAgent/config.xml
Hier muss man aufpassen: Die Angabe von PNA bzw. PNAgent unterscheidet zwischen
Groß- und Kleinschreibung.
Benutzer Profil Management
Auch bei virtuellen Desktops mit VDI-in-a-Box muss sich ein Administrator einige
Gedanken über die Benutzerprofile machen. Prinzipiell kann VDI-in-a-Box mit allen am
Markt verfügbaren Profilmanagement Lösungen betrieben werden. Auch die von Windows
verwendeten „Roaming Profiles“ sind eine denkbare Alternative. Citrix bietet seit einiger
Zeit die von der Firma Sepago erworbene User Profile Management Lösung gemeinsam
mit Citrix XenApp und Citrix XenDesktop an. Auch für VDI-in-a-Box kann das Citrix Profile
Management von den Download Seiten heruntergeladen und verwendet werden.
Weitere Informationen zum Einsatz und der Konfiguration des Citrix Profile Management
finden sie in den Links im Anhang.
VDI-in-a-Box Command Line Interface
Da es sich bei der virtuellen VDI-in-a-Box Appliance um eine auf CentOS Linux
basierenden Maschine handelt, kann man sich auch direkt an der Konsole anmelden.
65

66. Anmelden kann man sich mit dem Benutzer „kvm“ und dem Passwort „kaviza123“. Hier
stehen alle von Linux bekannten Tools und Skripte zur Verfügung. Insbesondere eine
komplizierte Netzwerk-Konfiguration kann hier über die CentOS Netzwerkskripte
vorgenommen werden.
Vorsicht, der VDI-in-a-Box Manager hat keine Kenntnis von Änderungen,
die auf der Linux Konsole vorgenommen werden. Im ungünstigsten Fall
wird der Server dadurch komplett unbrauchbar. Wenn sie nicht genau
wissen, was sie dort machen, dann Finger weg.
Die Skripte für Netzwerk-Konfiguration liegen unter /etc/sysconfig/network-scripts/. Die
virtuelle Appliance hat nur ein virtuelles Netzwerkinterface, deshalb sollte die einzig
verfügbare Schnittstelle eth0 sein. Um diese Datei zu bearbeiten, geben wir am Prompt
folgendes ein (Password für das su Kommando ist auch hier „kaviza123“):
kvm@vdimgr:/$ su
Password:
[root@vdimgr]# vi /etc/sysconfig/network-scripts/ifcfg-eth0
Diese Datei kann dann von einem Administrator entsprechend der eigenen Infrastruktur
angepasst werden. Nicht vergessen: nach dem Speichern der Datei, die Netzwerkdienste
neu zu starten -> [root@vdimgr]# service network restart. Alle
Konfigurationen auf der Kommandozeilenebene setzen gute Linux Kenntnisse bzw.
Kenntnisse im Umgang mit CentOS voraus.
66

67. Konfiguration der Endgeräte
Benutzer können mit ihren Endgeräten im wesentlichen über zwei Protokolle zugreifen. Als
Standardprotokoll ist natürlich das Citrix HDX Protokoll vorgesehen. Für den Zugriff über
das HDX Protokoll ist ein Server-Side Agent sowie ein Client-Side Agent erforderlich. Der
Server-Side Agent wird bereits mit der VDI-in-a-Box Client Komponente installiert und der
Clients-Side Agent wird durch den Citrix Receiver zur Verfügung gestellt. Für Endgeräte
ohne Citrix Receiver steht auch ein Java Client zur Verfügung. Die Kommunikation mit dem
VDI-in-a-Box Manager für Citrix Receiver und Java Client zeigt das folgende Diagramm.
1. Aufbau einer Verbindung mit dem Webbrowser auf http://<IP Adresse des
vdiManagers> bzw. mit dem Java Client auf http://<IP Adresse des
vdiManagers>/dt/vdiclient.jnlp.
2. Übertragen der .ICA Datei mit den Informationen zum virtuellen Desktop.
3. Weiterleiten der Informationen in der .ICA Datei zum HDX Client-Side Agent.
4. Herstellen der Session.
Der Java Clients verwendet, sobald kein Citrix HDX verfügbar ist, automatisch das RDP
Protokoll.
67

68. Microsoft Windows, Mac OS X oder Linux
Der Zugriff auf einen virtuellen Desktop erfolgt in der Regel über das Webinterface des
VDI-in-a-Box Managers. Über einen Webbrowser erreicht man das Webinterface unter
https://<IP Adresse des vdiManagers>. Gegebenenfalls müssen hier noch die
Sicherheitswarnungen des Zertifikats bestätigt werden.
Bei direkten Zugriff über den Citrix Receiver muss der Receiver mit der URL https://<IP
Adresse des vdiManagers>/dt/PNAgent/config.xml sowie mit dem Benutzernamen
und Passwort eines im VDI-in-a-Box Manager eingerichteten Benutzers konfiguriert
werden.
Für den Zugriff per RDP steht in Windows XP der native Client mit der RDP Version 6, bzw.
unter Windows 7 die RDP Version 7 zur Verfügung. Zur Nutzung aller RDP Version 7
Features empfiehlt Citrix den Zugriff auf virtuelle Desktops unter Windows 7 mit einem
Endgerät ebenfalls mit Windows 7. RDP Clients stehen für Mac OS und Linux ebenfalls zur
Verfügung.
‣ Mac OS Remotedesktop http://www.microsoft.com/mac/remote-desktop-client
‣ Linux rdesktop 1.7.0 http://www.rdesktop.org
Verbindungen mit dem Java Client habe ich im Kapitel Verbindung testen ausführlich
beschrieben. Allerdings besteht beim Java Client auch der Zugriff über die Konsole. Hier ist
dann der Befehl javaws://<IP Adresse des vdiManagers>/dt/vdiclien.jnlp
einzugeben und gegebenenfalls die Zertifikate der Website zu bestätigen. Danach startet
der VDI-in-a-Box Java Client.
Apple iOS oder Android
Der Zugriff auf virtuelle Desktops unter iOS (iPhone / iPad) oder Android unterscheidet
sich an dieser Stelle etwas. Sollen diese Geräte auf virtuelle Desktops zugreifen können,
ist es erforderlich, dass die VDI-in-a-Box Manager Mitglieder einer Active Directory
Domäne sind.
Für den Zugriff wird im Citrix Receiver ein neuer Account angelegt, der auf die URL
https://<IP Adresse des vdiManagers>/dt/PNAgent/config.xml zeigen muss.
Beim Dialog für Benutzername und Passwort sollte man etwas vorsichtig sein. Wird hier
zusätzlich zum Benutzernamen auch das Passwort eingegeben, wird dieses gespeichert.
Jeder, der Zugriff auf das Endgerät hat, kann dann einen virtuellen Desktop ohne weitere
Benutzerüberprüfung starten.
Wie der Citrix Receiver für Mobile Endgeräte konfiguriert wird beschreibt Citrix unter
http://support.citrix.com/proddocs/topic/receiver/receiver-mobile-devoces-wrapper.html
68

69. Anhang A: Nützliche Links
‣ VDI-in-a-box Startseite
http://www.citrix.com/English/ps2/products/product.asp?contentID=2316437
‣ Support Portal
http://community.citrix.com/p/vdi-in-a-box/
‣ Downloadseite
http://www.citrix.com/English/ss/downloads/results.asp?productID=2316437
‣ Resources
http://www.citrix.com/English/ps2/products/feature.asp?contentID=2316439
‣ Dokumentationen
http://support.citrix.com/proddocs/topic/vdi/vdi-landing-page-main.html
‣ Registrierung als Citrix Partner
https://secureportal.citrix.com/mycitrix/partner/qualification/default.aspx#SetFocus
‣ Training und Zertifizierung
http://www.citrix.com/smbtraining
‣ Citrix Receiver
http://www.citrix.com/receiver/
Weitere kostenlose Whitepaper
‣ 10 Schritte zum erfolgreichen Bring Your Own Device Programm
https://www.thomas-krampe.com/BringYourOwnDevice.html
‣ Apple im Unternehmen
https://www.thomas-krampe.com/apple_enterprise.html
69

70. Über den Autor
Thomas Krampe ist IT Architekt, Virtualization Evangelist,
Technology Analyst und Autor von diversen Whitepaper, Artikeln
und Blogbeiträgen. Mit mehr als 15 Jahren Berufs- und
Projekterfahrung in Großkonzernen sowie weltweit agierenden
Unternehmensberatungen wurde er 2009 von Citrix als Citrix
Technology Professional, einem ausgewählten Kreis von derzeit
42 Personen weltweit, ausgezeichnet. Zur Zeit ist Thomas Krampe
als Manager Enterprise Services bei der visionapp AG tätig und
verantwortet mit einem kleinen Team den 365/24/7 Betrieb einer
Grid Computing Umgebung bestehend aus mehr als 2.500 Blade-
Server bei einer deutschen Großbank. Zusätzlich zu seiner Tätigkeit als Manager und Autor
hält er Vorträge und Präsentationen auf vielen regionalen und überregionalen
Veranstaltungen, unter anderem auf der Citrix Synergy in den USA und EMEA sowie bei
den Citrix Geek-Speaks in den DACH Regionen.
‣ https://www.thomas-krampe.com
‣ https://blog.thomas-krampe.com
‣ http://wiki.xenmaster.de
70

71. © Thomas Krampe, 2011. Alle Rechte vorbehalten.
Die in diesem Dokument enthaltenen Informationen, Konzepte und Ideen sind Eigentum von Thomas
Krampe. Eine Weitergabe, auch in Auszügen, ohne die Zustimmung von Thomas Krampe ist nicht gestattet.
Alle in diesem Dokument verwendeten Markennahmen sind Eigentum der jeweiligen Markeninhaber.
Die in diesem Dokument enthaltenen Informationen und Daten können sich ohne vorherige Ankündigung
ändern.
71