App-V Scripting Within an OSD File

8/6/2019 App-V Scripting Within an OSD File

http://slidepdf.com/reader/full/app-v-scripting-within-an-osd-file 1/5

Scripting within an OSD file

J.C. Hornbeck 11 Oct 2007 5:16 PM

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 powerfulfeature and can be used to solve or create workarounds for a vast number of situations. This is anexcerpt of some text that was created to give the basics of the scripting concept. I try to go intodetail on the Whats and the Hows and I also put in several script examples at the end. Theseexamples are actual scripts that have been used in the field. Along with the example is anexplanation of what the script is doing. After reading this article however, try to look at just thescript 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 SoftGridApplication 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 inan 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 beforethe 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 scriptwill run:

SCRIPT TIMING and EVENT:

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

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

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 areonly 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 placementcan be very useful for troubleshooting.

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

“HOW”

The next item that must be determined in running scripts is “How” the script will run. This optiondefines 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 thatruns in a synchronous manner will run each step of the script without waiting for the next to havebeen completed.

TIMEOUT:

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

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 exactinstant before a user clicks, for example, the [X] in the upper right corner, or types Alt+F4). TheProtect attribute specifies whether the script runs inside or outside the virtual environment. TheWait attribute specifies whether the client waits for the script to finish before proceeding to thenext phase. Scripts may be written in any language, but the language must be installed locally onthe 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 usein 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 isactually 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 theclient.

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 thendeletes 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 \nping 192.168.100.100 \nnet use x: /delete /y \nnet use x: \\\\ServerName\\Achieve \nnet use y: /delete /y \nnet 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’snetlogon share. It then calls an existing .cmd file from that mapped network drive. The scriptcontinues 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 partof 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” ispresent in the Windows directory and if it does not then the file is copied from the Softricity VirtualDrive 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 itcan be assumed that the Microsoft SoftGrid Application Virtualization Mount Point would not be partof 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 absolutepath in this example is most likely unnecessary since it can be assumed to be in the client’s pathsearched by <HREF>. This command prompt will launch before the application but after the VirtualEnvironment is set allowing the Sequence Engineer to browse and even manipulate files in theVirtual 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 effectivetechnique for launching troubleshooting utilities such as Filemon, ProcMon into the VirtualEnvironment.

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 itmay go without saying, always, always, test your scripts before you deploy them in production.

See you in the Forums

Sean Donahue

Documents

App-V Scripting Within an OSD File