Citrix VDI-in-a-Box Installation - Konfiguration - Management

© 2011 Thomas Krampe - Alle Rechte vorbehalten.

VorwortDieses 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

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

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

EinleitungIm 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.

5

1 Virtual Desktop Infrastructure

2 Bring Your Own Device

ArchitekturübersichtDie 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

63 Citrix XenServer, VMware ESXi oder Microsoft Hyper-V

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.

74 Work Load Balancing

Systemvoraussetzungen

HypervisorFü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

Hardware VoraussetzungenFü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 ManagerDie 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)

ProzessorTypischerweise 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

HauptspeicherDie 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

FestplattenDie 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-VBeim 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

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 BasisimagesAktuell 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

Unterstützte Endgeräte/ BetriebssystemeZugriffe 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

VDI-in-a-Box Manager importierenBevor 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

Import mit dem Citrix XenCenterFü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

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

Konfigurieren des VDI-in-a-Box ManagerZur 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

Schritt 1 - Hypervisor SetupZuerst 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

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

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

Schritt 2 - Erstellen des BasisimagesBevor 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 BasisimagesSobald 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

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

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

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

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

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

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

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

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

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

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

Schritt 3 - Erstellen eines TemplatesVirtuelle 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

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

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 PoliciesEs 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.

‣ ScheduledHier kann auf Tage-, Wochen- oder Monatsbasis eine geplante Aktualisierung definiert

werden. Zusätzlich kann angegeben werden, ob der Desktop auch dann aktualisiert

33

werden soll, wenn er in Benutzung ist. Werden Desktops in Benutzung ausgenommen, aktualisieren sich diese erst bei Abmeldung des Benutzer.

‣ Scheduled or On LogoutDiese 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.

‣ ManualDiese 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

Schritt 4 - Benutzer anlegen und zuordnenZuvor 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

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

Verbindung testenUm 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 Receiver1. Ö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 Client1. Ö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

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

VDI-in-a-Box Verwaltung

Verwalten von Images

Neues Image erstellenUm 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 kopierenDas 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

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 bearbeitenEiner 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

Ü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

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 reparierenIn 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

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öschenVorhandene 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

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 kopierenKopieren 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 bearbeitenTemplates 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

es erforderlich sein, den Browser zu beenden und das Webinterface erneut aufzurufen, um die Änderungen zu sehen.

Templates löschenMit 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 BenutzernDas 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.

SummeryWie 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

‣ 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 SessionsAuf 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

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

Verwalten des VDI-in-a-Box ManagersFü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 ServerDie 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

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

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

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

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 FactorDieser 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 OverheadDieser 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 FactorDieser 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

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

Administration der UmgebungNatürlich gibt es noch weitere Parameter zu konfigurieren, die wir unter dem Reiter „Admin“ finden.

Advanced PropertiesDie wesentlichen Einstellungen finden wir unter „Advanced Properties“. Hier gibt es einige Einstellungen, welche man unbedingt noch kennen sollte.

54

SyslogFalls 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.

GridAn 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 PoolIn 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

SSL GatewayFalls 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 SessionsAn 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.

MiscellaneousIm 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

‣ 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 themDieser 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 TimeAn 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

Grid MaintenanceWollen 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 UpgradeAn 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

Edit Grid NameMöchte man nach der Installation den Namen der VDI-in-a-Box Umgebung ändern, kann das hier vorgenommen werden.

Configure User DatabaseAuch 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 LogFü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

Download Debug LogSelbstverständlich können wir auch ein ausführliches Debug Log herunterladen.

Change Console PasswordHinter 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 ServerHaben 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

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 Hypervisor

Unter dem Reiter Server den entsprech-enden Server anklicken und bei „Configure hypervisor connection“ den Button „Configure“ anklicken.

Keine Verbindung zum Hypervisor mehr möglich.

Zugangsdaten des Active Directory

Unter dem Reiter „Admin“ den Link „Configure User Database“ anklicken.

Keine Benutzer Authentifizierung mehr möglich.

Zugangsdaten vom Domain Controller

Unter dem Reiter „Images“ bei jedem betroffen Image den Link „Edit“ anklicken. Mit dem Assistenten müssen alle betroffenen Images angepasst werden.

Neue virtuelle Desktops können nicht mehr in die Domäne aufgenommen werden.

61

Erweiterte KonzepteIn 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 ModeDer 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

Im reinen Kiosk Mode muss sich der Benutzer immer noch mit einem gültigen User Account am virtuellen Desktop anmelden.

Generic User SupportEin 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 AccessFü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

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

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 ManagementAuch 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 InterfaceDa 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

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“):

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.

kvm@vdimgr:/$ suPassword:[root@vdimgr]# vi /etc/sysconfig/network-scripts/ifcfg-eth0

66

Konfiguration der EndgeräteBenutzer 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

Microsoft Windows, Mac OS X oder LinuxDer 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 AndroidDer 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

Anhang A: Nützliche Links‣ VDI-in-a-box Startseite

http://www.citrix.com/English/ps2/products/product.asp?contentID=2316437

‣ Support Portalhttp://community.citrix.com/p/vdi-in-a-box/

‣ Downloadseitehttp://www.citrix.com/English/ss/downloads/results.asp?productID=2316437

‣ Resources

http://www.citrix.com/English/ps2/products/feature.asp?contentID=2316439

‣ Dokumentationenhttp://support.citrix.com/proddocs/topic/vdi/vdi-landing-page-main.html

‣ Registrierung als Citrix Partnerhttps://secureportal.citrix.com/mycitrix/partner/qualification/default.aspx#SetFocus

‣ Training und Zertifizierunghttp://www.citrix.com/smbtraining

‣ Citrix Receiverhttp://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 Unternehmenhttps://www.thomas-krampe.com/apple_enterprise.html

69

Über den AutorThomas 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

© 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