SeeTricks - Gedanken, Links, Tools und Skripte rund um Citrix Produkte

Was soll da schon passieren? Das denken sich wohl viele Admins, wenn es an die Frage geht, ob der XML Port des Delivery Controllers (oder ggf. Cloud Connectors) TLS verschlüsselt werden sollte. Immerhin hat man doch schon den Zugriff auf NetScaler und StoreFront durchgängig mit Zertifikaten gesichert... Ein Restrisiko bleibt, denn immerhin gehen zwar per default keine Benutzernamen und Passwörter im Klartext über diesen Port, doch die Kommunikation zwischen StoreFront und den Delivery Controllers bzw. Cloud Connectors beinhaltet den Sessionkey für jede ausgehandelte Sitzung. Und wenn es einem Angreifer gelingt die Obfuskation der Daten (Richtig gelesen, Citrix verschlüsselt hier nicht, sondern lässt die Daten lediglich in anderen Daten "verstecken". Etwa so, wie seine Pin als Telefonnummer getarnt auf die Kreditkarte zu schreiben...mag reichen, oder eben nicht) zu verstehen (fertige Plugins sind im Netz erhältlich), dann könnte dieser Angreifer mit dem Sessionkey eine best

Wer hat nicht schon mal einen einzelnen XenServer zum Ausprobieren auf ausrangierter Hardware installiert? Selbst in der Gratis-Edition ("free" lt. Citrix) unterstützt der XenServer Funktionen, die bei anderen Hypervisor-Varianten entweder Geld kosten oder den Einsatz (sprich: Einkauf) zusätzlicher Software erfordern. Wenn man nun bloss einen einzelnen Server betreibt, und ISO Dateien bereitstellen muss, um VMs davon zu installieren, bleiben folgende Möglichkeiten: Einrichten einer Freigabe auf dem PC, mit dem man den XenServer steuert. Dies ist üblicherweise der Rechner, auf dem XenCenter installiert ist. Dabei richtet man vom XenServer aus einen Zugriff auf ein freigegebenes Verzeichnis des Notebooks / der Workstation ein. Vorteil: keine langen Kopieraktionen, keine Synchronisation für neue ISOs Nachteil: wenn Notebook / Workstation nicht verfügbar sind, ist das Storage Repository mit den ISOs auf dem XenServer unbrauchbar. Erfordert zwischen XenServer und Workstatio

Da wechselt man mal eben den Arbeitgeber (nicht den Job, ich gebe immer noch Trainings, mache Consulting und Support) und schon sind 1030 Tage vorbei. Ein unhaltbarer Zustand, deshalb habe ich heute beschlossen, das Schreiben hier wieder aufzunehmen, woanders war ich durchaus fleißiger, jüngst sogar auf den offiziellen Citrix Blogs: https://www.citrix.com/blogs/2017/09/28/5-reasons-to-prepare-for-the-next-5-years/ Wer auf der Suche nach ein paar guten Gründen ist, mal wieder ein Citrix Training zu besuchen, der findet im obigen Artikel meine ganz persönliche Meinung dazu. Mit der aktuellen Taktung der neuen Citrix XenApp und XenDesktop Versionen sollten die Admins ja auch Schritt halten können. Alles, was man erstmal für ein gesundes Miteinander über XA/XD 7.15 wissen muss, kann man im Citrix Training CXD-210-3i ab Oktober lernen, bei Arrow sowohl remote von zu Hause aus, als auch vor Ort an unseren Niederlassungen im Schulungsraum. Mich als Trainer oder einen meiner Kollegen bei

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 Beschreib

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://<ip

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: 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 so