I received an interesting inquiry recently. Given my post on Never Deploy to XenApp Servers, how do you stop deploy from happening for hosted desktop? Excellent question!
Here’s the situation. Happy XenApp Customer (they are all happy) who uses Application Streaming to deliver applications to their XenApp servers as well as stream to client, primarily for offline access. The applications are published to the user as offline enabled and this works swell to trigger the deploy operation that is required to execute the application when disconnected from the corporate network and also works swell to not trigger Deploy in the XenApp hosted case.
Quick refresher on Deploy
The Deploy space is a COPY of all the needed stuff from the Application Hub, but it is local to the execution machine. The Deploy space makes it possible for the streaming client to support application usage even when disconnected from the network. The Deploy space is generally in \Program files\Citrix\Deploy and the execution cache space is generally in \Program files\Citrix\RadeCache.
At runtime, the streaming client runtime fills the execution space as needed by copying content from the Application Hub – or if Deployed, from the Deploy space. Other than one being remote and the other being local, the activity of the client is the same whether “offline” or “online”. Technically, “Deploy” enables streaming from one side of the hard disk to the other and this keeps life pretty simple from a programming standpoint. I thought it up back in the Tarpon development and I’m still pretty happy with myself.
Deploy is automatically not done on XenApp Servers
It may seem like a good idea to Deploy to the XenApp Servers, but I have already squashed that myth and apparently did a good job there because the corollary, “Never Deploy to XenDesktop” has also been heard.
Back to the customer. They have XenApp running good and are engaging XenDesktop. Application Streaming is delivering the applications to the XenApp servers as well as to the end user machines (notebooks).
Here’s the thing that’s not always obvious. The streaming client KNOWS that Deploying to XenApp Servers is a bad idea. If you publish an application to a bunch of users and offline enable the applications AND if you publish the applications to hosted execution, a single user can use both without triggering a Deploy on the XenApp server.
If the user is running the application server side, the streaming client is still involved but it knows that it is running ON a XenApp Server, so it SKIPS the Deploy. This is the right thing to do. If the admin doesn’t like that, they can still command a Deploy to occur on the server by directly calling the deploy utility, RadeDeploy.exe, but again, you shouldn’t do that.
The customer is now engaging XenDesktop and have connected the hosted desktops to the App Streaming infrastructure from the existing XenApp configuration. Here, the streaming client is running on the hosted desktop and … when performing its app launch concludes that this is a client side execution and background copies down all the bits for offline execution. This is bad.
Here’s a good write up on the percentage of space that is used for online vs. offline execution.
The point: Lots of disk writes start happening to copy the Deploy content down from the Application Hub to place them in the Deploy space where they will exist and get copied again into the RadeCache. All of this is bad to the layers of cake. We want to minimize disk WRITES. Disk writes are backed up either by Xen/Other Virtual Machine manager or by Provisioning Services. Either way, large writes by large numbers or users are bad. Beyond being slow, these writes will occupy space in the per-user write back cache; which is discarded on logoff, so this whole thing will repeat on the next logon.
The Deploy should not occur! But it does. In a “correct” world, the streaming client would be XenDestop aware as it is XenApp aware. If running “hosted”, don’t Deploy! We do not live in a correct world. My initial guidance to the folks that asked me about this was “erase \program files\citrix\streaming client\radedeploy.exe”. All happy with myself because I KNOW that the streaming client shells to the utility to perform the deploy.
With the utility “missing”, the streaming client will have no choice but to push on without the deploy.
Survey says…. didn’t work.
Instead of “pushing on”, the streaming client declared failure and aborted the app launch. Aargh.
Beautiful part of this is that I didn’t have to actually try it. Smart folks on the other side, all I had to do was keep coming up with ideas.
Second round: Replace RadeDeploy.exe with a program that does nothing, but returns “success” return code.
Survey says…. Success!
The only utility I had handy to do this is one I wrote a very long time ago to use for remarking out RUN= statements from the Windows registry. Source is included – please compile it yourself before putting in production. For the programmers in the room, said program is “Hello world” minus the printf. In the common image where the streaming client is installed, copy nop.exe to RadeDeploy.exe.
Back to the Deploy activity
The streaming client “shells” to RadeDeploy.exe which is really “nop.exe”, which returns 0 as RC. With the Deploy “successful”, the launch proceeds with no error, AND the Deploy never happens. Perfect!
I see a future where the streaming client will be XenDesktop aware and skip the Deploy. Until then, this technique may prove useful. If you have other creative solutions to this problem, please share them here.
Next step is getting the RadeCache space available to everyone from a single source, read-only and fully populated at the get-go.
Product Architect Application Streaming