How-To-Compute

IT-Pro Blog: Anleitungen, Tipps und Tricks um euch das Leben leichter zu machen.

Startmenü mit XenApp 7 Session Sharing Lösung

Jeder von euch, wer bis einschließlich XenApp 6.5 das Online Plugin im published Desktop betrieben hat, um dem Benutzer die für ihn bestimmten Anwendungen ins Startmenü oder auf den Desktop zu bekommen weiß, dass dies mit XenApp 7 derzeit nicht geht. Jedenfalls nicht so wie es früher war, nämlich per Session Sharing. Citrix hat dazu einen Workaround in den Receiver programmiert, nämlich das “prefer” Keyword. Wir haben dazu auch schon zwei Artikel gepostet, wie ihr damit richtig umgehen könnt. prefer Keyword erklärt und prefer einfacher

Gerade der letzte Link ist interessant. Ihr legt das “PreferTemplateDirectory” auf den XenApp Servern auf “C:\ProgramData\Microsoft\Windows\Start Menu\Programs” fest. Damit erspart ihr euch, ein zentrales Verzeichnis anzulegen und die Verknüpfungen da hin zu kopieren. Zudem könnt ihr im Citrix Studio den Namen der Verknüpfung beim Original belassen. Beispielsweise die Verknüpfung “Internet Explorer”, kann dann im Studio mit dem prefer Keyword wie folgt veröffentlicht werden: “KEYWORDS:prefer=”Internet Explorer”.

Nun haben wir aber ein ganz anderes Problem, wenn ihr nämlich Published Desktop und Published App Umgebungen mischt. Bedeutet, wenn ihr einigen Benutzern mit vollwertigen Windows Rechnern bestimmte Anwendungen per published App bereitstellen wollt, diese schauen nämlich nun auch in ihren lokalen Startmenüs nach (weil ja das “prefer” Keyword gesetzt ist) und erstellen nun, wenn lokal zum Beispiel der Internet Explorer vorhanden ist, keine neue Verknüpfung. So kann der Benutzer leider per Receiver for Windows keine published Apps starten, die lokal installiert sind.

Hierzu habe ich nun die ultimate Lösung. Ich habe mittels Storefront SDK eine neue “StoreCustomization_Enumeration.dll” erstellt. Dies ist von Citrix so vorgesehen und wird grundsätzlich hier Clientname rewrite beschrieben.

Ihr könnt die dll hier  StoreCustomization_Enumeration_v1 herunterladen.

Folgendes Szenario habe ich nun erfolgreich getestet und kann es so mit der Anpassung empfehlen:

  1. Auf den XenApp Servern erstellt ihr in der Registry den Key “PreferTemplateDirectory” und legt den Pfad auf “C:\ProgramData\Microsoft\Windows\Start Menu\Programs” fest
  2. Ihr erstellt zwei Stores auf eurem Storefront. “ClientStore” und “DesktopStore”. Den “ClientStore” konfiguriert ihr, wie ihr ihn benötigt. Mit Remote Access, einer schönes Receiver Web Gui und und und. Eben so, wie ihr es für eure Clients benötigt.
  3. Den zweiten Store “DesktopStore” erstellt ihr im Prinzip genauso. Dieser Store wird aber für die Receiver genutzt, welche im published Desktop laufen. Wichtig hier, ihr solltet den Store auf “Mandatory Store” umstellen, so dass alle Anwendungen bereitgestellt werden.
  4. Ihr konfiguriert den Receiver, so dass der SelfService Mode deaktiviert wird, damit wird auch im published Desktop keine SelfService Gui vom Receiver bereitgestellt.
  5. Ihr erstellt von der originalen Datei “”C:\inetpub\wwwroot\Citrix\ClientStore\bin\StoreCustomization_Enumeration.dll” eine Sicherheitskopie außerhalb des c:\inetpub Verzeichnisses.
  6. Ihr ersetzt die Datei mit meiner Anpassung.
  7. Ihr prüft im Citrix Studio, dass ihr die Anwendungen mit dem “prefer=” Keyword versehen habt
  8. Fertig!

Was passiert nun? Für alle Clients, die gegen den “ImDesktop” Store verbunden sind, ändert sich nichts. Sie erhalten ihre “nativen” Verknüpfungen aus dem Common Startmenü in ihr persönliches Profil kopiert (%appData%\Microsoft\Windows\Start Menu) und können die Anwendungen starten, ohne dass eine neue Citrix Sitzung gestartet wird. Quasi Session Sharing. Für Anwendungen, wo keine Verknüpfung im Common Startmenü liegt, wird eine “ICA Published App” Verknüpfung erstellt. So können auch Sitzungen zu Silo Servern weiterhin aufgebaut werden.

Und jetzt die Magie: Alle vollwertigen Windows Clients bekommen nun keine nativen Shortcuts mehr, da dass “prefer=” Keyword überschrieben wird. Es werden also nur noch published App Verknüpfungen erstellt.

 

Bitte testet die Anpassung und gebt mir Feedback. Ich werde noch die ein oder anderen Erweiterungen einbauen und dann hier veröffentlichen. Wenn ihr Ideen habt, wie gefiltert werden soll, dann gebt mir bitte Feedback.

9 Comments

Add a Comment
  1. Hi,

    danke für den tollen Artikel, klasse Idee.
    Im Prinzip kann man in der GPO für die “vollwertigen Windows Clients” den “PreferTemplateDirectory”-Key einfach weglassen. Dann erstellt der Receiver ebenso keine “nativen Shortcuts”. Verzögerungen sind nicht festzustellen.

    Viele Grüße

    1. Stefan Wendrich

      Danke für deinen Kommentar, das ist richtig, aber auch keine published App Shortcuts. Damit können die Benutzer mit den vollwertigen Windows Rechner keine published Apps nutzen, wenn sie die gleiche App installiert haben. Kommt bei meinen Kunden öfter vor.
      Da dient dann meine Anpassung für und schon sind alle zufrieden;)

  2. Hi,

    Für welche Storefront-Version ist die DLL gedacht?
    Und diese Vorgehensweise müsste dann auch auf XenApp 6.5 funktionieren, wenn ein aktueller Receiver (z.B 4.5 oder 4.7) und Storefront installiert sind, richtig?
    Soweit ich das hier verstanden habe, ist das ja ein reines Problem vom Storefront in erster Linie.

    Gruß

    Ewald

    1. Stefan Wendrich

      Hi,
      Für alle storefront 3.x Versionen ist die Dll.
      Das Problem mit dem fehlenden SessionSharing kommt nicht vom Storefront, sondern von XenApp FMA Architektur.

      Ich habe es noch nicht mit XenApp 6.5 probiert. Aber ich denke es sollte da genauso funktionieren.

      Allerdings würde ich glaub ich auf dem XenApp Server den Receiver for Windows Enterprise verwenden. Da geht es dann nach wie vor ohne Probleme.

  3. Hallo Stefan,

    funktioniert leider nicht unter XD7.6 LTSR CU2 und Storefront 3.0.

    sG
    Florian

    1. Stefan Wendrich

      Hallo Florian,

      bekommst du irgendeine Fehlermeldung ? Das sdk ist von Storefront 3.0 – 3.11 gültig, daher sollte die Anpassung auch bei dir laufen.

  4. Hallo Stefan,

    sorry für die späte Rückmeldung. …deine DLL funktioniert einwandfrei

    Ein Kollege hat es mit dem Visual Studio am Storefront debuggt und herausgefunden dass es an der nicht definierten AggregationGroup Variable in unserer web.config liegt.

    Leider ist diese nicht ohne Grund nicht definiert;(

    sG

  5. Wir werden versuchen eine eigene StoreCustomization_Enumeration.dll zu kompilieren die keine Aggregation Group benötigt.

    1. Stefan Wendrich

      das klingt interessant. Wenn ihr Fragen dazu habt, könnt ihr gerne mich direkt anmailen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

How-To-Compute © 2017 Frontier Theme