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.
WHENThe 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:
SCRIPT TIMING and EVENT:• 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.
WHEREThe 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:• 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.
HOWThe 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:• 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.
Example 1The 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 \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\\Bethany \n</SCRIPTBODY></SCRIPT></DEPENDENCY>
Note: The “\n” indicates in SCRIPTBODY that another command is coming on the next line.
Example 2The 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 \nCALL k:\\usr-w2k.cmd \n\\\\sft-softgrid\\shr\\editini.exe c:\\word\\word.ini "FileLocations" TempPath c:\\tem \n</SCRIPTBODY></SCRIPT></DEPENDENCY>
Example 3The 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.
<DEPENDENCY><SCRIPT TIMING="PRE" EVENT="LAUNCH" WAIT="TRUE" PROTECT="TRUE"><SCRIPTBODY>%SFT_MNT%\\OfficeXP\\Office10\\proflwiz.exe</SCRIPTBODY></SCRIPT></DEPENDENCY>
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
http://blogs.technet.com/softgrid/archive/2007/04/18/using-scripts-with-softgrid.aspx The following was
"...All scripts must be placed between the <DEPENDENCY> tags within the OSD files..."
I do not agree with that since we use Citrx Terminal Server Environment. Let me explain a situation why we place an self written wsh script into the CODEBASE TAG to launch an application and not like the usual way into the DEPENDENCY TAG.
If you want to stream an application which its size is about 250 MB or bigger than that and you have registry / ocx / dll files you'll need run before the application is launched. And you'll need to map different network drives for each client but for the same application. This normally happens if you have one application you use for several clients but with different environments. Then you need to execute the script before you stream the entire application and prepare the virtual registry for your client and your network mapping etc... If the script execute fails then your script gets noticed about this error and stops streaming the entire application. This saves you network traffic and you see errors before the application gets started. You can modify clients error messages instead having SoftGrid errors which may not SoftGrid errors at all if an ocx or dll file is missing or an registry setting isn’t performed or an network drive is wrong mapped which this application needs to get started. The advantage why we don’t place the script in the DEPENDENCY TAG is as follow.
The OSD File is streamed by sfttray and you do not have any control of the osd afterwards. The application tries to launch after unsuccessful streaming because the osd file does not interrupt on any error. So you cant shut down a application before getting noticed about any wrong settings or errors. Since we discovered that SoftGrid proceeds with the osd launch phase, no matter if you try to set the TAG to WAIT="TRUE". So we had to place the script above all the other TAGS and we developed a script which starts the application. All information we need to run the application we placed out in a ini file which will parsed from the vbs file. So we can run multiple programs, perform multiple registry settings or registering ocx/dll files. But this is only necessary if you have a Terminal Environment which is really limited to clients. Like administrator shuts off the administrative rights for normal users.
The other problem is if you set the PARAMTER TIMEOUT the script you try to perform does not complete all settings before the timeout is reached. The Client tries to launch the application after the timeout is over and this time varies to each client. This was our secondary problem that all clients we tried to perform registry settings, dll/ocx registrations where too slow before the client launched the application. The timeout settings would be too high and not countable to set in the osd file. So we come to the conclusion to place the script above the DEPENDENCY TAG to make all settings trough the script and after that we launch the application. So we make sure we do not have unnecessary timeouts and we guarantee the application launches in the quite correct manner.
I hope this comment is helpful to anyone who tries to script with SoftGrid.
Good luck and comments are welcome.
The MS SoftGrid team has added a blog entry describing how to use scripts within .OSD files to modify the behavior of the application launch. They've also provided some basic examples of how one ...
The chaps out in Boston are doing some great work at the moment and have even started getting there blog