I recommend: Never PreDeploy to XenApp Servers; never PreDeploy to XenDesktop clients.  Always PreDeploy to notebooks.

Background: Application Streaming supports server side execution, client side execution and client side execution that can go offline.  These are controlled with publishing; should the application be available for offline or not, and via client side utilities (RadeDeploy) to optionally predeploy the execution content to the execution machine.  Notice that PreDeploy is REQUIRED and automatic for offline, but that Deploy is optional for online.

What does “online” mean?

Online execution means that the streaming client has everything it needs to run the application available via the network.  This means that it can “see” the Web Interface and can “see” the Application Hub.  By contrast, “offline” means that execution can still happen when the Web Interface and Application Hub are not available.

In programmer speak, this is a 2*2 matrix with 4 possible states; one of which is invalid, offline without Deploy.  I argue that Deploy + online, while valid, should not be used if the execution machine is inside the data center.  If the network is “solid”, don’t Deploy.  The corollary, if the machine is “sketchy”, always publish for offline, with automatic deploy.  This would get the number of states down from 3 to 2, which makes programmers happy.

What is Deploy

The guts of the streaming client are unaware of whether execution is server side or client side, online or offline.  The execution engine brings execution content into the RadeCache (\Program files\Citrix\RadeCache) and fetches that execution content from a CAB file on a file server or web server (App Hub).  In the online case, the cab file location is REALLY on a server.  In the offline case, the streaming engine is pointed to the Deploy location on the local machine and does “local streaming”.  I call this streaming from one side of the hard disk to another; it was my idea back at the beginning and I must say that 4 years later, I’m pretty happy with myself.  The caching activities in the streaming service and the kernel mode stuff in the file system driver are completely oblivious to “offline/online” and the streaming happens with the same code path in all cases; happy.

Deploy is implemented by copying the execution content from the Application Hub and placing a copy of the Application Hub contents onto the execution machine; in \program files\citrix\deploy.  Looking back, I wish we had put the RadeCache and Deploy directories one level deeper, but this is where they exist.

How to deploy

There are two ways to deploy.  In the automatic case, the admin publishes an application and, to some users (you), publishes that application as available for offline.  When you refresh applications in PNAgent (plugin for hosted apps), PNAgent gets a list of all of the applications that are available offline.

The administrator has a choice when publishing.  In the Access Management Console, the admin can say that the Pre-Deploy should happen immediately, or they can state that the Deploy should happen on the FIRST use of the application.  I have not yet found a single admin who has gone with the Deploy on application refresh.  Network storms at 8:05am are not how they want to start their day.  This means that applications are not available for offline until the application has been run online, at least once.

Eventually, the user (you) clicks on an icon to run the application.  The application is run as if “online” and in the background, the server side content is xcopied down to the Deploy location on the execution machine.  This automatic action does not occur if execution is on a XenApp server.

The first use of the application continues in “online” configuration and it isn’t until the next fresh launch of applications from that profile that the offline content is used.  Looking back, it would have been better to have completely copied the offline content to the execution machine before ever running the application.  The user feedback could then be … “Copying your offline content, please go get a cup of coffee while I transfer 2GB to your machine”.  Instead, the user is faced with online execution, competing  copying execution content from the file server into the RadeCache AND the streaming system copying the whole CAB file from the file server into the Deploy location and this presents a less than ideal first time experience, if the application is large.  Yes, the offline deploy is done on an “idle thread”, but single user, 2GHz + dual-CPU machines spend lots of time idle, so it competes.  Eventually, you get the execution content local and further streaming from that profile is local to the execution machine AND available for offline.

How to PreDeploy to XenApp server

First, don’t!  Second, you could use RadeDeploy.exe to command the deploy to happen, and if you do, it will occur.  This would normally be done by software management system.  The streaming client running on that server will at runtime look for the deploy content and if it is there, it will use it.

WHY NOT Deploy to servers!

It isn’t about the first execution.  Yes, the first execution will be faster if you are PreDeployed.  The application update though will be SLOWER.  You first deploy.  This happens once.  Later, you will update the application numerous times.  The update in “online” scenario is more efficient than the update in “offline”.  I should note that I really mean that the update is more efficient without PreDeploy.  Online/Offline is not the trigger, the trigger is Deploy/NotDeploy – then again, one shouldn’t deploy without offline, so they really are the same state.

Consider a large application, say 1GB in size.  If you PreDeploy it, you will have everything available for cache fills based on copies across the local disk; efficient.  If instead, you don’t PreDeploy it, some small percentage of the application will be runtime copied into the execution cache.

When it comes time to update the applications MOST of the execution content will be unchanged.  The Streaming Client will “KNOW” what files are the same, and which are different and it will “KNOW” this without a deep look at the files inside the CAB.  In the online case, all of the “same” content can be immediatley promoted from version 1 to version 2 with no network involvement and this happens whether deployed or not.  In the “deployed” case,  the streaming system though needs to bring down EVERYTHING and this is very inefficient.

In Streaming Client 1.1, this resulted in a full copy of the CAB file from the network server to the Deploy location on the client.  Notice that it is a single file (the cab); the client copied the whole thing and this is not friendly to the network and worse, it is very bad if the user is remotely connected over a VPN; where Deploy SHOULD be used.

In Streaming Client 1.2 (XenApp 5.0), the streaming client was enhanced to bring down only the “deltas” from version “old” to version “new”.  This is much more efficient network wise and brings Deploy case on-par with the online case, but it is still less efficient.  Ultimately, the whole cab file is needed for both “old” and “new”.  The streaming system knows what has to exist, but the CAB file format does not allow update in place.  To save network usage, the streaming client trades client side CPU and Disk activity to save network.  This means that the Deploy update consists of a full un-cab of the CAB file, apply the updates, and full re-cab.  For a 1GB application, this can take minutes!  10s of minutes?   What is my machine doing!!  AArgh!

In a XenApp hosted environment, there is no need to pay the un-cab/re-cab penalty; the most efficient update is directly inside the execution cache and this has existed since the first release of Application Streaming.  All of the above rocks thrown, are we going to make the Deploy/Offline case more efficient?  Certainly!

What should I do to optimize first time launch on the XenApp server?

Turn on “-e” RadeRun switch.  Here is a KB article with more details.  Execute one application from each profile, ONCE.  Finally, be sure to then turn off -e.  Yes, I say turn it off because if you don’t you will un-pack everything from the CAB on EVERY launch of any application for every user – which will be dog slow.

You can achieve the same thing by running RadeRun.exe directly from the command line, specifying the -e switch.  This best done by automated systems, when the users aren’t around.

With the single run with “-e”, everything will be extracted from the Application Hub and placed into the streaming execution cache.  The streaming system will still do it’s “just in time” programming, but it will pretty much never conclude that a cache fill is needed and the result is that execution will not suffer a first time launch penalty.

Enjoy,

Joe Nord

Citrix Systems, Product Architect for Application Streaming and User Profile Manager.