Post to Twitter |
Comments (6) |
Views (20290) |
The Application Streaming system "streams" stuff from the central network server to an execution platform. The streaming aspects of this are very neat, but it turns out for many customers that the centralized publishing and the isolation provided from Application Streaming are the important parts. Well, different people have their own definition of the important parts, but stick with me on the concept.
The trick though is that a "first time launch" for a large application can be a massive data transfer and this isn't desirable if all you really wanted was centralized publishing and isolation. How can you move that data transfer to "network idle time"? RadeDeploy.exe is the utility included with the streaming client for this purpose. Its is a command line utility that will advance copy the streaming content onto the execution machine. It is assumed that the admin has facilities in their software management system to control when this utility gets executed so that the streaming content gets copied down to the execution machine before users arrive in the morning and start running applications.
Server side or client side?
Application Streaming client runs in two spaces: Stream to Client or Stream to Server. For the most part, pre-deployment applies primarily to the stream to client configuration as its assumed that the Presentation Servers have a fast network between them and the file server that holds the streaming content.
The ultimate mission is to move execution content from the central file server into the RadeCache execution spaces. These are the "installation layer" of the 3 layers of isolation. These directories are always a subset fill of the entire installation contents. No matter what percent populated, the isolation system will lie to the application and tell it everything is present.
Here is the RadeCache space on my machine.
Copying from the network server to runtime fill the RadeCache execution space is the streaming aspect of Application Streaming. In an online case, or more exactly, a non-pre-deployed case, the isolation system does cache fills by extracting content from the CAB file stored on a network server, pulling down the item needed for execution of the application, just in time for use. This is the part of running the application, particularily first time launch, that generates network traffic.
To enable "offline use", the Streaming System also supports a concept called "PreDeploy". Instead of streaming from a network server to the RadeCache, the streaming system will instead use a local Deploy folder as its source - and never contact the network server for the cache fill operations. This is good stuff and since the Deploy location holds 100% of the content from the network server needed to run that application, it is possible to disconnect from the network while running a "streamed" application.
Here's a snapshot of the Deploy location
Now - is it streaming?
The cool part of this implementation of "offline" is that the majority of the streaming system is completely unaware of the concept of offline. When a cache fill is needed, the caching system asks the streaming service (radesvc.exe) to do the cache fill. The services' logic is simple: Do I have this in the Deploy location? Great, use that one. Else - consult the network server. In the case of pre-deployed, the answer to the first question is always yes, so the traffic to the network server is completely avoided. The file system driver that initiates the cache fill operation remains completely in the dark that the streaming was from one side of the hard disk to the other rather than across the network. Keeping it simple, keeps it from breaking.
RadeDeploy.exe
Is the utility that populates the Deploy location identified above in graphic. RadeDeploy copies the CAB file and other contents from the central file server and places it into the Deploy location.
Notice that RadeDeploy DOES NOT populate the RadeCache! It perhaps SHOULD, but it doesn't. This means that even if you do RadeDeploy to pre-copy execution content onto the client machine, you still have a first time launch penalty to apply to the first user on that machine that runs an application from that profile. How can this be avoided? In an ideal world, RadeDeploy.exe would also or optionally also populate the RadeCache. It doesn't (Streaming Client 1.2).
You can do it manually. How?
1) Do not delete the RadeCache directory. DACLs are applied there that let the streaming service user account perform cache fills.
2) Create a subdirectory there to match the GUID and Version of the Target to execute. Easiest way, run it once, see what gets created.
3) Extract Device\C and all dubdirectories from the CAB and place them into the RadeCache manually.
"Magic" is an acceptable means of populating the streaming cache. Software management systems are assumed to be good people for populating the cache. Ideally, you should do this when the streaming service is not running as it likes to keep track of what is in the cache so it can decide what to delete and otherwise avoid conflicts in cache fills/deletes. At a minimum, do it when there are no active applications using the same cache content that is being filled.
When more stuff is where it will ultimatley need to be, runtime performance is optmized.
Final thought - Stream to Server and RadeDeploy
I'm not a big fan of Deploy for server side execution. The servers are in the data center and they have fast and reliable networks. Many application only EVER access 25% of what they "install", so avoiding the full CAB file can cut down the overall data transfer required in the data center. There's more...
Through HRP1 (Streaming Client 1.1), the non-Deploy update of cache space for Target update is much more efficient for that the Deploy case; only the changes are transferred on upgrade of a Target from V1 to V2. In the upcoming Delaware release, this preference to not using pre deploy largely goes away as the same differencing is algorithm is given to the Deploy case as for the "online" update case.
Enjoy,
Joe Nord
Comments (6)
Jun 26, 2008
Reinhard Teischl says:
Hi Joe, interesting as your last comment on my question. Unfortunately there &#...Hi Joe,
interesting as your last comment on my question. Unfortunately there _are_ applications which load more than 25% of what they need, for example MS Autoroute 2007. You have to pre-deploy and pre-populate the cache, otherwise it takes several minutes until the application gets started. We're scripting it now, the cab is pre-populated in the RadeCache folder from the fileshare. Pre-deploy isn't utilized, it isn't necessary.
Reinhard
Jun 26, 2008
Joseph Nord says:
Thanks for the feedback Reinhard. MS office is the 25% example in my brain...Thanks for the feedback Reinhard. MS office is the 25% example in my brain. Good to know about MS AutoRoute. The foundation of my post is that while admins can gather from observation where stuff gets placed for a cache fill, they still want or need to know that there are no secrets in the cache fill that would bite them if they did the fill ahead of time without the streaming service knowing about it.
I receive this question from time to time via support channels. Is it is okay (or will it work) for the admin to take other means to populate the cache. Answer: Yes. This post adds some background information to how it works. Thanks for reading and taking the time to comment.
The only thing that is tricky is where the streaming service manages its "delete" activities. The service does a DIR /s on the cache when it starts up and adds up the size of everything in the cache. From there on, cache fills and deletes are a + or - to the number in memory. So, populating the cache when the service isn't looking means it isn't aware of the true size of the stuff in the cache. Does this really matter? No. Pretty much harmless.
The service also has the mission of performing cache fills (and deletes) - and if a file is being opened at the same moment that you are magically filling that file into the cache, there's a window where the streaming system AND your cache fill will compete to fill that file into the cache - potentially resulting in a cache fill failure on the streaming system. Its a small window, but it is there. So long as the streaming FSFD and Service are the ones doing the cache fill, they have the mission of making sure the cache fill/access conflicts do not occur. Does this matter? A little bit. If the server / client is mostly idle, then the odds of hitting this cache fill conflict are pretty low.
Avoiding this window of failure is the foundation reason for the RadeCache utility. Here, the utility doesn't delete the stuff from the cache or even enumerate what is there. Instead, it sends commands to the service to ask it to do the work - and the service protects itself from collisions.
The most rebust method to avoid the collision is to kill all the streamed applications, "net stop radesvc" to turn off the streaming service, update the cache, then "net start radesvc" to bring the service back to life (programmers short cut for a reboot). The key thing is that there were no active streamed applications running when the service was unloaded.
The FSFD that does the layers of isolation stuff for disk (ctxsbx.sys) will "see" the streaming service go away and come back and will use the "new" service for future cache fill operations.
For filling the cache, its perhaps easier to just "know" that streaming is idle and fill the space; this way can avoid killing all the presently running streamed applications. But to be aware there's a small window there on the magic fill that you and the streaming service could "compete" to cache fill or delete the same file.
-Joe
Jun 29, 2008
Brian Wagner says:
Joe, To populate the Radecache folder, I've used the raderun -e comma...Joe,
To populate the Radecache folder, I've used the raderun -e command to extract the CAB out.
Any reason you didn't mention this method?
Thanks!
-Brian Wagner
Anonymous replies:
Jul 07, 2008
Joseph Nord says:
> Any reason you didn't mention this method? No good reason. The RadeR...> Any reason you didn't mention this method?
No good reason. The RadeRun -e method works swell, but the only easy method to pass "-e" to RadeRun is via RadeRunSwitches in the registry. Doing this is "GLOBAL" to all application launches and I want to avoid always running with the cache fully populated. I mean, if you need it for 5 of 10 apps, there are 5 where populating -e would be a detriment.
Also, even with -e, you have to trigger the applicaiton launch at least once. With the manual method, this can be avoided.
Aug 29, 2008
Anonymous says:
Hi Joseph, I'm new to Citrix and have read a number of your posts with great in...Hi Joseph,
I'm new to Citrix and have read a number of your posts with great interest.
I have a question about manually streaming an application. I have resorted to doing this after
getting this error When I click one of the listed streaming applications on the PNA:
"Program NeighborHood Agent Could not launch the requested published application"
I could not find anything on this error on the forums and there was nothing more logged in the application log.
Onward to manual streaming.
When doing the manual stream I simply copied the required files to c:\program files\citrix\Deploy
and then per your post copied the relevant files from Device\C files to the RadeCache. All these files
are on the Citrix Presentation server that is part of the EVA btw. I also copied the rad24.rad (the mozilla firefox file) over
to my windows XP client machine and tried running the following command.
raderun -o rad24.rad
to launch the application offline but I get an error that says.
"The requested offline application has not been downloaded yet"
What could be the problem? I have verified that the radcache is populated with the right files per your post.
thanks,
Jasper at xenocode dot com
Sep 09, 2008
Joseph Nord says:
> files are on the Citrix Presentation server that is part of the EVA btw. I ...> files are on the Citrix Presentation server that is part of the EVA btw. I also copied the rad24.rad (the mozilla firefox file) over
to my windows XP client
Seems to be confusion here on which machine is running the application. The Streaming Client is running on the Presentation Server and possibly on the XP client. Since you populated the execution cache on the Presentation Server, then you imply that you plan to execute the application on the server. The user interface will be re-directed via ICA, but the Streaming Client will be running on the server.
But, issuing the RadeRun command on the XP client in the question above implies that you are telling the XP machine Streaming Client to run an the app, and that won't work because you just populated the cache on a different computer. Maybe I read this wrong.
Instead, you should issue the RadeRun command on the Presentation Server. Or, copy the RadeCache contents to the client.
Either way, the use of offline here is somewhat overkill. This true especially if plan to run app on the XenApp server.
If plan to run app on the XP machine, then you could make your server be your local machine. Curiously, this has to be UNC path or with Delaware, HTTP path accessible on the execution machine. Since the "file server" would actually be the local machine, there is no need to mess with Deploy for offline access. Access would always be "online".
Licensing then will be the only trick. The RadeRun will attempt to pull a license on the XP machine. The point: the streaming client will send "I'm running ABC" notices to the farm for the client system and when it says "I'm running ABC", the farm will respond "ABC WHO?". The farm wasn't involved in the launch activity, so the notification of launch progress for unknown app gets a response of bad confusion. "The Web Interface reported an unspecified error" or something close to that.
At BriForum, Jeroen van de Kamp showed a nice work around for this in using a .RAD file as the parm to RadeRun and editing the .RAD file contents to tell the Streaming Client to not report back app usage. This switch not available as parm to RadeRun.exe. I've been meaning to write about it.
Add Comment