Using PowerShell, VBScript and KiXtart with FastTrack

In an ideal world, you only need one scripting technology such as FastTrack or PowerShell. But in the real world, you might need to mix technologies for various reasons. It could be that you have a lot of existing scripts based on one technology that you cannot just convert in one iteration. It could also be that you find or have a complex script snippet that you simply can't convert. Or you might want to include features only available in another language, such as using the FastTrack SyncDir command in a PowerShell script.

We will go through how to call PowerShell, VBScript and KiXtart scripts from FastTrack and vice versa. We will also demonstrate how to pass exit codes and data from the called scripting language to the calling one.

Embedding other scripting languages

Calling an external script from a FastTrack script

When calling a PowerShell, VBScript or KiXtart script from a FastTrack script, you can use the "Run" command to call the script and wait for it to complete. We will refer to any non-FastTrack script as an "External script" from here on. Below an example of embedding one of each:
Calling a PowerShell script

Run PowerShell.exe,-ExecutionPolicy Bypass -file MyPSFile.ps1

Calling a VBScript script


Run WScript.exe,MyVBSFile.vbs

Calling a KiXtart script

Run WKIX32.EXE,MyKixFile.kix

Note that for calling VBScript, the environment variable SEE_MASK_NOZONECHECKS is set to 1. This will disable the security warning, as described in KB889815. The use of the command SetProcessEnvVar (instead of SetEnvVar) will set the variable only for the current process to avoid disabling the security warnings in general. You will only see the security warning, if the script you are calling is located on a network share.

Passing a return code from an external script

When calling an external script from a FastTrack script, you can pass a standard Windows return/exit code from the called script to the calling FastTrack script. This is useful for reporting, if there were any problems with the execution or for controlling next action. You can use any number you want as return code, but you can only pass a number and not a string. In the three examples below, we use the return code 200 to tell the FastTrack script that a certain condition was met. The three external scripts are of course supposed to be longer than just one line and must end with the displayed line to stop the execution and pass the return code, which is 200 in these cases.
FastTrack script

Run PowerShell.exe,-ExecutionPolicy Bypass -file MyPSFile.ps1

If [LastExitCode]=200 Then

  ''...Do something...

End If


PowerShell script (MyPSFile.ps1)
exit 200
FastTrack script


Run WScript.exe,MyVBSFile.vbs

If [LastExitCode]=200 Then

  ''...Do something...

End If

VBScript script (MyVBSFile.vbs)
WScript.Quit 200
FastTrack script

Run WKIX32.EXE,MyKixFile.kix

If [LastExitCode]=200 Then

  ''...Do something...

End If


VBScript script (MyKixFile.kix)
exit 200
Note that if you do not return an exit code with PowerShell, the script will return 0 when there are no errors and 1 if an unhandled exception is thrown. FastTrack does the same.

Passing complex data to a FastTrack script

If you need to pass more complex data, you need to place the data in a temporary storage. This could be a text file, an xml file, the registry, environment variables, etc. In this example we will use the registry as this is the most reliable choice. Let us use a concrete example. Suppose we would like to upload the operating system serial number and product key to SkyBox (see here for more information about SkyBox). The serial number we can retrieve with a single and simple WMI call from a FastTrack Script. But the product key is a different matter entirely, as this is not something you are supposed to be able to get back. It is encoded in the registry, presumably to avoid having people decoding and re-using it. If you Google the subject, there are people that have figured out how to decode the product key. The below VBScript example is found by a Google search. We will make one modification to the script we found, which is writing the decoded string to a temporary registry key. This is the italic line below. Our VBScript part looks like this:
Extracting the Windows Product Key with VBScript
Set WshShell = CreateObject("wscript.Shell")
strXPKey = GetKey(WshShell.RegRead("HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DigitalProductId"))
WshShell.RegWrite "HKEY_CURRENT_USER\Software\Temp\OSSerial",strXPKey

Function GetKey(rpk)
  Const rpkOffset=52:i=28

    dwAccumulator=0 : j=14
      rpk(j+rpkOffset)=(dwAccumulator\24) and 255
      dwAccumulator=dwAccumulator Mod 24
    Loop While j>=0
    i=i-1 : szProductKey=mid(szPossibleChars,dwAccumulator+1,1)&szProductKey
    if (((29-i) Mod 6)=0) and (i<>-1) then
      i=i-1 : szProductKey="-"&szProductKey
    End If
  Loop While i>=0
End Function
If we just execute the script and look in the registry, we have now decoded the product key to the temporary registry location HKEY_CURRENT_USER\SOFTWARE\Temp:


Suppose we saved the above script as "DigitalProductID.vbs" in the same directory as our logon script, all we need to do to achieve the goal is this:
FastTrack script to use the external VBScript snippet


Run WScript.exe,DigitalProductID.vbs

Set OSProductKey=[RegistryValue HKCU\SOFTWARE\Temp\OSSerial]

DeleteRegistryKey HKCU\SOFTWARE\Temp

Set OSSerialNo = [WMIQuery Select SerialNumber FROM Win32_OperatingSystem]

UploadInventory [Var OSSerialNo],[Var OSProductKey]

Note that the fourth line cleans up the registry. If we now look up a machine that has executed the above script snippet, we now have the information available in SkyBox, as shown below (actual values replaced by fictitious values). We can now extract all product keys from all computers in SkyBox to verify licenses.

Inventory with OS Serial no and Product key

If we wanted to pass data the same way from a called PowerShell or KiXtart script, we can do this the same way by writing data to the temporary registry location "HKEY_CURRENT_USER\Software\Temp" (or another temporary location you decide under HKEY_CURRENT_USER) as listed below, where we are just passing "Acme" in a registry value called "Name":
Writing Registry values with PowerShell
New-Item -Path "HKCU:\Software\Temp"
Set-ItemProperty -path "HKCU:\Software\Temp" -name "Name" -value "Acme"
Writing Registry values with KiXtart
WriteValue("HKCU\Software\Temp", "Name", "Acme", "REG_SZ")

Calling a FastTrack script from other scripting languages

Let's flip the coin and look at the world from the other side. Suppose we have a preference for using one of the other scripting technologies, then we might still want to use some FastTrack commands. This could for example be to backup files with SyncDir from a PowerShell, VBScript or KiXtart logon script. If we are going to do this on a larger scale, it might be a good idea to simply place a copy of FSH.Exe and FSH.Lic and script files in a directory and call FSH.exe with the script file as the only parameter. If we are only going to use one or two such scripts, it is easiest to simply compile temp into exe files and use them as any other external tool. Below a script line to back up users documents and the script editor button to compile the script into an exe file.

SyncDir [UserDocumentsDir],[UserHomeDrive]\Backup

Compiling a shell exe

Passing data from a FastTrack script to another scripting language works the same way as passing data to a FastTrack script. For return codes, FastTrack works the same way as PowerShell. If a script fails, it will by default return 1 and 0 on success. You can specify a different return/exit code with the "Exit" command. If you need to pass complex data, you can use the "WriteRegistry" command to set registry keys that you can then read from the other language.

Rating: 5 out of 5

"Use this as a replacement for VBScript and PowerShell"

"It's easy to include attractive GUI elements in FastTrack scripts, beyond the basic dialog boxes and text input that VBScript offers ... Another powerful feature is the ability to distribute scripts as Windows Installer (.msi) or standard .exe files. Although interesting in its own right, this ability results in a much more intriguing capability: to repackage -- or wrap -- software installers as .msi files without using snapshots. If you've ever created an .msi installer file from before-and-after system snapshots, for use with a software distribution system such as Group Policy or SCCM, then you know how hit-and-miss the results can be."

Read full review

Rating: 8 out of 10

"Faster than the rest"

"We found the FastTrack syntax to be more transparent and easier to learn than Microsoft's PowerShell – the editor in particular provided good support in this regard. the Script Editor offers a large number of options from the command set through to simple output of graphical elements, which cannot be achieved at all with PowerShell or other solutions or only with a significantly greater level of effort."

"Anyone wanting to tackle the many hurdles in everyday admin and especially anyone for whom logon scripts and client automation is a priority will benefit from the variety of functions offered by FastTrack."

Review in English      Review in German