Valid for : XD 7.0 & 7.1

Prologue:

Starting from XenDesktop 7.0, Citrix provides App-V application support as a first class citizen in Citrix XD deployments. This blog talks about the internals of Citrix App-V integration in detail and tries to uncover the mechanics that happens behind the scenes. The description will take into account very generic cases of publishing App-V applications at Studio and will try to highlight the technicalities (visible and invisible) from App publishing to App Launch on Citrix VDAs. Throughout the expanse of this blog, the following keywords will hold true for your quick understanding:

Mgmt. Server             : The App-V Management Server, part of MS App-V Server Setup 5.0 or higher.

Pub. Server                :  The App-V Publishing Server, part of MS App-V Server Setup 5.0 or higher.

App-V Infrastructure  : The combination of App-V Management, Publishing and Database servers that are used by MS to publish App-V applications.

App-V Client              : The App-V Client (RDS & VDI), part of MS App-V Client Setup 5.0 or higher.

Studio                        : The Citrix Desktop Studio part of XD 7.0 and higher.

VDA                            : The Citrix Virtual Delivery Agents – machines rendered for Desktops and Apps usage to end clients.

Receiver                    : The Citrix Receiver – end client application to access Desktops and Apps (managed by Citrix infrastructure) remotely.

Launcher.exe            : A Citrix executable (actually titled as “CtxAppVLauncher.exe”), part of Citrix VDA installation that guides through App-V application launch.

1. Studio/DDC:

 At the Site Configuration:

Post Studio/DDC installation, during the Site configuration stage Admininstrator specifies the details of Mgmt. and Pub. Server . The App-V configuration node UI allows only 1 pair, but additional Powershell cmdlets allow the configuration to add up to 5 such pairs. A test connection button ensures the health of these servers and responds back with the verification results. Once tested, the Administrator is presented an option to save the same. One could refer to this step as configuration of  App-V Servers in Studio.

 Behind the scenes:

When saved, the contents (Server Pair) are recorded in the XD Broker database in a structure termed as “blob”. This App-V blob data is automatically associated with every forthcoming Delivery Group that would have at least 1 App-V application.

 At the App-Publishing wizard:

Typically, an Administrator would now go ahead to create VDA Master images with pre-installed App-V Client 5.0 or higher and form machine catalogues of the same. Further he would proceed to create a Delivery Group (Application / Desktop&Application Delivery Group) and associate catalogues with it. At this juncture, there is the entire infrastructure that is required to publish App-V applications at Studio.

 Behind the scenes (1/2):

When Administrator chooses to Discover Applications, Studio uses the Citrix Low Level SDKs to import App-V application information from App-V Servers and packages published therein. This information comprises of Application Name, AppId, Package GUID, Version GUID, FTAs and Icons and represented at the Studio UI. When selected and published at Studio, the same are saved as Application records in the XD Broker database. However the actual published application for any App-V app is actually replaced with a Citrix executable say “Launcher.exe”. This executable stores certain App-V application specific parameters such as AppID & Publishing Serverin a hashed format (SHA-256 Hash encryption), and Pkg_GUID & Application Display Name as it is, as part of its commandline arguments.

Any launch request to App-V application would actually invoke this Launcher executable on the VDA machines, with the intended App-V application’s parameters.
 Behind the scenes (2/2):

A delivery group is a combination of Machines and Users. The App-V blob is associated with any delivery group that has at least 1 app-v application published in it. When I refer to association, the simple inference is that the blob policy will be applied to all VDAs that are part of any such Delivery Groups. To achieve this, the communication protocol of Citrix ensures that the blob data stored in the Broker database is percolated down to all such VDA machines. This happens whenever the BrokerAgent (on VDA machines) registers itself with the Broker and during any App-V configuration node change happens.

2. VDA

 At App-Launch:
An end-user when invokes an App-V Application from Receiver triggers the following set of events. The receiver sends a request to Broker for launching the particular App-V application. The broker issues a command to invoke the “Launcher.exe” with the appropriate App-V application parameters.

 Behind the scenes:
By this time the BrokerAgent has successfully registered with the Broker, allowing the Blob data (containing the Server pair) to be pushed onto the VDAs registry. A Citrix plugin (part of VDA, which loads into BrokerAgent service) monitors any changes in this registry (blob data) and fires up an event when it detects any modification. This invokes another Citrix component that runs in the privileged ADMINISTRATORcontext and adds the publishing server (received in the blob) on the VDA machines.[MS mandates that this operation can only be executed in an administrator context and hence the Citrix component always runs in the privileged mode.] The service startup, registration with broker, blob percolation and publishing server configuration happen almost instantaneously on the VDA, in the mentioned order.

 At the foreground:

Launcher.exe is invoked at the VDA along with the App-V application parameters. These include Hash of Pub Server, Hash of AppID, Pkg_GUID, inTarget(Boolean) and App Name.

It is possible that there are more than 1 servers added during the site configuration (1 using UI, and the rest using Powershell cmdlets). This essentially means that the App-V blob contains all such configured servers, and the privileged Citrix component would have added all of them (max 5) using App-V client cmdlets.

Launcher has a few tasks to accomplish before it makes the App-V application launchable. It starts with trying to hash each of these publishing servers from the Registry and compares the encrypted hash against the one it receives as parameters. The match confirms the unique publishing server (say Pub1) that hosts app-v packages. Launcher issues an App-V sync request using App-V client cmdlets that sync down all the packages published at Pub1.

Further, Launcher attempts to find the exact package using the Pkg_GUID parameter as an input to another app-v client cmdlet. This also returns an App-V package property called Version _GUID. Having found the package being looked for, it opens up one of the constituent files in it titled “AppxManifest.xml” that hosts all the AppIDs. Application IDs (or AppIDs) as one would refer to, are aliases to relative executable path of an application within a package. As one would obviously guess, launcher matches the given Hash with the hash of AppIDs available and determines the unique AppID of the exact app-v application in package that needs to be launched  (say AppID1).

A sample AppID looks like   – [{AppVPackageRoot}]\Notepad++\notepad++.exe

A resolved AppID looks like – \Root\Notepad++\notepad++.exe

PS: The folders referred by the Resolved AppID as in “…\Root” or “…\Root\VFS” are directory components of any App-V package and their presence depends on the way app-v sequences were created in the first place.

The next step for Launcher is to determine the App-V application arguments to be used for the actual app launch. Launcher retrieves this information from the data provided by App-V Management Server. [App-V applications when published at App-V Mgmt. Server can be provided any commandline arguments to be used by default, and the same are stored in the package. Soon after the package sync, Launcher extracts this vital information from the same.] Coming back to the proceedings, let’s call these arguments “Args1”.

At this juncture Launcher has all the necessary information handy at the VDA machine to launch an app-v application. It has ensured that the package sync tasks required from the App-V client side have been accomplished and all packages are downloaded as well as published for the launching user, ready to use. Thus Launcher creates the full path to the App-V executable which looks like <“App-V Cache” + “Pkg_GUID” + “Version_GUID” + “Resolved AppID”>  . Launcher adds the “Args1” as the argument to this app-v application, invokes it and dies off.

In case the InTarget (Boolean) is set to FALSE, Launcher acknowledges that the request is to launch an application outside the App-V package. The resolved AppID in such a case points to the full path of the locally available application. Launcher invokes the same and dies off.

That’s it!! That is all what happens behind the scenes. Post any comments or queries here. We’ll be glad to hear from you.

3. FAQs

 1. Do Administrators need to add the Publishing Server on every VDA using the App-V cmdlet “Add-AppVPublishingServer”?

No. This task is explicitly carried out by the combination of Citrix communication protocol and a Citrix component present at the VDA. The communication protocol sends down the to-be-added Publishing Server to the VDA. This is used by the privileged Citrix component which performs this task successfully. In fact, administrators can choose to verify this by executing an App-V Powershell cmdlet “Get-AppVPublishingServer” which would return the successfully added Publishing Server. (Given that this VDA is part of a Delivery Group that has at least 1 App-V application).

 

 2. I happen to notice a small progress window that says “Starting Microsoft Word…” or “Starting Microsoft Excel…” isn’t my actual app-v application?

True. When a user invokes an app-v application from the receiver, the UI window that comes up is actually the Launcher.exe, and it is supposed to perform certain tasks before being able to launch the exact app-v application. Launcher.exe invokes the actual App-V application soon before it dies.

 

 3. I have an App-V 5.0 or higher client installed with Receiver at my device. The App-V application runs as a hosted app and not as a local app-v application. Why is the local App-V client not useful in launching the application?

True. With XD 7.0 or 7.1, Citrix supports the availability of App-V applications as hosted applications. This means that the App-V application would be launched on Citrix managed VDAs and the Citrix ICA protocol will ensure to remote the GUI of application as an online application. We currently don’t support an Offline access of App-V applications meaning no packages are synced down to the absolute end-client machine with Citrix Receiver and MS App-V Client, thereby keeping local App-V client unused.

4. Why are some parameters hashed, while others not?

The app-launch request from a Broker to a VDA is a remote call to an executable on the VDA. Some of the constituent parameters say “Publishing Server” or “AppIDs” may extend up to very long paths. Hashing of these parameters ensures that we send absolutely minimal data using the Citrix communication protocol, exactly within allowed limits. This is to overcome the current limitation of MS Terminal Services applications that are restricted to 260 characters. Refer this KB for exact cause of this behaviour.

5. There are certain App-V client configuration settings like SCSM and Publishing Server specific settings with respect to LogOnRefresh. How can an administrator configure these?

Any App-V client configuration settings like SCSM, App-V Cache path etc. need to be configured by the Administrator, at the time of preparing the Master Image. Generally we recommend Administrators, to install the App-V Client on their Master Images before installing XenDesktop VDA on it.

All Publishing Server specific settings, are configurable either using GPO or using the Citrix Low Level SDK cmdlets. Although GPO wins over, in case both these mechanisms are used to configure publishing server settings. Citrix recommends using this SDK for configuring publishing server settings.

6. I’ve created a Delivery Group of the type “Desktops”. Is there a way I can access any App-V applications from the desktop session, just like how I access local applications installed on the VDA of this Desktop Delivery Group?

Incidentally yes. We know that an administrator can’t publish apps (master image/App-V) in a Desktop only Delivery Group. The key ingredient for being able to use App-V apps on such Desktops, is to have the App-V client point to the correct App-V Publishing Server. (Because once this is done, an App-V client uses a pub. server setting known as “UserLogOnRefresh” and as its name suggests, syncs down the App-V publishing server, thus caching App-V packages on VDA at every log on.)

So, soon after the site configuration step in XD Studio, follow these steps to manually associate the App-V blob to the Desktop Only Delivery Group. That’s it!! The Citrix VDA components will take over from here, and perform the magic of configuring App-V servers on the VDA. The App-V client will take over from there and sync down the packages published at the publishing server that was pointed to. By the end of logon, a user will have the App-V applications ready to use on VDAs.

7. This all looks good. But how do I troubleshoot or log any issues, if I face an error at Studio or VDA?

Follow the steps mentioned at Citrix e-docs content here.

8. Are there any other links I can refer to, for publishing App-V applications at Studio and launching them using Receiver?

Yes. Follow the blog post at /blogs/2013/06/28/microsoft-app-v-support-in-xendesktop-7/.