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:
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:
The executing user's application data directory. The executing user
has full control over this folder.
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.
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.
The program files directory on the executing computer. Only administrators
have write access to subfolders by default.
The Windows directory. Only administrators
have write access to subfolders by default.
The username of the executing user. Can be used with [UserDomain] to build
unique per-user directory names.
The domain of the executing user.
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.
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.
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:
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