App-V 5.1 ScriptRunner


Gears turning, one gear is redOne of the major improvements included in App-V 5.1 is the improved handling of scripts used with App-V Packages. The change from 4.6 to 5.0 scripting was a difficult transition for many. Microsoft Consultant, Steve Thomas, pointed out in his article on scripting, "It is almost easier to pretend you know nothing about App-V 4.x scripting when looking at scripting in 5.0."  With the ScriptRunner.exe included with installation of the App-V 5.1 client, the capability and ease of running scripts has become vastly easier and flexible.

NOTE: The 5.1 Client is backwards compatible with any 5.0 scripting.  There is no need to update your configuration XML files or scripts in order to run on the App-V 5.1 client.

SCRIPTRUNNER FEATURES

  • ScriptRunner.exe is a new exe as part of AppV Client
  • Script type is not limited to an executable.
    • Essentially, it can be anything that can be run from the "RUN" command in the start menu:
      • .EXE
      • .PS1
      • .BAT
      • .TXT
      • .CMD
      • .VBS
      • and more!

  • Execution of multiple scripts
  • Scripts running as non-admin work
    • No longer fails as an API call requiring Admin privileges
  • Environment variables handled within scripts, not arguments for scripts

MULTIPLE SCRIPT SUPPORT

Multiple scripts are passed as arguments to ScriptRunner.exe and each script is executed in the order provided in the XML. Although the scripts are executed in order, the scripts may end up running concurrently if the "-wait" parameter is not specified. Each script is launched in a separate process, using Process.Start(). If it is important that one script completes before another executes, the "-wait" should definitely be used. Any parameters applied are per individual script and use "-AppVScriptRunnerParameters" as the delimiter to set those values. 

  • If a script specifies the wait/timeout/rollback options, it will be applied explicitly for that script.
  • If a script does notspecify the wait/timeout/rollback option, default values are be used: no wait, no timeout, no rollbackonerror.
  • The wait/timeout/rollbackonerror values specified as a separate node applies to the parent “ScriptRunner.exe” process, and not to the individual scripts.

New Scriptrunner format xmlOld scripting format xml

Although the examples above show MachineScripts, ScriptRunner.exe can be used for both MachineScripts and UserScripts.  Additionally, ScriptRunner.exe can be used for both the UserConfig.xml and the DeploymentConfig.xml.

These eight triggers can be used for both the MachineScripts and the UserScripts:

  • <AddPackage>
  • <RemovePackage>
  • <PublishPackage>
  • <UnpublishPackage>
  •  <StartProcess>
  • <ExitProcess>
  • <StartVirtualEnvironment>
  • <TerminateVirtualEnvironment>

Scriptrunner triggers xml

ERROR HANDLING

Any scripts and parameters used with ScriptRunner.exe is that they are they are tested in the Console and any errors corrected before everything is committed to the DeploymentConfig.xml or the UserConfig.xml.  Any errors and messages are displayed in the Console.

The AppV>Operational Event log on the Client will record the following:

  • Error in input parameters to ScriptRunner.exe
  • Error in the actual script, no "rollbackonerror" setfor script that failed, execution continues and will eventually report success.
  • Error in the actual script, "rollbackonerror" set for script that failed, execution stops and error recorded

Comments (3)

  1. Roy Essers says:

    Great article, one this to note:
    On a x64 platform, I’ve tried to run a x64 powershell like:

    SCRIPTRUNNER.EXE
    -appvscript %windir%System32WindowsPowerShellv1.0powershell.exe -NonInteractive -ExecutionPolicy RemoteSigned -File Publish.ps1 -appvscriptrunnerparameters -wait -timeout=120 -rollbackonerror

    This will not work. Troubleshooting the script gave the following error: "The current processor architecture is: x86.". It appears that the execution environment from scriptrunner is 32-bit, and therefore launches the x86 version of Powershell. I’ve solved
    this issue by pointing to %windir%Sysnative instead of %windir%System32. Final script:

    SCRIPTRUNNER.EXE
    -appvscript %windir%SysnativeWindowsPowerShellv1.0powershell.exe -NonInteractive -ExecutionPolicy RemoteSigned -File Publish.ps1 -appvscriptrunnerparameters -wait -timeout=120 -rollbackonerror

  2. Steve Bucci says:

    Nice catch, Roy, and thanks for sharing it with everyone.

Skip to main content