Home > Blogs > VMware ThinApp Blog

Scripting within ThinApp

If you have need for special functions or processes which need to occur prior to or during the execution of your ThinApp packaged application, using a script within your ThinApp packaged application can accomplish these tasks based upon a nearly infinite amount of validation logic already available within Windows VBS scripts.

Scripting Outside the Callback Functions

If you are using a VBS script in your ThinApp packaged application, it should be noted that the script will be called when each and every parent process (entry point) and child process is executed. Any script code outside the callback functions will be executed.

Dim WSHNetwork, WSHShell, objFSO, objShell
Dim sDrive, sShare, sName
Set WSHNetwork = CreateObject("WScript.Network")
Set WSHShell = CreateObject("WScript.Shell")
Set objFSO = CreateObject("Scripting.FileSystemObject")

Scripting Inside the Callback Functions

The script will be launched when the ThinApp VOS needs any one of the four callback functions. In reference to the Callback functions – think of the script as a UDF (User Defined Function) repository for the ThinApp VOS.


Is called only once when the first ThinApp application is launched in a package. It is NOT called when a second ThinApp application is launched from the same ThinApp package so long as the first ThinApp application is still running.

Function OnFirstSandboxOwner

WSHNetwork = CreateObject("WScript.Network")

          Set WSHShell = CreateObject("WScript.Shell")
          Set objFSO = CreateObject("Scripting.FileSystemObject")
          sDrive = "X:" ‘ Set the Drive Letter to map
          sShare = "\\SERVER\SHARE\FOLDER" ‘Set the UNC Path
          ‘ Conduct Drive Mapping
          If Not objFSO.DriveExists(sDrive) Then
              WSHNetwork.MapNetworkDrive sDrive, sShare, 0
          End If
End Function


Is called prior to the ThinApp application being launched. This occurs regardless if another application has the sandbox locked open or not.


Function OnFirstParentStart
          ‘ Set the current directory
          WSHShell.CurrentDirectory = "X:\APP\DATA"
End Function 


Is called when the any Parent process exits. This occurs when each parent (i.e. Entry Point) shuts down.
NOTE: It will occur even if the parent process spawns a child process (or multiple child processes) and then exits. This function is ALWAYS executed when an parent process (i.e. Entry Point) exits.


Function OnFirstParentExit
          ‘Delete DB Lock Files
          If objFSO.FileExists "X:\APP\Data\DB.LCK" Then
              objFSO.DeleteFile "X:\APP\Data\*.LCK", True
          End If
End Function 


This function is called when the very last process in the ThinApp VOS exits – whether it be a child process or the parent process.


Function OnLastProcessExit
          ‘ Unmap X: Drive
          WSHNetwork.RemoveNetworkDrive "X:", True, True
End Function

WARNING: When using NET.EXE to un-map a network drive or network printer, it should be noted that the use of NET.EXE within the OnLastProcessExit callback function will cause a looping condition. 

Scripting Limitations

  • Only VBS is supported natively
    • Load the Scripting Engine into the package.
    • Create a VBS script that launches your own script against it’s scripting engine.
  • Only ONE VBS script can be loaded into root of a package.
    • While this may be theoretically true, it is not technically accurate as multiple scripts can be loaded.
      NOTE: Using multiple scripts can be
    • Create a VBS script that launches your own script against it’s scripting engine.
  • The script will be called for each parent and child process and for EACH callback function.
    • Non-function code (i.e. code not within a ThinApp callback function or other scripted function) will be executed for each parent process (i.e. Entry Point).
    • Call Back functions will be executed ONLY when one of the four application timings are triggered (e.g. OnLastProcessExit is called when the last process in the virtual bubble is shutdown).
  • Use common variables at the top of the script outside any of the callback functions for assigning standard values.
    • Use of commons system variables makes it easier and cleaner to script as well as keeping your code clean and easy to troubleshoot. Why define that variable for four times when you only need to define it once and reference it multiple times?
      NOTE: This is a standard way of scripting, however, it does not mean there aren’t any scenarios in which you may need to redefine a variable.
  • Test your script code outside ThinApp first.
    • Make sure your code does what it’s supposed to do before you dump it into a packaged application. Test it out on its own as well as put it into an empty or test ThinApp package to see if it executes as desired.
  • Comment, Comment, Comment
    • When you go back to try and troubleshoot your scripts, it makes troubleshooting a lot easier if you can read the comments to determine what you were attempting to accomplish with a particular piece of code.
This entry was posted in Scripts on by .
Dean Flaming

About Dean Flaming

Dean is currently an EUC Architect and member of the VMware End User Computing Enablement and Lighthouse Support teams, working to develop communications and IP around VMware End User Computing products and solutions as well as support many various Lighthouse accounts with their own EUC practices. Prior to this, from 2008 through 2012 Dean was one of VMware's End User Computing Specialists. Throughout his time at VMware, Dean has also written and published various articles, videos, and podcasts regarding VMware's EUC Solutions.