FastTrack offers information about the installed SCCM client, such as whether the client is
installed or not, which version is installed and which site the computer is assigned to.
One use of this information could be checking that all computers actually have the SCCM
client installed. Your clients that show up in the Configuration Manager Console are based
on the discovery methods you have set up. For example, if you use Active Directory
System Discovery, a list of computers is retrieved from the computer accounts in your Active Directory.
If you use Network Discovery, clients are found by various means such as querying Microsoft DHCP
and WINS servers for a client list. It is therefore not likely that computers will not eventually show up
in the console. However, what is not unlikely is it not being possible to push the client to
all computers. There are a number of situations, where we know a FastTrack script will be running on
these computers from time to time, and we could use these to make integrity checks.
We could put this script line into the regular logon script:
If Not SCCMClientInstalled
Then ShowMessage Your computer is unable to receive
software updates. Please contact the Help Desk.
If it then turns out that the SCCM client is not installed on a computer, when a user logs on,
this is shown during the logon process:
In fact, this is essentially what the Logon Script Wizard does, if use the SCCM client check.
The Logon Script Builder is essentially just a script generator, but you are limited to what
GUI can produce, if you do not write the script "by hand".
We could also choose to use the SendMail command to email the Help Desk to advise of this problem.
This script line would also be of great value to put in a SmartDock script
as it is most likely that problems pushing the client to a computer would be over VPN connections for
computers that are rarely or never on the LAN.
Another use would be to include SCCM client information in your personal SkyBox
When you use SCCM, you might not be using SkyBox at the same time, but one does not rule out the other. While SCCM collects
heaps of inventory data about computers, SkyBox is a light-weight inventory, because the purpose of SkyBox is to
make inventory information available in the cloud. SkyBox can also be used to identify clients that do not have the SCCM
client installed or that have an older version, simply by using the SkyBox filter function. To include SCCM client information
in your personal SkyBox, we can simply supply the relevant information as custom properties:
When we log on to SkyBox and investigate a computer, this information is now available as two custom
attributes. In the case below, the names are set by using the link below the information. The version of the SCCM
client is also available in the software inventory list.
The true power of the collaboration between SCCM and FastTrack is when using FastTrack as part of SCCM Task Sequences.
To learn what a Task Sequence is, please refer to the official Microsoft documentation here
In short, you can say that a Task Sequence is a series of steps controlled by SCCM with the option to execute each step conditionally.
Including a FastTrack script in your Task Sequence is very simple. Simply insert a "Run Command Line" action anywhere in your sequence:
You can then choose to execute a compiled FastTrack exe file or you can put a copy of FSH.Exe, FSH.Lic
and a copy of your script in a directory and execute it from there. In this example, the second option
Task Sequence Logging
FastTrack supports logging entries in the SCCM logging format. All you have to do to log, is to issue
the LogTaskActionInfo, LogTaskActionWarning or LogTaskActionError command. By default the log file is FSH.log, but you can
change this with the SetTaskActionLogFile command.
It is up to you to decide how much logic you place in the sequence and how much logic you want controlled
by a script. If there are any uncertainties, it might be safer to have a FastTrack script control a large
part of the logic. For example, if there is uncertainty as to whether or not some laptops may already have the Cisco VPN client
installed manually, why not simply execute a script on all computers and let the script decide the logic.
So we could go:
If Portable Then
Systems VPN Client Then
LogTaskActionInfo Cisco VPN
LogTaskActionInfo Cisco VPN
LogTaskActionWarning Cisco VPN
installation skipped - already installed
If we examine the log for a laptop that has the software installed,
it looks like this:
Using Task Sequence variables
To learn what Task Sequence variables are, please refer to the official Microsoft documentation
Basically Task Sequence variables are what make Task Sequences cool. The variables are available upon execution
and only during execution. The variables available are the sum of standard variables
variables assigned specifically to a collection or computer. The standard variables (the ones starting with underscore) are
read-only, whereas all other variables can be changed and new variables created during the sequence for other steps to use.
When executing a script as part of a Task Sequence, all variables can be read by using the TaskVar function and existence can be checked with the TaskVarExists
condition in the FastTrack script. A script line using a custom variable that must be passed from a collection variable could look
like the example below, where the installation folder must be passed to the script as a Task Sequence variable. The installation folder
variable can be passed by using a collection variable, a computer variable or can be defined by a previous step.
If TaskVarExists InstallFolder Then
SyncDir Bin,[TaskVar InstallFolder]
There are lots of standard variables
for example the variables _SMSTSLastActionSucceeded and _SMSTSPackageName variables, which tells if the previous action/step in the
sequence failed and the name of the executing sequence. These can be read with the TaskVar function, but they are also available as
the condition "LastTaskActionFailed" and the "TaskSequenceName" function, which are basically wrappers for these two variables. If there was
a prerequisite step prior to installing the Cisco VPN client and we wanted the FastTrack script to fire the installation conditionally, our script to install is not the first action in the sequence.
In case there is a severe error in the prerequisite action (previous step), we could email the administrator notifying of the problem
and not attempt the installation:
Robot,firstname.lastname@example.org,SCCM Error,Unable to execute [TaskSequenceName] on [ComputerName]
If Portable And Not ProgramInstalled Cisco Systems VPN Client Then InstallMSI CiscoVPN.msi
Setting Task Sequences variables
In the previous section we looked at how to consume SCCM variables in our scripts. But we can also do it
the other way around and make variables available to other actions in the sequence. Any condition or other
information you can do or get with a FastTrack script, you can set as variables in sequence using the
For example, if we wanted to deploy our Cisco VPN client software only to laptops, we could deploy it to a collection
of laptops, hoping that the collection includes nothing more or less than the actual laptops in the organization.
Another way around it is to deploy a Task Sequence to all computers and then install it conditionally,
as shown in the previous section. There are a number of examples available to determine in an SCCM Task Sequence,
if a computer is a laptop by reading the chassis type through WMI. This approach is unsafe, because if there is
a new chassis type in the future, the VPN software gets installed on too many or too few computers. The only safe
way to do it is to rely on the FastTrack "Portable" condition. This means that we could either use the above
approach and execute a sequence on all computers, or we could make the "Portable" condition available to the
rest of the Task Sequence to install an SCCM package instead of executing the installation MSI from the script.
To do the same using a Task Sequence, we need to make the Laptop condition available in the Task Sequence
through a new variable. While we are at it, let's make a generic expandable template script that we could
use as a general first action in sequences:
If Server Then
If Windows64Bit Then
Subsequent actions will now have three new variables available: "ComputerType" (value will
be "Desktop" or "Portable), "IsServer" and "Is64Bit". You can expand this script to make
much more rich information available to a sequence. For example, you can now make Active Directory
information of the executing computer available to the sequence, such as creating a true/false
variable based on the "ComputerIsInOU" or "ComputerIsMemberOf" to tell if the computer is member
of a specific group and in a specific Organizational Unit.
To get the script executed, we must either use a copy of FSH.Exe, FSH.Lic and the script
on a share or compile it into an exe file. We will do the latter in this case and save the output
exe file as TSVarSetter.exe in root of a share named \\acmeserver\deploy$:
Next step is creating a new Task Sequence, which will use the exe file as the first step to
make the variables available. Create a new Task Sequence and edit it:
The first step in the sequence is calling the new TSVarSetter.exe file. Select the "Run Command Line"
command as the first step and call the TSVarSetter.exe:
At this point in the sequence, the new variables are available. This means that we can install the Cisco VPN
Operating System Deployments
Operating System Deployments (OSD) can also use Task Sequences as part of the installation process.
The Task Sequence will be running under Windows PE and for this reason, it is not recommended to use a FastTrack
script at this stage for two reasons. The first reason is that FastTrack, like PowerShell, requires the .net 2.0
framework to execute and the .net 2.0 framework is not available in Windows PE. This limitation is relatively
easy to overcome, if you Google the subject and it is relatively easy to get FastTrack and PowerShell to work under Windows PE.
However, the second and more important reason is that Windows PE is not the full operating system and therefore only a subset
of FastTrack and PowerShell will actually work under Windows PE, which is the real reason why FastTrack Software cannot support
use under Windows PE the same way Microsoft cannot support PowerShell under Windows PE. The way to get around this is to
handle this scenario a little different. Let SCCM execute the basic Task Sequences required to install drivers and packages
and then hook into the unattended deployment process later and get access to the full Windows API, all features of FastTrack
and the ability to work with your Active Directory during OS installation.
Basically it is just a question of placing 4 files in the source image under Sources\$OEM$\$$\Setup\Scripts,
which would be under \\AcmeServer\Images$\Win7x64Pro\sources\$OEM$\$$\Setup\Scripts in the example below.
Please refer to this page
for documentation on how to execute
FastTrack scripts with SCCM OS deployments.
Software Distribution Packages
In the previous sections we have focused mainly on how to distribute software using Task Sequences. You can also deploy
software or maintenance tasks through regular SCCM packages that are based on a controlling FastTrack script.
The easiest way to do that is to compile your maintenance or installation script into an exe file and place it along your installation files (if any).
Please refer to this page
for information on how to compile script into
exe files. You can also just place your script and a copy of FSH.Exe and FSH.lic in the folder and execute FSH.Exe
passing the script file to FSH.Exe.
Other points of interest
You can use other FastTrack features to handle tasks that SCCM cannot do. For example:
- Handle some installations outside SCCM based on Active Directory groups. More info
- Create public exe-based install packages for computers not available for servicing. More info
- Create MSI packages from non-MSI based installers without using snapshots. More info
- Create MSI based scheduled tasks that for example backup your SQL Servers. More info
- Add custom tasks and security to your MSI packages and repackage them back to MSI format. More info
- Automatically re-use computer names based on MAC addresses when re-installing operating systems. More info
- Add custom tasks to your operating system deployments. More info
- Handle scripting tasks that SCCM cannot do for you, like LAN and VPN logon scripts and laptop backups.