4. Dezember 2014

Storefront Stores mit Beschreibung

Hat sich noch jemand gewundert, wie eine Beschreibung in das Dialogfeld des Citrix Receivers kommt, wenn mehr als ein Store zur Auswahl steht? Oder warum manche Stores als (primary) gekennzeichnet werden, wenn der User in seinem Receiver die Liste der konfigurierten Konten anzeigt?

Die gewünschten Beschreibungen können pro Store in einer Datei hinterlegt werden, der Pfad der Datei ist für Storefront 2.6:
c:\inetpub\wwwroot\Roaming\web.config

Hierin findet sich für jeden Store eine Sektion, unterhalb des XML-Pfads
configuration / citrix.deliveryservices / RoamingRecords / Accounts
mit Namen <account>, in der das passende Feld namens "description" mit dem gewünschten Inhalt gefüllt werden kann. Die Zeilennummern aus dem nachstehenden Screenshot können natürlich variieren.


Mit den obigen Inhalten gefüllt wird dem User im Receiver nun beim Auflisten der Stores (falls mehrere Stores vorhanden sind), oder im Accounts-Dialog nach der Konfiguration die Beschreibung angezeigt.



Happy hunting!

22. August 2014

Citrix Default Passwords

Wer hat sich schon mal gefragt, wie der Admin-Account der gerade frisch heruntergeladenen Virtual Appliance ist? Oder der Portal-Login für einen NetScaler? Ich habe die Standard-Passwörter (sofern mir bekannt) hier mal in einer Tabelle zusammengefasst. Wenn Ihnen weitere bekannt werden, hinterlassen Sie bitte einen Kommentar auf dieser Site, ich werde den Beitrag dann erweitern.
Produkt Username Passwort Konfigurationsweg
Access Gateway 5.x admin admin https://<ipaddress>/lp/adminlogonpoint
App Controller 2.5 administrator password https://10.20.30.40:4443/ControlPoint
Branch Repeater 6.x Admin password http://<ipaddress>
CloudPlatform 3.x admin password http://<ipaddress>:8080/client
Distributed Virtual Switch Controller admin admin https://<ipaddress>
Merchandising Server 2.2 root C1trix321 https://<ipaddress>:/appliance
Netscaler nsroot nsroot https://<nsip>
VDI-in-a-Box vdiadmin kaviza https://<ipaddress>/admin
VDI-in-a-Box (appliance) kvm kaviza123 putty / console

20. Februar 2014

XenDesktop 7 – published Desktop, aber nicht für alle

Hat noch jemand den Release Candidate von Citrix XenDesktop 7 in Erinnerung? Dort waren Delivery Groups (Bereitstellungsgruppen) für die Freigabe von Desktops getrennt von den Delivery Groups für die Freigabe von Anwendungen zu erstellen. Bei XenApp 6.5 und früheren Versionen war es kein Problem von einer Maschine sowohl den Desktop als auch verschiedene Apps freizugeben – dies schien XenDesktop 7 nicht zu unterstützen.

Das Produkt ist mittlerweile auf dem Markt und die gleichzeitige Freigabe von Desktops und Apps innerhalb einer Delivery Group ist kein Problem – beim Anlegen der Delivery Group kann der Admin entscheiden, ob er diese für Apps, Desktop oder beides nutzen will, wie der folgende ScreenShot zeigt:

2014-02-20_10h08_33

Aber im weiteren Verlauf muss der Admin Gruppen oder User definieren, die auf die Delivery Group Zugriff haben sollen – und damit später auch auf den (einzigen) freigegebenen Desktop und die freigegebenen Apps dieser Bereitstellungsgruppe. Im ScreenShot im unteren Beispiel sollen später Apps für die “Doctor-Group” und die “Nurse-Group” bereitgestellt werden, während gleichzeitig ein Desktop für die “helpdesk-group” freigegeben werden soll.

2014-02-20_09h14_58

Damit die Helpdesk-User nun nicht die ganzen einzelnen Apps sehen, oder die Mitglieder der “Nurse-Group” nicht Zugriff auf die Apps für die “Doctor-Group” haben, kann der Admin in den Eigenschaften der jeweiligen App die Sichtbarkeit der App auf bestimmte Gruppen einschränken. Diese Gruppen *müssen* allerdings prinzipiell Zugriff auf die Delivery Group zu haben, es handelt sich hier also eine Teilmenge der genannten Gruppen. Im unteren Beispiel wird die Anwendung “InfoPath Designer 2013” nur für Mitglieder der “Doctor-Group” freigegeben – Benutzer der “Nurse-Group” und “Helpdesk-Group” werden diese Anwendung also nicht sehen.

2014-02-20_09h15_55

Daraus ergibt sich jedoch das Problem, dass der über die Delivery Group freigegebene Desktop nun prinzipiell auch allen anderen Benutzern angezeigt wird – denn zumindest die GUI, also Citrix Studio, bietet keine Option, die Sichtbarkeit des Desktops einzuschränken (limit visibility).

Das folgende Diagramm soll dies verdeutlichen:

image

Deshalb hat der angemeldete Benutzer im ScreenShot unten (nurse1) auch neben dem Zugriff auf den dedizierten Desktop für die Benutzergruppe (aus einer anderen Delivery Group) zusätzlich Zugriff auf den eigentlich unerwünschten Desktop für die “Helpdesk-Group”. Wer nun die “Nurse-Group” aus der Delivery Group selbst entfernt, verhindert den Zugriff der “Nurse-Group”-Mitglieder auf sämtliche freigegebenen Apps der kompletten Delivery Group.

2014-02-20_09h09_53

Die Lösung des Problems liegt, wie bei XenDesktop 7 so oft, im Einsatz von PowerShell – sogar ein vergleichsweise simples Kommando schafft eine effektive Filterlösung für die Anzeige oder das Unterdrücken des Desktops.

Ok, nach dem Start einer PowerShell Eingabeaufforderung müssen zunächst die Citrix SnapIns geladen werden. Es reicht eigentlich das SnapIn “Citrix.Broker.Admin.V2” – dieses kann durch das Kommando Add-PSSnapin Citrix.Broker.Admin.V2 eingebunden werden.

Das Kommando Get-BrokerEntitlementPolicyRule zeigt nun die verfügbaren Filter für die existierenden Delivery Groups an – die passende Gruppe kann über den Namen oder die UID gefunden werden – notfalls im Zusammenspiel mit Get-BrokerDesktopGroup, oder schöner:
Get-BrokerDesktopGroup | format-list name,uid

In meinem Beispiel muss eine Filterregel für die Delivery Group “Medical Applications” erstellt werden. Diese Gruppe enthält Windows Server 2012 R2 VMs mit dem Server OS VDA und gibt sowohl Desktops als auch Apps frei – die Desktops allerdings sollten nur für die Helpdesk-Gruppe sichtbar sein…

image

Die Uid der Delivery Group bitte nicht mit der Uid der Entitlement Policy Rule verwechseln – die Referenz wird hier über die DesktopGroupUid hergestellt.

image

Die zu benötigte Entitlement Policy Rule wird mit Set-BrokerEntitlementPolicyRule erstellt – dabei wird die zuvor ermittelte Delivery Group namentlich referenziert.
Der PowerShell Befehl kann mit den Parametern –IncludedUserFilterEnabled und –ExcludedUserFilterEnabled zwei verschiedene Filter aktivieren, je nachdem, ob ich von 20 ursprünglich auf der Delivery Group definierten Gruppen eine Gruppe explizit ausschließen ("Die nicht!") will, oder nur noch eine (oder wenige) Gruppe für den freigegebenen Desktop berechtigen will ist also eine Blacklist oder Whitelist zu pflegen.

Die User können für beide Varianten hinzugefügt und entfernt werden, so wird eine bestehende Liste ergänzt bzw. überarbeitet, alternativ kann eine bereits erstellte Liste von Usern komplett ersetzt/bestimmt werden, wobei vorherige Einträge überschrieben werden. Die Parameter sind dann passend –AddIncludedUsers, –RemoveIncludedUsers, –AddExcludedUsers oder –RemoveExcludedUsers. Wer die ganze Userliste setzen will, kann –ExcludedUsers oder –IncludedUsers benutzen.

Um also für den Zugriff auf den Desktop (!) der "Medical Applications" Delivery Group nur noch die Helpdesk-Gruppe zuzulassen und ergo alle anderen Gruppen, die auf der Delivery Group definiert wurden zwar an Apps, nicht jedoch an den Desktop zu lassen, kann folgendes Kommando benutzt werden:

Set-BrokerEntitlementPolicyRule –Name "Medical Applications_1" –AddIncludedUsers cch\helpdesk-group –IncludedUserFilterEnabled $true

image

Das Ergebnis kann mit Get-BrokerrEntitlementPolicyRule kontrolliert werden:

image

Aus Sicht des Benutzers "fehlt" nun wie gewollt der unerwünscht dargestellte UHD-Desktop. Ziel erreicht :-)

image

Have fun!

5. Februar 2014

XenServer – Software in der Control Domain nachinstallieren

Wer wie ich regelmässiger Gast in der Control Domain eines XenServers ist, wird sich vielleicht das eine oder andere mal Tools vom heimischen Linux gewünscht haben: Midnight Commander, perl oder einfach nur einen FTP Client (vor allem da Transfers über WinSCP aufgrund der Verschlüsselung quälend langsam sind).

Fehlt also ein lokal installierter FTP Client, kann dies in der Control Domain (bei bestehender Internetverbindung) über folgende Befehl erreicht werden:

yum --enablerepo base install ftp

Have fun!

3. Februar 2014

Receiver 4 an Presentation Server 4 – geht doch :-)

In einem XenDesktop Kurs wurde ich jüngst von einem Teilnehmer darauf hingewiesen, dass es Probleme beim Zugriff mit modernen Clients wie Citrix Receiver auf Citrix Presentation Server 4 gäbe. Um diese Probleme zu klären habe ich in einem Lab die Situation nachgestellt und bin auf lediglich zwei triviale Hürden gestossen, abgesehen davon klappt das ganz prima.

Hürde 1: der Start der App aus einem XenApp6.5 – Webinterface (Version 5.4) wird mit der Fehlermeldung verweigert, dass eine „LauncherReference“ fehlt.
Bekanntes Problem bei der Kombination alt & neu. Zur Lösung ist in der WebInterface.Conf der jeweiligen WebSite das Attribut „RequireLaunchReference=Off“ zu setzen (steht normalerweise auf „On“). Dies wäre übrigens mit einem älteren WI nicht nötig gewesen.

Hürde 2:
Die Sitzung läuft innerhalb des Receivers schwerfällig und langsam. Lösung hier ist das Abschalten eines Receiver Features in der Registry (des Clients!).

For x86 Computers

Registry Key: HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\ICA Client\Engine\Lockdown Profiles\All Regions\Lockdown\Virtual Channels\Seamless Windows
Value Name: DeferredUpdateMode
Value Type: REG_SZ
Value: false (instead of default “*”)

For x64 Computers

Registry Key: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\ICA Client\Engine\Lockdown Profiles\All Regions\Lockdown\Virtual Channels\Seamless Windows
Value Name: DeferredUpdateMode
Value Type: REG_SZ
Value: false (instead of default “*”)

Danach stellt sich der Erfolg ein – siehe Screenshot mit aktuellem Datum:

 

image

Have Fun!

7. Januar 2014

XenServer: FastForward und FastRewind

Kennt ihr noch die passenden Tasten am Tapedeck? Oder wenigstens ein Tapedeck? Und Wirken Massen-SnapShots beruhigend? Ein klares Ja.
Aber wann immer ich ein neues Training erstelle, oder ein bestehendes Lab weiterentwickle, muss ich von allen beteiligten VMs in kaltem Zustand (heruntergefahren, gestoppt) einen “Erst-Snapshot” erstellen, um notfalls das Rad der Zeit schnell zurückdrehen zu können ohne direkt ein langwieriges Restore zu beginnen. Aktuelle habe ich 19 VMs vor mir und weigere mich, im XenCenter jede einzelne VM anzuklicken um einen Snapshot nach dem anderen zu erstellen. Das *muss* schneller, einfacher und weniger fehlerträchtig gehen!
Erste Idee war, den Befehl “xe vm-snapshot” mit dem Parameter “--multiple” zu benutzen, allerdings scheint trotz anders lautendem Hilfetext der Parameter “multiple” in diesem Fall nicht unterstützt zu sein. Was bleibt ist die gute alte For-Schleife :-)
---- in der Control Domain des XenServers (Console im XenCenter oder PuTTY/KiTTY) folgende Zeile eingeben (copy & paste?) --------------
for vms in $(xe vm-list is-control-domain=false power-state=halted --minimal|sed 's/,/ /g'); do xe vm-snapshot vm=$vms new-name-label=develop-$(date +'%Y%m%d-%H%M');done
------ Ende der copy & paste Sektion ----------------
Das Ergebnis sind mit aktuellem Datum und Uhrzeit versehene Snapshots, wie im Bild unten dargestellt.
image
Um jetzt zu einem zuvor gesicherten Zustand *labweit* zurückzukehren, kann die folgende CodeZeile benutzt werden:
---------------start-----------------
echo "Enter SnapShot name to revert to:"; read snapname; for vms in $(xe snapshot-list name-label=$snapname --minimal|sed 's/,/ /g'); do xe snapshot-revert uuid=$vms;done
--------------stop-----------------
Oh, und wie immer ist Linux pingelig, was die Gross-/Kleinschreibung angeht…
Have fun!

23. Oktober 2013

Der Fall der versteckten Apps

Ist PowerShell ein Fall für Sherlock Holmes? oder doch eher für Dr. Watson? (falls das Tool überhaupt noch jemand kennt: http://support.microsoft.com/kb/308538/en-us)

Ok, langsam. Im Rahmen eines PowerShell Kurses, den ich für XenApp-Administratoren gegeben habe, fiel mir auf, dass das Commandlet “New-XAApplication” die Angabe eines Ordners ermöglicht, mit dem sich die Anwendung unterhalb von Applications in weitere Ordner einsortieren lässt. Was aber, wenn man sich nicht an die Spielregeln hält und statt “Applications” einen anderen Ordner der Konsole angibt?

Jeder “Root”-Folder kann mit “Get-XAFolder” abgefragt werden – typischerweise gibt es davon drei:

  • Applications
  • Servers
  • WorkerGroups

Und alle drei sind passende Ziele für den New-XAApplication Befehl, *aber* die Delivery Services Console / das AppCenter stellt Anwendungen, die dort abgelegt sind, einfach nicht dar.

Der Beweis? Das folgende Kommando erstellt eine Published App aus der cmd.exe für die Domänen Admins der Demo-Domäne:

New-XAApplication -ApplicationType serverinstalled -DisplayName SecretShell -CommandLineExecutable C:\windows\system32\cmd.exe -ServerNames XA01 -Accounts "demo\domain admins" -FolderPath servers

Das Ergebnis zeigt, dass im AppCenter die neue Anwendung nicht gelistet wurde, wohl aber im WebInterface – dort ist sie auch startbar wie jede andere Anwendung auch.

image  image

Das Geheimnis dahinter kennt nun lediglich PowerShell:

image

Ein paar Anwendungsfälle dafür kann ich mir durchaus vorstellen ;-)

 

Have fun!