Using Scripts with SoftGrid

The chaps out in Boston are doing some great work at the moment and have even started getting there blog going! I will probably point to the Team a lot when important notes do pop up.

Anyway they also done an excellent post on scripting in SoftGrid

The original post is or just feel free to just keep reading!


We often times get questions about using scripts with SoftGrid so we thought we would post some basics to get you started.  We have the ability to run any number and style of scripts within an OSD file and these scripts can be immensely useful in overcoming some limitations with applications or setting up particular configurations that an application would require in order to run properly.

Scripts written in almost any language can be passed from the OSD file of a SoftGrid 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. One can choose to either refer to an existing script by its file name or you can enter the exact syntax of the commands in the script section.

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

• PRE STREAM: Before the application begins streaming. (For instance, if the user needs to open a VPN to SoftGrid 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 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.

• 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.

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 “TIMEOUT” attribute is used to determine the amount of time in seconds that the SoftGrid client will wait for the OSD file’s script to complete. For backwards compatibility the WAIT attribute is still supported in SoftGrid 4.x. 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=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=False: Continue without waiting for the script to finish.
• Wait=True: Do not start the next step until the script finishes.

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.

<SCRIPTBODY> @echo on \n
ping \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\\Bethany \n

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.

net use k: \\\\w2k-pdc\\netlogon \n
CALL k:\\usr-w2k.cmd \n
\\\\sft-softgrid\\shr\\editini.exe c:\\word\\word.ini “FileLocations” TempPath
c:\\tem \n

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 SoftGrid Mount Point would not be part of the client’s path statement.


We hope you find this information about scripting useful and as always, if you have any suggestions for future topics just let us know.  

– The Microsoft SoftGrid Team

Comments (1)

  1. Anonymous says:

    Now as I have mentioned in the past this month and next I am traveling around a lot. And one of these