Using the VBScript Definition Type

The Windows VBScript language is a variation of Visual Basic. The cscript command-line interpreter is available on all recent Windows server operating systems.

Note: You must assign at least one Process Server to run VBS Process Definitions in order to use the VBS Definition Type.

Note: By default, the 32-bit version of cscript.exe is used to execute VBScript processes, to use the 64-bit version, you use a CMD Process Definitions and call the script from there. See example below. You can also set the Platform Agent to run in 64-Bit mode using the LocalInterpreter registry entry or set all to run in 64-Bit with the LocalInterpreterBits registry entry.

32-Bit and 64-Bit Interpreters

By default, the 32-bit versions of the interpreters are used on Windows platforms. However, you can change this.

  • JCS_INTERPRETER_VBSCRIPT:A parameter used to override the default interpreter. This value can be set to C:/Windows/Sysnative/cscript.exe for a 64-bit interpreter. The default value if the Process Server parameter LocalInterpreter_VBSCRIPT is not set is C:/Windows/System32/cscript.exe.
  • InterpreterWhitelist_VBSCRIPT: A Process Server parameter that takes a regular expression matching all interpreters you want supported. Use .* to allow any, or C:/Windows/.*/cscript.exe} to allow any cscript.exe in a subfolder of C:/Windows. You can explicitly set two interpreters, separated by a comma without space, like so: C:/Windows/Sysnative/cscript.exe,C:/Windows/System32/cscript.exe.
  • LocalInterpreter_VBSCRIPT: A Process Server parameter used to set the default interpreter to 64-bit. Set this to C:/Windows/Sysnative/cscript.exe for a 64-bit intepreter. This setting affects all processes for the Process Server that do not have JCS_INTERPRETER_VBSCRIPT set. The default value is C:/Windows/System32/cscript.exe.
  • LocalInterpreterBits: If you set this key to 64, all Windows Platform Agents will use 64-bit interpreters.

Note: On 64-bit Windows platforms, the System32 directory contains 64-bit binaries, and the SYSWOW64 directory contains 32-bit binaries.

Note: On Windows 64-bit platforms, you must explicitly call the 32-bit binaries to access C:\\Windows\\Sysnative. The path does not exist for 64-bit applications.

Supported VBScript Syntaxes

WSF support allows you to mix JavaScript, VBScript, Perl, and Python code in one definition. The VBScript Definition Type supports VBScript code (such as you would write in a .vbs file) as well as XML markup (as you would specify in a .wsf file). To use the WSF capability, the first character in the Source field must be a < character.

The XML processing instruction <?XML Version="1.0" encoding="ISO-8859-1"?> must be on the first line in the Source field. This is not mandatory for cscript.exe, but it is mandatory for RunMyJobs. Also, each tag must be on a separate line.

Note: Perl and/or Python must be correctly installed and configured for WSF before they can be used. Remember that the Platform Agent runs in 32-Bit mode by default. You need the 32-Bit Perl and/or Python interpreters if you do not wish to switch the Platform Agent to 64-Bit. You can use the 32-Bit version of cmd.exe or powershell.exe to test the 32-bit interpreters with cscript.exe.

Copy
<?XML Version="1.0" encoding="ISO-8859-1"?>
<?job error="true" debug="false"?>
<package>
        <job>
        <script language="JScript" src="c:\myScripts\myScript.js" />
        <script language="VBScript">
        <![CDATA[
public sub println(strText)
        wscript.echo strText & " (from vbs)"
end sub
dim Test
Test= "One, Two"
        ]]>
        </script>
        <script language="Python">
        <![CDATA[
import sys
globals.println('python can read Test variable defined in VBScript:' + globals.Test)
        ]]>
        </script>
        </job>
</package>

The ActiveState Perl interpreter installed WSF support as part of its installation. The ActiveState Python interpreter needed additional modules.

Installing a Python Interpreter with WSF Support

Note: These installation instructions are provided for your convenience. No further support for the installation of Perl and/or Python interpreters will be provided. Redwood will support Perl and Python WSF scripts if they work in cscript.exe and the above mentioned syntax (XML processing instruction on first line, each tag on its own line) are adhered to. Note that processes must run as a user whose environment is properly set up with environment variables such as PYTHONPATH.

Redwood recommends the ActiveState Perl and Python interpreters.

The following PowerShell script installs the necessary modules for Python WSF support in RunMyJobs.

Copy
#Requires -RunAsAdministrator

if ( (Get-Command python -ErrorAction SilentlyContinue).Source -match "python")
{

python -m pip install pywin32
python -m pip install setuptools

$PYTH_DIR= $(split-path -parent (get-command python).Source)

python  $PYTH_DIR/scripts/pywin32_postinstall.py -install
} else {
write-host "Please ensure Python is installed and on your path"
}

Background and Foreground Processes

By default, commands are executed in the background. You will not see any dialog in the server. If you want to display a process on-screen, use the {session} or {console} keywords in the Run As User field, followed by the credential or username and password.

  • {session}: An RDP or Windows Terminal Server session.
  • {console}: A console session. A console session is displayed on the physical monitor screen attached to the server.

Note: The specified user must be logged in to a console session (for {console}) or any type of the supported sessions (for {session}), or the process linked to the process will reach status Error.

Examples

This example shows how to specify a Run As User field with {session} and a virtual user.

Copy
{session}{virtual}:ops

This example shows how to specify a Run As User field with {console} and a credential.

Copy
{console}example@example.corp

Variables and Parameters

You can manipulate Process Definition parameters as variables, using standard VBScript syntax.

The String and Number data types are supported. DateTimeZone parameters are stored in string variables.

To set an Out parameter, set a global variable with the same name as the parameter to the desired value.

Returning an Error

If your script needs to set a non-zero exit code, you can code Wscript.Quit(n) as you normally wold. This is correctly reflected in the server, and as of 9.0.17 it will also set Out parameters.

Your script should start with error handling set to abort execution. When a runtime error occurs, the process will fail with Error and s return code indicating the Err.Number value. If you handle errors using the resume next statement, make sure the error is cleared after you have handled it, or at least before the script ends. If your script completes and you have not called Wscript.Quit, and the Err object has not been reset, the script will end in the Error status.

Examples

This example shows how to pass numeric (N1), string (S1) and date (D1) parameters to and from VBS processes:

Copy
N1 = N1 + N1
S1 = S1 & S1
DTEMP = "1999/12/31 23:59:59Z"
Wscript.stdout.writeline "You said " & D1 & ", I propose " & DTEMP
D1 = DTEMP

This example shows you how to return a non-zero exit code resulting in the process going into Error, as well as setting any output variables:

Copy
N = 1
Wscript.stdout.writeline "Exiting with value " & N
Quit N

This example demonstrates raising an error and clearing it so the process can reach Completed status.

Copy
On error resume next
Err.Raise 8
Err.Description = "Example Custom Error"
Err.Source = "MSLN_ErrorHandler"
Wscript.echo("An Error of the type " & Err.Description & " has been caused by " & Err.Source & ".")
Err.Clear

This example shows how to run a VBScript file in 64-bit mode using the CMD Definition Type.

Copy
rem Call 64 bit cscript if in 32 bit mode and 64 bit exists
if exist "%systemroot%\sysnative\cscript.exe" (
  "%systemroot%\sysnative\cscript.exe" <arguments>
) else (
  "%systemroot%\system32\cscript.exe" <arguments>
)

Note that %systemroot%\sysnative is only available on 64-bit versions of Windows when the 32-bit version of cmd.exe is run. This example should run fine on all supported versions of Windows, 32-bit and 64-bit.

Determining Interpreter Architecture

This example shows how to determine if the system is 32-bit or 64-bit.

Copy
Wscript.echo "Windows:" &VbTab& VbTab& GetObject("winmgmts:root\cimv2:Win32_Processor='cpu0'").AddressWidth
Wscript.echo "Hardware:" &VbTab& VbTab& GetObject("winmgmts:root\cimv2:Win32_Processor='cpu0'").DataWidth

'Not very reliable
Wscript.echo "Process:" &VbTab& VbTab& CreateObject("WScript.Shell").Environment("Process")("PROCESSOR_ARCHITECTURE") & VbCrLF & "(x86 => 32Bit, other =>64Bit)"