Scripting within an OSD file

I noticed some posts on the SoftGrid Forums lately that could be addressed with some useful scripting with the .OSD files for a SoftGrid package. Scripting within .OSD files is a very powerful feature and can be used to solve or create workarounds for a vast number of situations. This is an excerpt of some text that was created to give the basics of the scripting concept. I try to go into detail on the Whats and the Hows and I also put in several script examples at the end. These examples are actual scripts that have been used in the field. Along with the example is an explanation of what the script is doing. After reading this article however, try to look at just the script example and decipher for yourself what it is doing. A mini self quiz if you will.

Scripts written in almost any language can be passed from the OSD file of a Microsoft SoftGrid Application Virtualization enabled application to a client that has the necessary interpreter in place. Organizations may have preexisting scripts written in Visual Basic, Perl, .bat files, .cmd files, etc. that are required for their applications to run effectively. By following the basic rules of scripting in an OSD file those existing scripts can be leveraged here as well.

The following questions on “When”, “Where” and “How” a script runs need to be answered before the script can be placed inside the OSD file.

All scripts must be placed between the <DEPENDENCY> tags within the OSD files. The Sequence Engineer can choose to either refer to an existing by its file name or can enter the exact syntax of the commands in the script section.

“WHEN”

The OSD file can launch scripts at various points within the launching of Microsoft SoftGrid Application Virtualization-enabled applications. The script’s first setting determines when the script will run:

SCRIPT TIMING and EVENT:

PRE STREAM: Before the application begins streaming. (For instance, if the user needs to open a VPN to Microsoft SoftGrid Application Virtualization Server prior to running the application.)

POST STREAM: Run after authorization and streaming but before the Virtual Environment is setup.

PRE LAUNCH: Run inside of virtual environment, before execution begins.

POST LAUNCH: After the application is launched.

POST SHUTDOWN: Clean up activity or deleting settings files.

The following flow chart depicts the sequence of events when scripts are used within an OSD file.

“WHERE”

The next item that must be determined in running scripts is “Where” the script will run. There are only two options available here, either inside the virtual environment or outside it

Protect:

Protect=True: Allows the script to run within the protected environment. This script placement can be very useful for troubleshooting.

Protect=False: Allows the script to run outside the virtual environment. This script placement can be very effective when files need to copied locally to a client but there is no need to penetrate the virtual environment.

“HOW”

The next item that must be determined in running scripts is “How” the script will run. This option defines how much time, if any, the script will wait to completely execute. The new “TIMEOUT” attribute is used to determine the amount of time in seconds that the Microsoft SoftGrid Application Virtualization client will wait for the OSD file’s script to complete. For backwards compatibility the WAIT attribute is still supported in Microsoft SoftGrid Application Virtualization 4.1. A script that runs in a synchronous manner will run each step of the script without waiting for the next to have been completed.

TIMEOUT:

TIMEOUT=xx: The client will wait xx seconds for the script to complete before returning an error.

TIMEOUT=0: The client will wait indefinitely for the script to complete.

Wait:

Wait=False: Continue without waiting for the script to finish.

Wait=True: Do not start the next step until the script finishes.

Note: The client does not support a PRE SHUTDOWN event (it is not possible to know the exact instant before a user clicks, for example, the [X] in the upper right corner, or types Alt+F4). The Protect attribute specifies whether the script runs inside or outside the virtual environment. The Wait attribute specifies whether the client waits for the script to finish before proceeding to the next phase. Scripts may be written in any language, but the language must be installed locally on the client machine.

There are two types of scripts that can be used in the OSD file, <SCRIPTBODY> and <HREF>. The following table describes each type. You can decide for yourself which one is the better to use in your situation or environment. I treat this table as a score card for the script types.

<SCRIPTBODY>

<HREF>

Can be used to call an executable by searching for the executable in the client’s Path statement.

Can be used to call an executable by searching for the executable in the client’s Path statement.

Uses the “\” as an escape character and as such requires an extra “\” to pass the actual character.

Does not use the “\” as an escape character.

Can be used to pass non executable commands such as the DOS make directory (md). This is actually a part of the command.com.

Cannot be used to pass non executable commands such as the DOS make directory (md).

When used, the contents of the script are copied to a temporary .bat file on the client’s drive. The .bat file is executed and then deleted when the application is closed.

Does not create a temporary .bat file but instead executes the contents of the script directly on the client.

When used a DOS window appears on the screen during the execution of the script’s .bat file.

No DOS window appears on the screen unless the process being called is a console application.

The SCRIPT tag is a child of the DEPENDENCY tag and the SCRIPTBODY or HREF tag is a child of the SCRIPT tag.

The following list some examples of scripts used in OSD files.

Example 1

The following example uses the SCRIPTBODY tag to first ping a server by its IP Address. It then deletes a drive mapping and creates a new drive mapping to a server using the same drive letter that was just deleted.

<DEPENDENCY>

<SCRIPT TIMING="PRE" EVENT="LAUNCH" WAIT="TRUE" PROTECT="TRUE"> <SCRIPTBODY> @echo on \n

ping 192.168.100.100 \n

net use x: /delete /y \n

net use x: \\\\ServerName\\Achieve \n

net use y: /delete /y \n

net use y: \\\\ServerName\\Achieve\\claims\\Sean \n

</SCRIPTBODY>

</SCRIPT>

</DEPENDENCY>

Note: The “\n” indicates in SCRIPTBODY that another command is coming on the next line.

Example 2

The following example uses the SCRIPTBODY tag to first map a network drive to a server’s netlogon share. It then calls an existing .cmd file from that mapped network drive. The script continues by calling the executable editini.exe and opening the word.ini to add a TempPath.

<DEPENDENCY>

<SCRIPT EVENT="LAUNCH" TIMING="PRE" PROTECT="TRUE" WAIT="TRUE">

<SCRIPTBODY>

net use k: \\\\w2k-pdc\\netlogon \n

CALL k:\\usr-w2k.cmd \n

\\\\sft-Microsoft SoftGrid Application Virtualization\\shr\\editini.exe c:\\word\\word.ini "FileLocations" TempPath c:\\tem \n

</SCRIPTBODY>

</SCRIPT>

</DEPENDENCY>

Example 3

The following example uses the variable %SFT_MNT% to refer to the client’s virtual mount point (typically Q:\) and calls the executable “proflwiz.exe”. The absolute path is used here because it can be assumed that the Microsoft SoftGrid Application Virtualization Mount Point would not be part of the client’s path statement.

<DEPENDENCY>

<SCRIPT TIMING="PRE" EVENT="LAUNCH" WAIT="TRUE" PROTECT="TRUE"> <SCRIPTBODY>%SFT_MNT%\\OfficeXP\\Office10\\proflwiz.exe</SCRIPTBODY> </SCRIPT>

</DEPENDENCY>

Example 4

The following example uses an “if not exist” statement to determine if a file named “random.ini” is present in the Windows directory and if it does not then the file is copied from the Softricity Virtual Drive to the Windows directory.

<DEPENDENCY>

<SCRIPT TIMING="PRE" EVENT="LAUNCH" WAIT="TRUE" PROTECT="TRUE">

<SCRIPTBODY>if not exist "H:\\WINDOWS\\random.ini" copy "Q:\\app.v1\\random.ini" "H:\\WINDOWS\\" </SCRIPTBODY>

</SCRIPT>

</DEPENDENCY>

Scripts via <HREF>

Example 1

The following example uses the variable %SFT_MNT% to refer to the client’s virtual mount point (typically Q:\) and calls the executable “proflwiz.exe”. The absolute path is used here because it can be assumed that the Microsoft SoftGrid Application Virtualization Mount Point would not be part of the client’s path statement.

<DEPENDENCY>

<SCRIPT TIMING="PRE" EVENT="LAUNCH" WAIT="TRUE" PROTECT="TRUE"> <HREF>%SFT_MNT%\OfficeXP\Office10\proflwiz.exe</HREF>

</SCRIPT>

</DEPENDENCY>

NOTE: Although this is the same syntax as in the above example of <SCRIPTBODY> it is a more efficient way of launching an executable because <HREF> does not need to create the temporary .bat file on the Microsoft SoftGrid Application Virtualization client.

Example 2

The following example uses an absolute path to launch the command prompt. Using the absolute path in this example is most likely unnecessary since it can be assumed to be in the client’s path searched by <HREF>. This command prompt will launch before the application but after the Virtual Environment is set allowing the Sequence Engineer to browse and even manipulate files in the Virtual Environment on Q:\.

<DEPENDENCY>

<SCRIPT TIMING="PRE" EVENT="LAUNCH" WAIT="TRUE" PROTECT="TRUE"> <HREF>cmd.exe</HREF>

</SCRIPT>

</DEPENDENCY>

NOTE: Although this script does not seem very exciting. In fact in class I would often sarcastically say “It launches the command prompt. Big Deal.” Yes, it is a Big Deal This is a very effective technique for launching troubleshooting utilities such as Filemon, ProcMon into the Virtual Environment.

Example 3

The following example calls an existing .cmd file from a network share.

<DEPENDENCY>

<SCRIPT TIMING="PRE" EVENT="LAUNCH" WAIT="TRUE" PROTECT="TRUE"> <HREF>\\SRV_NAME\NT_SHR\PRE_SCRIPT.CMD</HREF>

</SCRIPT>

</DEPENDENCY>

There is so much you can accomplish with scripts in the .OSD file. Like anything you do to files at the Server, always make a backup copy of your .OSD file before you start modifying it. Also, and it may go without saying, always, always, test your scripts before you deploy them in production.

See you in the Forums

Sean Donahue

Comments

• Anonymous
  January 01, 2003
  The first thing you’ll probably want to do in preparation for your callback is gather up any relevant

• Anonymous
  January 01, 2003
  I was reviewing some of the SoftGrid Microsoft Application Virtualization issues that came in over the

• Anonymous
  January 01, 2003
  I recently had the need to leverage a Softgrid pre-launch script to copy an INI file into a subfolder of the user's Application Data folder. Softgrid has two methods of pre-launch scripting: ...

• Anonymous
  January 01, 2003
  PingBack from http://www.oppergod.nl/2007/10/13/scripting-softgrid-packages/

• Anonymous
  January 01, 2003
  In het artikel Scripting within an OSD file laat Sean Donahue zien wat de mogelijkheden zijn. Lees het artikel hier

• Anonymous
  January 01, 2003
  Now as I have mentioned in the past this month and next I am traveling around a lot. And one of these