Video Screencast Help

Symantec Workspace Streaming Composer Scripting

Created: 02 Apr 2010 • Updated: 29 Jul 2010
Language Translations
Gene Kupfer's picture
+1 1 Vote
Login to vote

I'd like to introduce you to a particular functional area of our Streaming Composer. Anyone that has been doing any amount of packaging will be familiar with the ability to attach scripts and data files to the package. This is actually a pretty powerful tool that allows you to extend your applications in various ways. In some situations, you may even find a requirement to utilize this to accomplish a task during streaming that may otherwise create streaming difficulties. A good example of this is any application that loads one or more processes at install time, which do not exit when the installer exits. The reason this poses an issue to the streaming engine is because it is waiting for an exit code and if a process remains resident, the exit code is never delivered. By adding a script to the end of the streaming process, you can issue a simple net stop or taskkill command to end the process.

What Is Fair Game?

There really isn't a rule in terms of what you can attach as a script or data file. There are two rules that are important however.

  1. Always be sure that the scripting being done does not in anyway break the rules of your EULA
  2. Do sufficient testing to make sure the script(s) is working as intended and does not cause any issues on the OS

The Exit Code - Batch File

There is not much to say here, except that the very last line of every script should contain the following line, without the quotes.

  • "echo 1 > %1"

The Exit Code - Executable

If your script is in the form of an .exe, it gets only a bit trickier. You can use the following method, to call your .exe from a batch file and exit with the appropriate code.

@echo off
CallYourScriptHere

IF "%ERRORLEVEL%"="1"
Echo 0 >> %1
ELSE
Echo 1 >> %1
ENDIF

Script Priority

When adding a script you'll notice a drop-down presenting you with multiple options. They are...

  • PreInstallation
  • PostInstallation
  • PreExecution
  • PostExecution
  • PreUninstall Requirements
  • PreUninstall
  • PostUninstall
  • Data File

At first glance they are fairly self explanatory, but when it comes to utilizing them it is important to understand at exactly what point of the streaming process these execute to be able to use them effectively.

PreInstallation and PostInstallation are the most commonly used and will run your scripted instructions immediately after streaming initiates, but before caching begins and after caching ends but before streaming terminates, respectively.

PreExecution and PostExecution are similar but will initiate before an application starts and after an application exits.These two are persistant throughout the life of the streamed application.

PreUninstall Requirements and PreUninstall actually sound confusing at first, because they appear to be referencing the same time period. However, the minor difference in when these kick of the script can actually make a major difference in a successful streaming process. The first runs before the streaming engine initiates the uninstall process. The reason this is important is because as soon as we kick off this process files are locked and if your script needs to interact with a locked file it will fail. The later kicks off after the streaming engine initiates, but before the uninstall begins. With PostUninstall running after the application is removed from cache.

The Data file provides the ability to attach one or more required files for your application. This is really handy for example, in delivering some DLLs with the application and registering them via a PostInstallation script.

Absolute Or Relative Path

One last thing that is important to mention...if you're including multiple scripts and one or more data files and are wondering what kind of path you should use to get to those files then this should make you smile. All scripts and data files are bundled together into a single directory with the package and delivered to the endpoint in time to be executed. This means that there is no need for lengthy path references. Just issue your command and follow it with the file name that command is going to access. In short, it's a relative path and it's in the same directory.