Citrix XenDesktop 7.8 und App-V

Mit XenApp 7.8 hat Citrix die App-V Unterstützung erweitert und verbessert. In unserem Blog-Artikel „XenDesktop 7 und App-V“ (http://www.software-virtualisierung.de/entry/xendesktop-7-und-app-v.html) ist beschrieben, wie eine Veröffentlichung mit Citrix XenDesktop und einem Microsoft App-V Publishing- bzw. Veröffentlichungsserver erfolgt. In diesem Artikel wird beschrieben, welche Möglichkeiten zur App-V Paketbereitstellung es zusätzlich mit XenDesktop 7.8 gibt. Das neue Verfahren erinnert dabei stark an die Möglichkeit zur Bereitstellung von Citrix Applikation Streaming Paketen (bzw. jetzt XenApp Streaming). Die Pakete wurden bis XenApp 6.5 dafür in einem Fileshare abgelegt (wer noch Citrix Applikation Streaming Pakete hat, bitte melden - wir können diese mit unserem AppBot version 2.0 konvertieren). Genauso ein Verfahren ist nun mit XenDesktop 7.8 und für App-V Pakete möglich. Schon mit einem einfachen Powershell-Skript kann ein Paket ohne eine umfangreiche Infrastruktur veröffentlicht werden:

$app = Add-AppvClientPackage

Prublish-AppVClientPackage $app

In der Vergangenheit wurde genau aus diesem Grund Tools wie App-V Sheduler zur Integration von Paketen genutzt. Jetzt haben wir eine ähnliche Funktion im XenDesktop Studio integriert. 

Hier zunächst den großteil des Artikels auch als Video. Das Troubleshooting am Ende des Artikels ist im Video nicht enthalten: 

Unter Configuration/App-V Publishing findet sich nun neben der Funktion „Add Microsoft Server“ mit der ein Publishing Server für die Umgebung angegeben werden kann, nun die Funktion „Add Package“.

Als Nachteil dieser Art der Bereitstellung ist zu nennen:

• Keine Verbindungsgruppen
• Keine Bearbeitung der Dateiverknüpfungen
• Fehlendes Icon Management
• Keine Skriptintegration, keine benutzergebundenen Konfigurationsdateien

Alle benötigten Funktionen müssen im „.appv“ Paket enthalten sein, also zuvor mit dem Sequencer im Paket festgelegt werden. Mit einer Skriptintegration wird das schwer. Wir planen eine neue Version des v-Injectors, die auch Skripte im Paket editieren kann und eine vereinfachte Möglichkeit bietet, Dateierweiterungen und Verknüpfungen direkt im Paket zu bearbeiten. Damit frühestens Anfang 2017 zu rechnen.

Nach der Anwahl der Funktion Add-Package kann in einem Fileshare ein App-V Paket in einem Fileshare angegeben werden.

Auf diesen Share greift bei der Bereitstellung über einen VDA wiederum ein Systemdienst zu. Daher für den Zugriff auf diesen Share am besten „Jeder:Lesen“ als Berechtigung vergeben.

Die NTFS Berechtigung für den Share anschließend auf „Netzwerkdienst:Lesen“ und dort „Jeder“ herausnehmen. Im Dialog ist die Anwendung zu erkennen.

Für die Delivery Group kann nun auch diese Anwendung ohne eine App-V Infrastruktur bereitgestellt werden:

Über die Funktion „Properties“ wird die Sichtbarkeit auf bestimmte Benutzergruppen eingeschränkt:

Interessant ist auch der Punkt „Location“. Jeder Start einer App-V Anwendung erfolgt über das Tool CtxAppVLauncher.exe. Hier könnte ein Unternehmen eine eigene Befehlszeile oder ein eigenes Bereitstellungstool nutzen. CtxAppVLauncher.exe bekommt „nur“ die PackageID und nicht die VersionsID. Es wird automatisch die neueste Version eines Paketes gestartet.

Der Bereitstellungsgruppe ist nun die Anwendung zugeordnet.

Das Bereitstellungstool CtxAppvLauncher kopiert dabei die „.appv“ Dateien nach c:\windows\temp\CtxAppvPkgCache.

Der Start mit dem CtxAppVLauncher.exe sieht anschließend so aus:

Leider gibt es mit dem CtxAppVLauncher immer mal wieder Probleme. Manche Anwendungen starten einfach nicht. Auch nicht beim Einsatz eines Publishing Servers. Man kann recht leicht das Logging aktivieren. Alle Pakete werden hierbei auch Problemlos mit dem App-V Publishing Server bereitgestellt!

Troubleshooting:

http://docs.citrix.com/en-us/xenapp-and-xendesktop/7-6/xad-build-new-enviroment/xad-app-v.html

Einen Ordner: C:\CtxAppVLogs erstellen Die Datei C:\Program Files\Citrix\Virtual Desktop Agent\CtxAppVCommon.dll.config wie folgt anpassen:

  Die Logs die, benötigt werden, finden sich nach dem Start der Anwendung nicht etwa unter c:\CtxAppVLogs\, sondern unter %localappdata%\Citrix\CtxAppVLogs.

Hier gibt es den Hinweise, dass das Manifest nicht korrekt „geparst“ (Syntaxcheck) werden konnte und die AppID nicht gefunden wurde. Über die AppID erfolgt die Zuordnung zum Start. Ich vermute einen Bug im CtxAppVLauncher.exe. Zumal das Problem auch immer mal mit dem Publishing-Server aufgetreten ist.

5/14/2016 11:50:59 AM CtxAppVCommon:  XmlParser::XmlParser - Exception occurred in the constructor.System.ArgumentException: Invalid Deployment Config XML
   at Citrix.VirtApp.Studio.PowerShellManager.XmlParser..ctor(Stream inStream, AppVXmlType xmlType)
5/14/2016 11:50:59 AM CtxAppVCommon:  PkgDeploymentConfig::PkgDeploymentConfig - Argument  Exception occurred in constructor.System.ArgumentException: Invalid Deployment Config XML
   at Citrix.VirtApp.Studio.PowerShellManager.XmlParser..ctor(Stream inStream, AppVXmlType xmlType)
   at Citrix.VirtApp.Studio.PowerShellManager.PkgDeploymentConfig..ctor(Stream stream)
5/14/2016 11:50:59 AM CtxAppVCommon:  Entry: PkgManifest:: PkgManifest
5/14/2016 11:50:59 AM CtxAppVCommon:  Entry: XmlParser::XmlParser
5/14/2016 11:50:59 AM CtxAppVCommon:  XmlParser::XmlParser - parsing appxmanifest file
5/14/2016 11:50:59 AM CtxAppVCommon:  Exit: XmlParser::XmlParser
5/14/2016 11:50:59 AM CtxAppVCommon:  Exit: PkgManifest::PkgManifest
5/14/2016 11:50:59 AM CtxAppVCommon:  Entry: PkgManifest::GetCmdLineArgs 
5/14/2016 11:50:59 AM CtxAppVCommon:  PkgManifest::GetCmdLineArgs - Argument Null Exception occurred in GetCmdLineArgs.
5/14/2016 11:50:59 AM CtxAppVLauncher:  ConvertToArrayCmdLineASD: Exception while parsing arguments: System.ArgumentNullException: appId cannot be null
Parameter name: appId
   at Citrix.VirtApp.Studio.PowerShellManager.PkgManifest.GetCmdLineArgs(String appId)
   at Citrix.VirtApp.Vda.Launcher.VirtAppLauncher.GetCmdLineArgs()
   at Citrix.VirtApp.Vda.Launcher.VirtAppLauncher.ConvertToArrayCmdLineASD(BackgroundWorker worker)
5/14/2016 11:50:59 AM CtxAppVLauncher:  FUNCTION: BackGroundWorkerThread MESSAGE: System.ArgumentNullException: appId cannot be null
Parameter name: appId
   at Citrix.VirtApp.Vda.Launcher.VirtAppLauncher.BackGroundWorkerThread(Object sender, DoWorkEventArgs e)
5/14/2016 11:50:59 AM CtxAppVLauncher:  FUNCTION: BackGroundWorkerThread MESSAGE:Background thread encountered an exception  System.ArgumentNullException: appId cannot be null
Parameter name: appId
   at Citrix.VirtApp.Vda.Launcher.VirtAppLauncher.BackGroundWorkerThread(Object sender, DoWorkEventArgs e)

In einem weiteren Test haben wir das Paket noch einmal mit dem Application Virtualization Explorer von Gridmetric geöffnet und gespeichert. Das Tool hat für mich immer eine Hundertprozentige Zuverlässigkeit gehabt. Leider mochte Citrix das Paket anschließend nicht einmal mehr einbinden. Weitere Pakete haben sich genau so verhalten.

Vielleicht hat jemand eine Idee dazu? Ich vermute einen Bug im XML Parser für das AppvManifest. Hier noch ein Echter Deep Dive für die Citrix XenDesktop App-V Integration: Citrix App-V Integration: Internals:

https://www.citrix.com/blogs/2013/12/23/citrix-app-v-integration-internals/