There you are, cranking some code after my introductory piece on scripts in App Streaming and you want to take it to the next level. What interesting things can I do with scripts?
Among the most important items that occurs with scripts is that a whole bunch of environment variables get created to assist the script. To show this, I created a prelaunch script .cmd file which does the following:
- @echo off
- echo prelaunch
- set aie
A side note is that all of these variables are also created for streamed applications. Very few make use of it, but they are there…
Back to this post
Run the application (doesn’t matter what the application is) and you’ll see the pre-launch script execute, and then thanks to the pause in the script, it will stay visible so you can see what it displayed. Note: The application will not start until you hit the any key.
Saving you much work, here’s a screen capture of what you’ll see. This screen captured with streaming client version 6.0.
First: The streaming system set environment variables all start with “AIE_”. This is an inheritance from App Streaming’s ancestry in the AIE technology of Presentation Server 4.0
Second: The most important environment variables are
- AIE_NAME and
Third: The AIE_NAME environment variable is set WRONG!
No, I do not make this crap up.
I hit this when working scripts with the present build – not yet released code and was shocked! Shocked more when I installed 6.0 onto a machine and see it’s wrong there too. Shocked worse when I inspect the code and this tells me that it’s wrong on 5.2 as well. I haven’t validated this by an actual test.
Backup a minute: What’s wrong?
Thankfully only 1 of the 3 is busted. AIE_NAME is SUPPOSED to have the streaming target GUID. In my capture above it has a bunch of extra characters. The AIE_FSUSERROOT and AIE_REGUSERROOT variables are “correct”.
Back to the layers of glass, the middle layer of isolation and the top layer of isolation get their name on disk and in the registry based upon the GUID that identifies each execution target. Each target has a GUID *AND* each profile has a GUID. The layers of isolation are the execution TARGETs and from here, the GUID uniquely identifies the isolation layers for any given execution target, without having to use names.
In a script, you pretty much always need the GUID. If you’re going to mess with the layers of glass before the app runs, you need to know WHERE the layers are located. This is most critical when the script runs OUTSIDE of isolation, but it is also available when the script runs inside of isolation.
If AIE_NAME is “wrong”, how do you get just what you need.
Conveniently, the AIE_REGUSERROOT is correctly set. Here’s an example value.
We have most of what we need, but there’s a bunch of gorp in the front.
To get just the GUID in a CMD/BAT based script, a bit of artful batch programming is required. Here are the key lines.
Script starts here…
if not defined AIE_REGUSERROOT echo AIE_REGUSERROOT is not defined & goto :fail
REM Get the GUID part and place into environment
FOR /F “TOKENS=5 DELIMS=\” %%A IN (‘echo %AIE_REGUSERROOT%’) DO SET AIEGUID=%%A
echo AIEGUID is %AIEGUID%
Script ends here…
Darn near magic, but it works.
Courtesy of a bit of batch file elegance, you can get to the GUID even though the streaming system seems to have gone out of its way to confuse matters.
A side note is that once Inter-Isolation Communication gets involved, there are more layers and the GUIDs get more elaborate. I’ll ignore that for the moment.