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 run-time 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, particularly 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.
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 ultimately 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.