← Using the PowerShell Definition TypeUsing the CMD Definition Type →

Using the Visual Basic Script Definition Type

The Microsoft Windows VBScript (VBS) language is a variation of Visual Basic, and is very suited for writing scripts. The cscript command-line interpreter is available on all recent Microsoft Windows server operating systems.

note

You must assign at least one process server to run VBS process definitions in order to use the 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/64-bit

By default, the 32-bit versions of the interpreters are used on Windows platforms, this can be changed using the following:

  • JCS_INTERPRETER_VBSCRIPT - parameter used to override default, can be set to C:/Windows/Sysnative/cscript.exe for 64-bit; default when non-existent or empty and process server parameter LocalInterpreter_VBSCRIPT not set: C:/Windows/System32/cscript.exe
  • InterpreterWhitelist_VBSCRIPT - process server parameter that takes a regex 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 also explicitly set two separated by a comma without space (regex syntax): C:/Windows/Sysnative/cscript.exe,C:/Windows/System32/cscript.exe
  • LocalInterpreter_VBSCRIPT - process server parameter used to set default to 64-bit, can be set to C:/Windows/Sysnative/cscript.exe for 64-bit; affects all processes for the process server that do not have JCS_INTERPRETER_VBSCRIPT set, default or when not set: C:/Windows/System32/cscript.exe
  • LocalInterpreterBits - Set this key to 64 and all Windows platform agents will use 64-Bit interpreters.
note

Remember that on 64-bit Windows platforms the System32 directory contains 64-bit binaries and SYSWOW64 is the directory containing 32-bit binaries.

note

In Windows 64-bit, you have to explicitly call the 32-bit binaries to access C:\\Windows\\Sysnative; the path does not exist for 64-bit applications.

Supported VBScript Syntaxes

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 of the Script 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, it is mandatory for Redwood Server. Furthermore, each tag must be on a separate line. WSF support allows you to mix JavaScript, VBScript, Perl, and Python code in one definition.

Note that 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 use the 32-Bit version of cmd.exe or powershell.exe to test the 32-Bit interpreters with cscript.exe.

<?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 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 that has its environment properly set up, environment variables such as PYTHONPATH.

The ActiveState Perl and Python interpreters are recommended.

The following PowerShell script installed the necessary modules for Python WSF support on our systems; note that an Internet connection is required to download the modules.

#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, you use the {session} or {console} keywords in the Run As User field followed by the credential or username and password.

  • {session} - RDP or Windows Terminal Server session
  • {console} - 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:

Specifying a Run As User field with {session} and virtual user

{session}{virtual}:ops

Specifying a Run As User field with {console} and credential

{console}example@example.corp

Variables and Parameters

  • Parameters to the process definition are manipulated in the VBScript source simply as if they are variables, using the standard syntax.
  • The VBScript language has knowledge of data-types. The String and Number data-types are supported. DateTimeZone parameters are stored in string variables.
  • Out parameters are supported by setting the global variable with the same name as the parameter to the desired value.

Returning an Error

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

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

Examples

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

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

The following 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:

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

Raising an error and clearing it so the process reaches Completed

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

The following example illustrates how to run a VBScript file in 64-bit mode (using CMD definition type )

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 and 64-bit.

The following code allows you to determine the Bitness

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)"

See Also

← Using the PowerShell Definition TypeUsing the CMD Definition Type →