Sample exe files

The scripts that you compile into exe files, do not require FastTrack Scripting Host to execute. You can try these sample exe files without having FastTrack Scripting Host installed.

Demo script exe file Executable version of the demo script that comes with the installation of FastTrack Scripting Host.

HelpDesk application exe file Executable version of the script file compiled in the movie above - the script is explained in this article. Be aware that Active Directory operations will be performed, if you select a menu item and fill in the information.

Backup Assistant exe file Executable version of the backup assistant presented in this article. Note that the backup copy operation will be performed, if you select a source and destination.

Pros and cons

A FastTrack Scripting Host script can either be compiled into a stand-alone exe file or if FSH.Exe is present, the script itself can just be executed. Select "Getting Started Wizard" from the "Help" tab in the editor for more information on executing regular scripts.

The drawback of creating an executable file in general, over a regular script execution, is that it's larger than the script file: A 10kb script file will be a little over 1mb as an exe file. And another drawback is that the original script must be kept as the source code for future editing, because the original script can never be retrieved from the exe file.

In a situation where a copy of FSH.Exe is already on target computers, or can easily be placed there, there is no reason to create an exe file. If you are compiling your script only to protect the content, you get the same level of protection simply by encrypting your script. For instance if you are already using FastTrack Logon, FSH.Exe is already installed on clients. And if you are creating a batch job for a server, it might be a better idea to just place a copy of FSH.Exe in the same directory as the script, to be sure you always have the original script for future editing.

On the other hand, there are many scenarios where a single exe file is the best choice. An exe file can run on any computer without including an FSH.Exe and FSH.Lic file and can simply be served on a network drive, usb stick, CD, DVD, from an intranet server or zipped in an email. And you have the option of packing additional files into your exe files (see next section), so exe conversion would be relevant in scenarios like:

• You have installation scripts in a relatively public area and you want to ensure the users do not copy the installation files.
• Your scripts are in a relatively public area, like an education center, and you have concerns that external users may copy your license key.
• Others administrators also have your private key and you want to make sure no one else can edit your scripts.
• You are a consultant writing scripts for a customer.
• You have little or no control over executing computers.
• Executing computers are not accessible for servicing.

Note that producing an exe file or using the original script makes no difference regarding licensing. Any compiled exe file will be compiled with license information of the creator and licensing rules are the same.

Executable projects

You will have two options of creating an exe file from the "Execute" menu:

• Create Executable Script: Compiles your open script into a single executable file (see movie at the top).
• Create Executable Project: Compiles your open script and all other files in your script directory structure into a single executable file.

An executable project is basically the same as an executable script, except that it also includes other files. This means that you can repackage a whole directory structure and include your own custom script into one single self-extracting exe file. The files will be unpacked to the executing users' temporary directory and the script that was the base of the project gets executed after unpacking as the "boot" script. You can then for instance create a company specific repackage of a whole software installation, including your custom script, into a single exe file without compromising credentials and other sensible information in your script.

To setup a project to repackage, follow these steps:

• Create a project folder
• Create a script file in the root of the structure that will be the boot script
• Include all other files for the project in the project folder or subfolders

In the movie below, the scenario is this:

• The network administrator wants to create a pool of common applications that users can self-service themselves to get installed, without consulting the IT department.
• Any one installation must be one executable file to avoid users copying the installation files.
• Executing users are not administrators.
• The process must be completely automatic without requiring user interaction, except asking to install or not.
• There is a local administrator account on all computers that have the same password known only to the network administrator.
• Executing users must not be able to get credentials of the local administrator account executing the installation.

In the example below, a single 90mb exe file is produced that will install Adobe Reader 8.1 using a custom administrator account.

Command line compilation

It is possible to compile scripts from command line. A tool called Build.Exe is located in the installation directory of FastTrack Scripting Host, which can be called to compile script files into exe files without using the script editor. The syntax is:
If the /Quiet switch is specified, the successful conversion message will not be shown. In case of an error, an error message will always be displayed.

Protecting content

This section and the next section are extracts from the Unattended Installations page describing how to package a script and installation files into one single exe file that can be placed in a public location for computers that are not accessible for servicing. Please refer to that page for more details on creating installation scripts.

Creating a single exe file based on a script and installation files has a number of advantages over all other possible alternatives for these types of machines: The users cannot get a copy of the installation files, the users do not have to be administrators and credentials can be safely included in scripts.

If an exe file is put on a public location, we need to protect it from abuse. We could get by this by simply asking for a password that only internal users know. If we inserted this at the top of the script before getting to the script lines that actually perform the installation:
Then the user will see this, when running the exe file:


If the user did not enter "Sesame" in this case, then the user gets an error and the exe file exits.

Getting permissions and privileged

If the offline users are local administrators, we can continue to the actual installation script lines that execute the installation. If the local user may be under User Account Control, we might need to elevate the user to be able to actually execute the installation. To handle this, we simply need to insert one script line before we start the installation:
Please refer to the User Account Control page for more information on the ElevateUser command.

If the user is not local administrator, but we know the name and password of a local administrator account that is not under User Account Control, we can simply change the executing user before doing anything that requires administrative privileges:
What is important to understand is that all this will be compiled into a single executable file and the executing user will have no chance of getting any information from inside the script. Using the above "start password" example, the user does not know any account passwords. The output exe file can be put in a public location and the url and start password can be handed out.

Digitally signing your exe files

If you plan to deliver your exe files over a public infrastructure, as suggested above, you might want to digitally sign your executable file. You can use Microsoft Authenticode to sign your output exe file the same way that you can sign any other exe file. FastTrack Software cannot warrant the content of your scripts and therefore generated exe files are not digitally signed. You can however purchase your own digital signature from for example VeriSign and sign your generated exe file with the Microsoft tool Signtool: Please refer to the official signtool page for more information on digitally signing exe files with signtool.