NWC Services Blog

Beim Einsatz von Flex+ als Profilmanagement-Lösung werden oft sämtliche Links benutzerbezogen über Flex+ angelegt. Der Sinn dieses Vorgehens liegt auf der Hand: Links können aufgrund von Conditions (z.B. Gruppenmitgliedschaften) erzeugt werden, durch die asynchrone Abarbeitung verzögert sich nicht der Login Prozess, der DSM AutoInstaller Prozess wird "entschlackt". 

Allerdings kommt dabei ein Problem auf: Wird der Maschinenteil einer Anwendung via DSM installiert, hat der User seine Links erst zur Verfügung, wenn dieser sich ab- und wieder neu anmeldet, kurzum: die FlexEngine neu startet. Speziell beim Deployment einer Anwendung über den AutoInstaller ist die User-Experience daher eher "mau". 

SSON an einer Webite (Receiver for Web) funktioniert nicht mehr. Sobald man SSON als einzige Authentifizierungsmethode aktiviert, meldet Storefront "kein Zugriff möglich". Demnach widmet sich dieser Artikel ausschließlich SSON in Verbindung mit einer Service Site (Store).

Single Sign-On bedeutet die automatische Nutzung der lokalen Domain-Anmeldedaten für eine Citrix Sitzung. Wichtig ist der Hinweis, dass dies nicht zu verwechseln ist mit dem gleichnamigen Citrix Produkt, das ehemals als "PasswordManager" bezeichnet wurde und für das mittlerweile ebenfalls die Bezeichnung "Single Sign-on" benutzt wird.

Seit DSM 7.2.1 gibt es ja neben dem normalen Patch Management, das im Wesentlichen die Funktionalität bietet, die die Windows Server Update Services (besser bekannt als WSUS) auch bereitstellen, die erweiterte Variante des Avanced Patch Managements (APM).

Hauptmerkmal des APM ist, dass neben den üblichen Microsoft Produkten, die auch durch den WSUS mit Patches versorgt werden würden, eine große Anzahl von Dritthersteller-Produkten gepatcht werden kann. Fragt man jedoch, welche Produkte (oder zumindest wieviele) denn sonst noch mit Patchen versorgt werden können, erhält man oft ungenaue oder zum Teil sogar sich widersprechende Aussagen.

Da es sich beim APM um eine OEM-Version des Produkts "Shavlik Protect" handelt, kann man auf die Angaben des Herstellers zurückgreifen – sofern man diese findet...

Bei XenDesktop 4 und Metaframe XP SP2 FR1 bis XenApp 6.5 gab es außerhalb der Citrix Richtlinien die Möglichkeit, den XML Port mit dem Befehl ctxxmlss /R<port> zu wechseln. Überprüfen konnte man dies in der Registry unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\CtxHttp.

Diesen Befehl gibt es bei XenDesktop 5.x und XenDesktop 7.x nicht mehr, aber nach wie vor die Möglichkeit dies einzustellen und zu überprüfen.

Seit einiger Zeit bietet DSM die Möglichkeit, die Overall-Compliance sowie die Compliance von Patchen, Software und Treiber jeweils einzeln auszuwerten. Zu diesem Zweck bietet DSM eine Liste von Zahlenwerten in den jeweiligen Computer Eigenschaften, von denen 7 Werte als "Partly Compliance" gekennzeichnet sind. Hinter diesen Werten steckt folgende Aufschlüsselung: 

0 - Undefined
1 - Compliant
2 - NotCompliant
3 - Pending
4 - 12.5
5 - 25
6 - 37.5
7 - 50
8 - 62.5
9 - 75
10 -87.5

Windows 8.1 bringt den Typ 1 Hypervisor „Hyper-V“ als Feature mit, welches sich nachträglich über die Systemsteuerung aktivieren lässt. Nach ersten Tests bin ich von der Performance durchaus angetan. Allerdings bringt Hyper-V ein paar kleine Stolpersteine mit, die es so z.B. unter VMware Workstation oder VirtualBox nicht gibt. Wenn als Gast zum Beispiel Windows Server 2008 R2 eingesetzt wird, bietet Hyper-V nur eine 4:3 Auflösung. Das macht auf einem 16:10 Notebook nicht wirklich Spaß. Zum anderen fehlt auch der Dateiaustausch zwischen Host und Gast über die Zwischenablage. Mit einem Server 2012 R2 oder Windows 8.1 als Gast hat man diese Probleme nicht.

Um ordentlich mit einem Server 2008 R2 arbeiten zu können und die bereits genannten Probleme zu eliminieren, kann man sich auf den Gast auch per RDP verbinden. Dies setzt allerdings mehrere Konfigurationsänderungen voraus, damit das auch wirklich funktioniert.

Immer wieder werden im Projekt heftige Dikussion um die CPU Bestückung des BLS geführt. Bei einem Blick in den Taskmanager zeigt dieser auf dem BLS oft nur eine Auslastung unter 50% an, was zu der Annahme verleitet, dass keine weiteren CPUs für den BLS mehr notwendig sind. Allerdings ist die Aussage des Taskmanager völlig unbrauchbar, das nicht die aktuelle Auslastung der CPU, sondern die Warteschlange vor der CPU den entscheidenen Messwert darstellt.

Rund um das Thema "Umzug des ORG-Master Depots" gibt es jede Menge Unsicherheit, Gerüchte und fast schon moderne Märchen. Ganz früher (zu NetInstall 5.0-Zeiten) war dafür zwingend der sogenannte RAW-Modus erforderlich, der aber weder supported noch offiziell dokumentiert war.

Um ein supportbares Szenario zu schaffen, wurde mit der Version NetInstall 5.54 der Schalter "/AllowSrvMove" geschaffen, mit dem der NetInstall-Manager gestartet werden musste. In solch einer Sitzung konnte dann der ORG-Master durch Auswahl des Kontextmenü-Befehls "Umbenennen" oder durch Drücken von F2 umbenannt werden.

Wie mein Kollege David König in einem – mittlerweile veralteten und daher von ihm offline-genommenen – Artikel beschrieben hatte, gab es auch vor einiger Zeit mal eine DSM-Version, wo die alleinige Verwendung des "/AllowSrvMove"-Parameters nicht (mehr) ausreichend war. Beim Versuch eine so modifizierte NCP-Datei abzuspeichern kam es zu einer Fehlermeldung und so musste damals eine Kombination aus RAW-Mode und Schalter verwenden werden.

Mittlerweile (zum Zeitpunkt der Erstellung dieses Artikels ist die DSM-Version 7.2.1.2123 aktuell) wurden  diesbezüglich erneut Änderungen vorgenommen...

Beim Aufbau einer DSM Umgebung gibt es Computer-Eigenschaften, die grundsätzlich immer wieder implementiert werden. Eine Übersicht der folgenden Eigenschaften, die in jeder Umgebung Sinn machen, sollen folgende vorgestellt werden. Es handelt sich hier um Best-Practices die sich im Laufe der Jahre herauskristallisiert haben.