by Tim Mangan, CTP Fellow, Boston CUGC Leader
ABOUT THE SERIES:
The Field Book on Citrix with App-V is a collection of experiences in customer implementations. This article helps to understand an issue seen on 7.9 with shortcuts in App-V on XenApp.
Use search term FieldBook to search for more from the series.
An on-going set of experiences in helping customers implement App-V in Citrix environments.
The customer is using XenApp 7.9 with App-V direct integration. Users will be using Published Application access only from StoreFront and not the full desktop. They are producing and publishing their first packages. The first half-dozen go well.
The customer then reports that with some new packages they are testing, when they try to launch an app from a package it tries to uninstall the app instead, which is another package shortcut in the App-V package that they don’t even publish via Studio.
XenApp 7.9 with App-V 5.1 Hotfix 6.
After troubleshooting, it is determined that this is a problem with App-V Packages containing multiple publishable applications. It does not matter how many apps of the package that you publish via Studio; instead it seems that the process of StoreFront launching through the CtxAppLauncher application is picking the first application inside the package.
Citrix integrations appear to use the internal AppXManifest file. In the file are the multiple shortcuts, and multiple applications (AppIDs), and we found that it appeared that the fist AppID in the file was being selected. Although we attempted manual manipulation on the order by editing the internal AppXManifest file, the sequencer ensures that the entries are kept ordered in this file in alphabetical order by application path when it saves the App-V package file.
A ticket is opened by the customer with Citrix. For this package, we were able to repackage by eliminating the uninstaller from the package while in monitoring mode. This solves the issue for this package, but a fix will be required for other more complex packages.
I have not checked back with the customer on the status of the ticket, however I tested the same situation on a 7.12 test-lab setup. I could not reproduce the issue there, so it is likely that Citrix fixed it at some point.