The client

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 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.

Task Sequences

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 is used:

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 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 here. 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 and 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.
There are lots of standard variables available, 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:

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 SetTaskVar command.

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:
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 package conditionally:

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.