Customizing FastTrack Logon

FastTrack Logon consists of one exe file (FTLogon.exe) and one ini file (FTLogon.ini). What FastTrack Logon does is more or less just to synchronize files from your "ServerDir" to your "ClientDir" and execute the scripts. The reason why the synchronization happens is that doing this will save bandwidth, instead of running a fairly large exe (fsh.exe) directly off a network server every time someone logs on. With FastTrack Logon, you only transfer about 50kb of data from your domain controller plus any changes in the binary folder any time a user logs on.

Another advantage is that this repository folder that is replicated to the clients, can be used for additional files without further deployment. This could for instance be files for SmartDock.

Customizing FastTrack Logon

How FastTrack Logon works

FastTrack Logon is the logon script executable that will do the following at logon:
  • Synchronize the engine (FSH.Exe) and logon script files to a configurable local cache folder to avoid copying the files at every logon.
  • Execute your logon script from this client location.
  • Associate the .fsh extension to the local profile copy of FSH.exe for the current user.
The first time each user logs on to a client, about 1.5 megabytes of data will be copied from the domain controller to a configurable local cache folder. After that, copying will only happen when you change the files in the fshbin folder on the domain controller, which means almost no traffic on subsequent logons. Anything you put in the domain controller's fshbin directory will be synchronized to each client. There is no limitation as to how many files and directories can be put there.

The local copy of the files and the file association is per-user. This way you don't have to do anything else for clients to support FastTrack scripts in general for the logged on user. There is no need for a per-machine deployment and this operation does not require the user to be a local administrator. FastTrack Logon is certified to work on all current Windows versions (Win10/Win8.1/Win8/Win7/Vista/XP/2000/NT4 and 2012/2008/2003/2000 Server).

Configuring FastTrack Logon

You logon script files are located on the netlogon share. The FTLogon.ini file configures FTLogon.exe and looks like this by default:
[Settings]
ServerDir=fshbin
ClientDir=[LocalAppData]\FastTrack
EngineExe=FSH.Exe
PreLogonScript=Prelogon.fsh
PostLogonScript=Postlogon.fsh
StopOnTerminalServices=false
Debug=false
StopOnError=true
Note that "Debug" and "StopOnError" are depricated from version 10.7. The reason is that these can now be controlled from the logon script itself.
"PreLogonScript" refers to a script that is executed before the explorer starts and "PostLogonScript" refers to a script that is executed after explorer starts. Both are relative to the "ServerDir" location. It is a good idea to use the prelogon script, because you know for sure that the user cannot "disturb" anything you might do here, like locking files you want to backup, opening programs that disturb installations, etc. Observe that you can overrule the ability to start the logon script synchronously with group policies, so be sure you don't actively turn off the "Run logon scripts synchronously" setting in your group policies.

The "ServerDir" is a repository folder for anything you want to synchronize to all clients. The directory is by default relative to the FTLogon.exe location, but can be set to any network folder. You can put anything you like in this directory, including files that are not at all related to FastTrack. If you upgrade the FastTrack version, you can just overwrite the fsh.exe in the ServerDir and it will automatically be update on all clients, as users log on. You can also make subfolders and everything you delete, will be remove from the clients as well. FastTrack Logon will also associate fsh files with the FSH.Exe, so you don't need to specify fsh.exe in the shortcuts you may create for the user, which ensures that you can move your client directory without have problems with shortcuts.

ClientDir is the location on the local disk, where server files are synchronized to and executed from. The files are by default located in the user's profile. If you need to change executing user in a logon script, you need to change this setting - see further down.

If you have User Account Control (UAC) disabled in your group policies, you might prefer the path [LocalAppData]\FastTrack, which will put the files in the user's profile instead. But if UAC is enabled, it is not possible to elevate to an administrator in scripts, because UAC will not allow the elevated user to read from the executing user's profile, regardless that the elevated user is domain admin.

Remember that the logon script runs in the users' context, so the user has to have write access to the defined client directory. Do not hard-code the client path, as it will not be the same on different operating systems (see this article for explanation of client paths). You can use these variables for client directories that will be replaced at runtime with actual values:
[LocalAppData] The executing user's application data directory. The executing user has full control over this folder.
[AppDataDir] The common application data directory. The executing user has write access only to the files created by the user himself. Therefore, if common application data is used, make sure that the directory name is unique per user.
[TempDir] The executing user's temp directory. The executing user has full control over this folder, but files here must be expected to be deleted occasionally.
[ProgramFilesDir] The program files directory on the executing computer. Only administrators have write access to subfolders by default.
[WinDir] The Windows directory. Only administrators have write access to subfolders by default.
[Username] The username of the executing user. Can be used with [UserDomain] to build unique per-user directory names.
[UserDomain] The domain of the executing user.
[UserSID] The unique SID (security identifier) of the executing user.
EngineExe refers to the FSH.exe to execute - if you prefer the exe to be located deeper under the fshbin folder, you can prefix it with an additional path.

(depricated) Enabling the "Debug" setting will run the scripts with the /D option and let you debug through the logon script and enabling the "StopOnTerminalServices" setting will disable the logon script execution, when FastTrack Logon is executed inside a Remote Desktop Services session.

(depricated) When "StopOnError" is false, the scripts are executed with the /IE option and all runtime errors are ignored. This setting is recommended to set to false in production environments and then log the error with the errorhandler.fsh script instead. This way the user will never see error messages from script executions.

Changing executing user in a logon script

If you need to change the user that is executing the logon script, you cannot use the default setting, when UAC is enabled, because this user cannot read the cache files in the current user's profile. If you need to change user, use a setting like this for client directory:
ClientDir=[AppDataDir]\FastTrack\[UserName]\[UserSID]
The cache files will then be stored under the common application data in a path that includes the SID (security identifier) of the current user. The reason why the SID is included in the path is that if a user is deleted from the Active Directory and created again, the user has the same user name, but a different SID. And under common application data, only the owner/creator of files and administrators can change files; thus there has to be a directory for each unique SID in the domain for the client files to be updatable. In other words, under the common application data directory, users can read each others files, but not change each others files


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