ScriptLauncher  is a free tool designed to make it easier to use scripts on Microsoft App-V 5 virtual application package that requires scripts.

App-V 5 supports adding a reference to scripts in the Deployment and User Config XML files. While the new capabilities are great, there are things that we need to do in scripting that need some added help, and that is where this tool comes in.

In a recent training class we ran on App-V 5, we found that there are several problems the App-V scripting solution at present. This list was further enhanced by a contract sequencing of an app that we did for a Cloud Service provider:

  • Microsoft documentation provides examples that all assume that you will place these scripts inside the package when you sequence. While this is a great place for some scripts, often we want to be able to create and modify the scripts post-sequencing. The ideal place to locate such scripts would be on a share, possibly in the same server folder as the App-V package storage itself, or possibly in an independent script folder. We generally don't want to put the scripts inside the package to begin with.
  • Even though the Microsoft Sequencing Guide shows examples of doing so, you cannot use any environment variables directly in the scripts portion of the config.xml files, either for the command path element or in any of the command line arguments. Because there is no conhost interpreter used, the variables are not dereferenced before handing it off to the program that you reference, so that it will see the command line arguments just the way you type them into the file. This behavior is unlike any normal script processing or typing the same command in a command window.
  • Even if you can avoid the use of environment variables for referencing things on the client, if you have multiple sites you probably want to use a variable for the site server share.
  • The environment variables that you might expect may not be present. The scripts are run by a system process, possibly impersonating the user for security, so the environment passed in uses the machine context for the environment, even when performing a application launch script. This is even the case when you only add the scripts into the UserConfig file! This means that:
    1. USERNAME points to computername$
    2. USERPROFILE points to C:\windows\system32\config\systemprofile
    3. APPDATA points to C:\windows\system32\config\systemprofile\AppData\Roaming
    For example:
    Running as USER 4/2 6 9:8:14.015
    ENVIRONMENT VARIABLES:
        ALLUSERSPROFILE=C:\ProgramData
        APPDATA=C:\windows\system32\config\systemprofile\AppData\Roaming
        CommonProgramFiles=C:\Program Files\Common Files
        COMPUTERNAME=AV5CLIW7X861
        ComSpec=C:\windows\system32\cmd.exe
        FP_NO_HOST_CHECK=NO
        LOCALAPPDATA=C:\windows\system32\config\systemprofile\AppData\Local
        NUMBER_OF_PROCESSORS=1
        OS=Windows_NT
        Path=C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;C:\windows\System32\WindowsPowerShell\v1.0\;
        PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
        PROCESSOR_ARCHITECTURE=x86
        PROCESSOR_IDENTIFIER=x86 Family 6 Model 44 Stepping 2, GenuineIntel
        PROCESSOR_LEVEL=6
        PROCESSOR_REVISION=2c02
        ProgramData=C:\ProgramData
        ProgramFiles=C:\Program Files
        PSModulePath=C:\windows\system32\WindowsPowerShell\v1.0\Modules\;C:\Program Files\Microsoft Application Virtualization\Client\
        PUBLIC=C:\Users\Public
        SCRIPTHOSTSYSTEM=TMUHOST
        SystemDrive=C:
        SystemRoot=C:\windows
        TEMP=C:\windows\TEMP
        TMP=C:\windows\TEMP
        USERDOMAIN=TMU
        USERNAME=AV5CLIW7X861$
        USERPROFILE=C:\windows\system32\config\systemprofile
        windir=C:\windows
        windows_tracing_flags=3
        windows_tracing_logfile=C:\BVTBin\Tests\installpackage\csilogfile.log
        __COMPAT_LAYER=ElevateCreateProcess

     

  • If the application prompts for UAC elevation to run as an administrator, the start/stop scripts run twice, once as a user and then as an admin.
  • On some packages, (probably those with virtual services) a script placed at StartVirtualizationEnvironment will lock up before executing.
  • Mounted user drives, like Home drives are not available to the script.

Enter ScriptLauncher

ScriptLauncher is an executable that you place on the client machine and reference as the scripting program in your config.xml files. You make Scriptlauncher.exe the primary script program to run, and then place the complete command line of the script you want to run (including any environment variables) as arguments to the program.

ScriptLauncher will parse and dereference the EnvironmentVariables for you and run the command, even if the App-V Scripting subsystem will not.

ScriptLauncher will create an added environment variable for use in the script called "EffectiveUserName". Use this variable in place of UserName when you run scripts that run in the User Security Context. I love using this to reference C:\Users\%EffectiveUserName%\AppData\Roaming.

ScriptLauncher is a 32-bit console application that produces no output. This means that unless the command you run produces a window, the user will not see anything when the script is run.

Version 1.2 also handles command parameters better than the initial version. Previously, some scripts had problems with path names that included spaces when passed to programs like robocopy. The parameters now preserve any quotation marks you put in the arguments in the config file.

 

Installation

There is no installer. Just copy the file into a folder on the client. You can place it in any folder contained in the PATH variable and reference it by name alone, or you can place it in a new folder and reference it with the full path.

You may want to add an environment variable to the client system to indicate where the scripts are centrally stored. The example below uses a variable called SCRIPTHOSTSYSTEM to point to the site-specific name of the server hosting the scripts. Because some of the App-V scripts run under the user context, and some under the system context, you should make the variable a system environment variable. Such a variable is easily pushed out via Group Policy.

About Scripts

The TMurgent website contains this Blog Post which provides some information about the kind of scripts that you can add to the Deployment and User Config files, and the context that they run under.

You may also need to look at this post about environments and contexts to get a better grip on what is going on.

Below are some examples of use of Scriptlauncher:


<MachineScripts>
    <PublishPackage>
        <Path>C:\Windows\ScriptLauncher.exe</Path>
        <Arguments>\\%SCRIPTHOSTSYSTEM%\Content\TMurgent_ATM_V3\Tattoo.exe C:\Windows\Temp\MachineScript_Publish.txt</Arguments>
        <Wait RollbackOnError="true" Timeout="30"/>
    </PublishPackage>

    <UnpublishPackage>
        <Path>ScriptLauncher.exe</Path>
        <Arguments>\\%SCRIPTHOSTSYSTEM%\Content\TMurgent_ATM_V3\Tattoo.exe %TEMP%\MachineScript_Unpublish.txt</Arguments>
        <Wait RollbackOnError="false" Timeout="30"/>
    </UnpublishPackage>

    <AddPackage>
        <Path>C:\Windows\ScriptLauncher.exe</Path>
        <Arguments>\\%SCRIPTHOSTSYSTEM%\Content\TMurgent_ATM_V3\Tattoo.exe $TEMP\MachineScript_AddPackage.txt </Arguments>
        <Wait RollbackOnError="true" Timeout="30"/>
    </AddPackage>

    <RemovePackage>
        <Path>C:\Windows\ScriptLauncher.exe</Path>
        <Arguments>\\%SCRIPTHOSTSYSTEM%\Content\TMurgent_ATM_V3\Tattoo.exe %TEMP\MachineScript_Remove.txt </Arguments>
        <Wait RollbackOnError="false" Timeout="60"/>
    </RemovePackage>
</MachineScripts>
 

Example of injecting a file into the virtual environment:

A common use of this tool is to inject a file into the virtual environment that has a relationship to the user.  Licensing solutions often require this.

  • In the App-V Sequence Editor, add ScriptLauncher.exe into the package "Scripts" folder.  You must copy ScriptLauncher.exe somewhere on the disk partition as is being sequenced (such as to the desktop).  You can do this before or after monitoring mode.  Then right click on the Scripts folder on the Package Files tab and import the file.
  • Edit the xml for the script.  In App-V 5.1 and above, this is best done while in the sequence editor.  Export the AppXManifest.xml file and use AVME (the AppVManifestEditor tool also available on this site) to add the script. 
  • Use the "Start of Virtual Environment" script.  Select "Run in Virtual Environment" checkbox, and the "Wait" checkbox.
  • Make the Path be "[{AppVPackageRoot}]\..\Scripts\ScriptLauncher.exe"
  • Use the %EffectiveUserName% argument to get the real user name.  for example, the argument might be:

C:\Windows\Cmd.exe /C copy "\\ProfileServer\Share\%EffectiveUserName%\Licenses\ProgramName.ext"[{ProgramFilesX86}]\Vendor\Subfolder\ActualLicenseFilename.ext"

  •  Save the edited manifest file and import back into the sequence. 

Notes:

Some Notes about the Config.xml Path element...

  • In the Config.xml files, the value of the "Path" element must be an exe file. This value must NOT have any white space, either before, after, or in-between or the App-V script engine will fail. You may not place in in quotation marks either. You may not use environment variables in the Path.
  • You may reference the complete file path to the exe (keeping in mind the rules above), or you may just reference the file if it is either in the current working directory or the PATH variable.
  • Strangely, when using the stand-alone client, the current working directory for the script appears to be the folder from which the client source for the .AppV file is loaded. So for stand-alone client use, this means it is possible to place ScriptLauncher.exe in the share folder containing the APPV file instead of on the client. Credit goes to Kim for finding this! Unfortunately, this current working directory quirk will not work if you delivered the package via the App-V Management server or SCCM.

Some Notes about the Config.xml Arguments element...

  • You may enclose the environment variable in the value of the Arguments element only, and then ONLY if you use ScriptLauncher in the Path element.!
  • The Arguments may then have environment variables including % characters, use a leading $ character, or even a leading % without the trailing one. When you don't enclose in two % characters, a space or backslash will be considered to be the terminator of the environment variable name.
  • You can have multiple environment variables in a single Arguments element, but only one environment variable per "parameter" within that element.

Some Notes about problems Scriptlauncher doesn't address...

  • ScriptLauncher does not affect the value of the environment variables (except for EffectiveUserName). USERNAME is still the computer account.
  • ScriptLauncher does not affect the double run UAC issue.

What does ScriptLauncher cost?

TMurgent believes in giving back to the community.   ScriptLauncher is free for for use./p>

What OSs will it run on?

Anywhere the App-V Client works.

Are there more free tools?

TMurgent has a bunch of tools on this page.

What is in the latest updates to the tool?

Version 1.3.0.0

  • Update Release. Previous release added quotation marks around all arguments that didn't have any. Now only add quotation marks around arguments if the argument includes a space.

Version 1.2.0.0

  • Update Release. Added %EffectiveUserName% and better argument handling.

Version 1.0.0.0

  • Initial Release.

 

Here is the ZIP package:    Compressed copy of the tool  (28kb)