ScriptLauncher: A Client Helper Tool for App-V 5
Version 1.2.0 June 19, 2013
Download links and version changes at the bottom of this page.
| |
ScriptLauncher is a free tool designed to make it easier to use scripts on Microsoft App-V 5 virtual application package thats require 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 environemt, 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:
- USERNAME points to computername$
- USERPROFILE points to C:\windows\system32\config\systemprofile
- 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>
|
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 environemt 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 EffectivUuserName). 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. Usually they are free, unless you are a Software Vendor.
Tools for performance have a segregated list here.
What is in the latest updates to the tool?
Version 1.2.0.0
- Update Release. Added %EffectiveUserName% and better argument handling.
Version 1.0.0.0
Where Can I download it?
Here is the ZIP package:
Compressed copy of the tool (28kb)