I wrote two articles recently on introducing App Streaming scripts and describing how environment variables are set to assist the scripts manipulation of the isolation space. These were “warm up” for the real goal of writing today’s article on implementing “global” scripts.
In the introduction, I covered that a script is anything executable by windows and that all scripts are treated as binary, even .CMD files. Scripts can run before sandbox create, during sandbox tear down and they can be run outside or inside of isolation. There can be an “unlimited” number of scripts and finally, scripts can exist at the profile layer or the target layer. If that’s an ear full, read the full post on the intro.
Scripts in App Streaming are a very powerful animal! But – something’s missing.
I would like to define a single set of scripts which will apply to “ALL” profiles. This would centralize maintenance of a common set of scripts to a single place and any time you maintain “one”, it is better than maintaining “many”. Unfortunately, the streaming system doesn’t define a concept of global scripts. Hum.
Can it be simulated? Answer, yes and the rest of this post talks about how.
On your network, you have a bunch of file servers. One of them is a network server that holds the application streaming profiles, we title this one the App Hub. This could be a web server, but for today, let’s go with the UNC access method.
On the App Hub, there is “top” directory and below that directory are a whole bunch of subdirectories, one for each application streaming profile. The streaming profiler insists on this format by forcing the profile save dialog to always create a subdir for the saved profile, and then putting the profile into that directory.
Generally speaking, we let the streaming profiler store the stuff on this server, but we could add a subdirectory there. I’ll title it “GlobalScripts”. Notice there are no spaces in the subdirectory name, just because spaces create headaches.
The App Hub looks something like this
Add a new subdirectory, GlobalScripts
Inside that directory, place 4 script files. Each of these COULD be executable code or could be .CMD files, or .VBS. For this example, I’ve made them all .CMD.
Answer: Full matrix of PRE/POST and INSIDE/OUTSIDE of isolation.
Also in this directory, I added a couple extra files to assist with the identification of the isolation GUID that identifies the sandbox. Note, in global scripts outside of isolation, this environment variable is our KEY to knowing which sandbox we might want to adjust before it starts. If we are inside of isolation, this isn’t as key as the script in the sandbox can adjust what it believes to be the real machine, without hurting the real machine. It will land in per-user space.
If you peek inside these scripts, you will see really pretty stuff like:
echo Global PostExit script (isolated)
Hopefully your version will have more important contents, such as the pre-launch/post-exist out of isolation scripts that I’m hacking with for a larger project. Notice, a full 887 bytes!
Okay – we have global scripts. That’s great. How do we get all of the profiles to call them? Excellent question – the streaming system won’t exactly help you.
You can use the streaming profiler GUI to open each profile, right mouse button, properties/scripts, add the 4 scripts to the profile, correctly set each of the checkboxes to select pre/post and isolated/not and then all is happy and grand.
For 100 profiles, when you’re done with this, you’ll have zero confidence that you didn’t fat finger at least 40 of them and you’ll be screaming for a programmatic solution. Save that for a separate day.
Profile scripts to call global scripts
You need to add scripts to the streaming profiles that the streaming system WILL CALL when it runs applications. Here, we have another set of 4 scripts. By convention, I’ve taken a liberty to say that the admin will have defined an environment variable called APPHUB to point to the network server that holds profiles. While it is POSSIBLE for App Streaming solutions to utilize numerous application hubs for profile storage, this is rare and most people have “1”.
Each of these are TINY! They are intended to never be maintained. All the maintenance should occur in the single location for GlobalScripts.
Here’s an example contents.
Observe that it is mostly comments. The only line of importance is the one at the end that calls the program or script stored in the GlobalScripts directory on the App Hub. Lather, rinse and repeat for the other 3 scripts that get added to all profiles.
When you get done updating all 100 of your profiles to have them call the single set of global scripts, you will have a single set of 4 “GlobalScripts” maintained in a single spot.
One of the configuration items in the profiler is the SEQUENCE that scripts are run. In my example, I’ve implemented this as
- Pre-Launch not isolated
- Pre-Launch isolated
- ( Sandbox exists here – application runs )
- Post-Exit isolated
- Post-Exit not isolated
The other thing to make this more elegant is to replace the .CMD files with actual programs. All that screen flashing when the .CMD batch processor runs will not be ideal and converting this to .EXEs that don’t show anything would clear up the screen.
Add it all up and you CAN implement global scripts. Yes, life would be better if the streaming system automated most of this.
Citrix Systems Product Architect
Application Streaming, Profile Manager