Getting Started Quick Guide

FastTrack is a scripting language and is currently the only real high-level scripting language. Using all other scripting languages, you do a lot of time consuming plumbing to accomplish things and the complexity of this alone prohibits you from doing a lot of things you would like to do. Most other commonly used scripting languages are very close to programming languages and many of them are in fact the counterparts of real programming languages, like VBScript. This means that you need programming skills to script and often you find yourself using other people's snippets you find on the internet. It is very difficult to script complex things even for a programmer and most places you won't find a programmer in the systems administrators department.

FastTrack is completely different. It is essentially a gigantic toolbox and the paradigm is: one operation - one script line. If you need to synchronize files from one directory to another you write one line in your script and FastTrack shows the user a friendly GUI while doing it. This of course triggers hundreds of real codes lines in the engine, but you don't write the code to actually execute the operation, you just specify what you want to accomplish. This means, that if you have a relatively large WSH logon script today, you will be amazed how few script lines you need to do the same with FastTrack. And on top of that your scripts will be far more readable and you wrote all of it yourself instead of relying on other people's snippets or even consultants. If you have consultants this is the place they don't want you to know about. Anyone with IT understanding can write a FastTrack script that does complex things, so now you can use your energy one what you want done instead of how and who you want to do it.

The editor

To write script, first of all you must download and install the setup package. Start the editor from the "FSH Script Editor" icon. It looks like this:


First time you start the editor, a demo script is opened. Try running it with F5 from the editor, which will execute a small demo script. The script is not very useful, but the point is that it is all done in just a few simple script lines. You can also press F6 and run a script in debug mode. Running in debug mode allows you to step through the script and see exactly how the script is parsed at runtime.

The "Engine Browser" tree shows all commands, functions, collections and conditions. When an item is marked in the tree, the "Context Helper" shows a full explanation of the selected item. If you for instance need to execute a program, you locate the "Run" command in the tree and double-click it to insert it into your script at the cursor position (or drag it into the script). A property builder is opened to help you create the correct parameters.


The editor automatically highlights commands, functions, collections, conditions and loops (which are all explained further down this page). When you move around your script, the editor senses what you do and if the cursor is on one of the highlighted items, it automatically displays an explanation in the "Context Helper" panel. This happens completely on-the-fly as you type letters or move around in the script. As you type, the case will also automatically be corrected. If you type the command "splash", it will automatically be corrected to "Splash" (with a capital S). The editor also has code completion. In the above screen dump, "co" was typed, and 5 commands are suggested.

You can disable the property builder, if you prefer to write the parameters directly in the script. If you do, a template is copied into the script instead. You will most likely find that in the beginning, you use the property builder, but as you get familiar with command, functions, etc, you will write the scripts directly with aid from the code completion. A small tip on finding a command: When you write a new line, you can press space to open a full code completion window. When you select a command, the space is removed.

To ensure script quality, a script validator is build into the editor. When you save or execute a script, a simulated run is performed to validate if there are any syntactical errors in your script, like a missing parameter. If the script cannot pass a simulated run, you will be notified of what line is the problem. This means that you cannot save or execute an invalid script, unless you uncheck the "Validate Before Save" setting.

The editor is completely customizable. You can change the skin and move the panels around like in Visual Studio. This is the same editor where a panel is dragged:


Writing scripts

FastTrack scripts generally consists of 5 types: Commands, functions, collections, conditions and loops.

Commands

A command is an operation that "does something", like performing a file operation, connecting a share, etc. Everything else is basically there to support the commands. Click here for a complete list of current commands.

Functions

A function is notated with square brackets, like [UserFullName] and is replaced by what the function does. In this case it would be replaced by the currently logged on users name. Click here for a complete list of current functions. Think of a function as a textual replacement before commands, conditions and loops are executed. A command will see the replaced function value when it executes. Functions can have parameters for instance [Var Server], which returns the content of a variable named "Server". You can use functions inside functions like [UserFullName [Var user]]. The next example demonstrates use of functions.

Collections

A collection is essentially the same as a function, except that it returns a comma separated list of values instead of just one value. This means that a collection is the same format as a list of parameters, making collections very useful for loops or menus. The example in the loops section below demonstrates the use of it. Click here for a complete list of current collections.

If-statements with Conditions

A condition is used with an if-statement. If the condition is true, the inner code is executed, otherwise not. You can always specify "not" after if for the opposite result. A condition consists of "IF.....Then" and has to have en ending line "end if" and optionally have an "Else" in between. If there is just one command that has to be executed if the condition is true, it can be specified after "Then". In that case there can be no else or end if attached to it. An example of a conditional if-statement in one line can be seen in line 4 in the next example. Click here for a complete list of current conditions for if-statements.

If-statements with operators

If statements can also be used without conditions. You can use the operators <, > and =. For "not equal to", you use the = operator and "not" after "If". When they are used the engine simply compares the results on both sides of the operator, like in example with IPAddressPart below.

This example is script in the Startup folder of a computer which determines if it is at home or at work, which uses all of the above "If" constructs:

SmallSplash "Connecting, please wait..."

DisconnectAllShares

If [IPAddressPart 3]=192.168.1 Then

  If Alive MyHomeServer Then ConnectShare O:,\\MyHomeServer\D$

  SetPrinterDefault \\MyHomeServer\HomePrinter

Else

  If Not ProcessRunning outlook Then LaunchMin [ProgramFilesDir]\Microsoft Office\Office12\OUTLOOK.EXE

  SetPrinterDefault \\ACMESERVER\PRT012

End If 

If-statements with multiple conditions

Regular AND and OR operators are possible as shown below where a documents backup is performed, if the computer is a portable computer and it is running on A/C.

If Portable And Not RunningOnBatteries Then SyncDir [UserDocumentsDir],[UserHomeDir]\DocumentsBackup

Loops

Loops are just means to iterate through collections, which has to be ended with "End Loop". The first parameter is always the name of variable you choose which contains the actual value inside the loop. This example synchronizes a data directory to all citrix servers in a farm:

Loop Server,[CitrixServers]

  SyncDir C:\Data,\\[Var Server]\d$\Data

End Loop

Parameters

Parameters are always separated by commas and can optionally be written inside quotes. This means that if a parameter itself contains a comma, the parameter must be quoted. Take a look at this example:

If [FreeDiskSpace]<5 Then ShowMessage "Your harddrive space is too low, contact HelpDesk",Error

If the first parameter was not quoted, the engine would have considered the first parameter as two parameters, yielding a "too many parameters" error from ShowMessage. You don't have to use quotes in general, but remember that you must quote anything that may contain commas. Also remember that a function that may return something with comma must also be quoted.

Variables

A variable is defined with the command "SetVar" and retrieved again with the function "Var". This example would present a menu with the names of all local groups and put the selected one into the variable "Group". The second line would display the content of the variable "Group" in a messagebox:

SetVar Group,[Menu Select a group,[LocalGroups]]<br />

ShowMessage [Var Group],You selected

Escape

Functions and collections are residing inside square brackets, [ and ]. You will most likely never experience it, but if you in fact need the bracket characters themselves for for instance writing a registry value that contains them, you must use the char function. The [Char 91] function will produce a start bracket char and [Char 93] will produce an end bracket char.

Comments

Comments can be used anywhere, and is noted as ''. Anything beyond it on a line is considered a comment. Block comments must start with /* and end with */.

Labels

Any line that starts with a colon is considered a variable. In most other scripting and programming languages, labels cannot contain spaces for parsing reasons. This is not the case with FastTrack scripts, labels can in fact contain spaces. The reason for this is that in almost any case you would need goto, spaces will be involved. Take a look at this example which is a menu to easily synchronize data to a selectable server:

SetVar Selected,[Menu Select operation,Replicate to Server 1,Replicate to Server 2,Replicate to Server 3]

If Not [Var Selected]= Then Goto [Var Selected]

Exit

 

:Replicate to Server 1

SyncDir C:\Data,\\Acme\Server1\Data

Exit

 

:Replicate to Server 2

SyncDir C:\Data,\\Acme\Server2\Data

Exit

 

:Replicate to Server 3

SyncDir C:\Data,\\Acme\Server3\Data

Exit

Embedding other scripting languages

If you have a script written in another scripting language that you want to include within your FastTrack Script, you can simply issue a Run command. The Run command uses shell execution, meaning that you do not need to specify the executable to handle a specific file type, if there is already an association to the specific scripting type.

If you need to hand over a status from the embedded script, or an executable, you can facilitate exit codes. In VBScript, you can optionally supply an exit code to VBScript.Quit like this:
WScript.Quit(200)
Inside your FastTrack Script your then read this status by using the LastExitCode function:

Run AcmeScript.vbs

If [LastExitCode]=200 Then

  ''...Do something...

End If

Running scripts outside the editor

To run scripts outside the editor on your own machine, you simply double-click the saved fsh file and it gets executed. This will just pass the script file as the only parameter to the fsh.exe file, which is the only file you need to execute a script. But most likely the actual use of the script is on other machines than the one you created the scripts on. To execute a script on another machine you need nothing but the fsh.exe file from the installation directory on the target machine. Just pass the script as the only parameter like this:
FSH.Exe MyScript.fsh
To see the command line options, just start the "Language reference" icon in the start menu and look at the last tab. If you have a license, you must put a copy of you fsh.lic file in the same directory as the fsh.exe to avoid the trial window. You may also optionally copy an error handler and/or a post installation script with the exe file, this is described later in the article. Note that FastTrack cannot run directly off a network unless you grant the intranet zone full rights on the machine.

For distributing to all clients in a network, we highly recommend you use the free FastTrack Logon. It will automatically distribute the engine and logon scripts to all clients seamlessly. See the logonscript menu for details.

Error handling

Error handling is essential in any script or program and you can decide how you want it handled. If there is a file called "ErrorHandler.fsh" in the same directory as the engine (fsh.exe), it gets executed when a fault happens. You should especially use it with FastTrack Logon. Creating this single line in ErrorHandler.fsh with FastTrack Logon:

AppendFile \\AcmeServer\ITShare\NetworkErrors.log,"[Date],[Time],[Username],[LastError]"

...will append all execution errors on the entire network to the file. Consider the amazing overview you would get as a systems administrator, all errors on all machines logged in a single file!

The engine has two parameters related to the way faults are handled. In general there is a distinction between runtime errors and script errors. Script errors (malformed script like a wrongly spelled command) by default stop the script execution entirely and shows the error to the user, but runs the error handler script. Runtime errors (like users full name cannot be retrieved because a domain controller cannot be reached) also by default stops execution and runs the error handler. But you can decide a different behavior with command-line parameters. If you specify /ie, runtime errors will not stop the execution and every time a runtime error occurs the error handler script is executed. If you use this switch, all functions will return a blank string if it fails and conditions are not entered if the condition fails. You can also ignore script faults with /if, but this is not recommended because you might never find out that your script is malformed. FastTrack Logon executes logonscripts with /ie to ensure full execution. If you used the line above, you will know what fails instead of showing it to user. The execeution of the ErrorHandler.fsh is a bit blindfolded. It does not include itself again if there is a fault it in, since this would produce an infinite loop, so be sure you script actually works. If it is complex, you should test it by executing it directly.

Where to go from here...

Hopefully, you now have an understanding of how FastTrack works. What can you do with it then? You can of course do anything you could do with other scripting languages, but you will also find, that you can do much much more. Your logonscript can with very few script lines handle location based connection of shares and printers, apply user settings, do cleanups and checks and the single most important new thing is that you can get a centralized log of all execution errors just by filling in one line in ErrorHandler.fsh. This gives you an extreme insight to what goes on "out there" that you never had before and you just wrote one script line to do it. Look in the Logon Script menu for more details on creating login scripts.

You can also script all your installations with simple FastTrack scripts or just wrap your existing scripts. You couls then use your logonscript to solve the classic usersettings problem, this is described in more detail in the Installation menu.

You can also do administrative tasks like replicating data between servers or backing up files with synchronization. You can write small scripts to handle launching of user applications based on script logic and much much more, the possibilities are endless once you understand the power of the script engine. And you can do all the same things for Terminal Servers and Citrix solutions and a few tricks more. You can log people off, if the user uses a certain citrix application on client locations you don't want them to run it from, because you can get the clients IP address and workstation name in a citrix logon script.