Quick links Power Scripting:
FastTrack can be used to accelerate and harden scripts written for COM, (short for Component Object Model) which is a technology that allows software components to communicate.
COM is a great technology because you can interact with any component that exposes a COM interface that you might not be able to script otherwise. The drawback of COM (in a scripting sense) is that it is late binding. Late binding means that methods and properties of the COM interface are determined at run-time and not at compile-time. This effectively means that working with COM interfaces from scripts is a time-consuming trial-and-error process. Another drawback of late binding is that you have to find documentation from the vendor of the COM interface and convert that into the syntax of your scripting language.
If you have used VBScript, you are probably familiar with common COM interfaces like WScript.Network and Scripting.FileSystemObject. These are interfaces that sit on top of the Windows API.
FastTrack Automation Studio can interact with the Windows Registry enabling you to build both simple script logic that runs depending on a particular registry value, to more advanced registry operations that for example involve the changing of registry permissions.
One of the major pain points to most scripters is the fact that writing to the 32-bit and 64-bit Registry on a 64-bit machine are completely different. If you install a 32-bit application on a 64-bit machine, it is not stored in the “normal” 64-bit registry, but in a separate hive and emulated for 32-bit applications. This means that you would normally need two different scripts, one for running on 32-bit and one for 64-bit. FastTrack handles this differently. All Registry and Path functionality have two versions. One that is postfixed with “x86” and one that is not. What is great about that is that on a 32-bit machine, the x86 version behaves the same as the one without the x86 postfix, but on a 64-bit machine, they behave differently. And the reason why this is great is that you never need two versions of your scripts.
Said in another way, if you need to extract a Registry value of an application that is always 32-bit (meaning installed in the x86 version of Program Files on 64-bit), you can just use the RegistryValuex86 function and you can ignore the fact that your script may run on a 32-bit or 64-bit machine. This same logic applies to path functions FastTrack also has the ability via its ImportRegFile command to import entire registry files as part of scripts you build.
FTP is an ancient and venerable protocol; one of the initial ‘building blocks’ of the Internet when it was first created. It is not a secure protocol and as such, and generally been entirely replaced with Secure FTP (SFTP) and FTP Over SSL (FTPS). That said, it is still highly robust, and can still be considered when used in a controlled environment or over a VPN.
FastTracks ability to script commands to send and synchronise files using the FTP protocol can come in handy, especially when working within the connectivity limitations of legacy environments, or systems where it is simply not possible to ‘install’ anything, either file transfer software, or windows components such as .NET runtimes. Like all FastTrack 1,500+ commands, everything is included, and runs from a single, fully standalone 1.7MB executable file.
Even though SFTP or FTP via TLS are not supported, it’s still mandatory to encrypt all passwords when building FastTrack applications that contain FTP commands, so in this respect running FTP commands over plain FTP is still more secure than using plain FTP commands within standard windows batch files.
FastTrack can interact with System Center Configuration Manager (SCCM) by injecting scripts into Task Sequences. By doing this you have access to Task Sequence variables the same simple way that you have access to regular script variables. The exchange of variables between FastTrack and SCCM is completely transparent and on the fly.
You also have access to information about the SCCM client and to standard SCCM logging during execution by using one simple command.
LogTaskActionInfo “Cisco VPN installation skipped – already installed”
You can use other FastTrack features to handle tasks that SCCM cannot do:
Handle some installations outside SCCM based on Active Directory groups.
Create public exe-based install packages for computers not available for servicing.
Ability to create MSI packages from non-MSI based installers without using snapshots.
Create MSI based scheduled tasks that for example backup your SQL Servers.
Add custom tasks and security to your MSI packages and repackage them back to MSI format.
Automatically re-use computer names based on MAC addresses when re-installing operating systems.
Add custom tasks to your operating system deployments.
FastTrack has the ability to collect any WMI object from the local system executing, and use this data pretty much anywhere, be it on screen prompt, a CSV file which is then uploaded to an FTP server, inserted into an MS SQL database or even written into an email and send off someplace.
Bear in mind that WMI can be an CPU intensive method to extract data, so if there is already a native command within FastTrack to get to the exact same data (such as for example, total system memory) we would always recommend the use of the FastTrack native method over WMI as it is much faster, and less resource intensive.
However if you move outside querying common information or you need to invoke methods, you must use WMI. Due to the sheer scope of what’s available via WMI, that’s an immense amount of data that’s not just accessible, through Fastrack, but dynamically actionable.
MS SQL Server
Built into FastTracks core executable engine is the powerful ExecSQL command plus additional functions for the querying data directly from MS SQL server.
If you have a requirement to integrate/exchange SQL based data stored in corporate back office systems with objects stored your Active Directory or vice-versa, you will find our MS SQL support extremely useful.
In addition to data reading and writing from MS SQL databases, FastTrack is able to run any type of Transact-SQL statement and even backup entire SQL databases. By combining FastTracks ability to ‘ingest’ file content (FileContent command) with ExecSQL – if the file you are feeding in is valid SQL, then FastTrack will execute all of these commands against whatever database you’ve pointed it at (be it manually, of dynamically assigned based on your script logic). A handy feature for automating database maintenance tasks, that run along side, or checking ‘behind’ existing MS SQL scheduled jobs.
Again the small size, robustness and stand alone nature of FastTracks tiny 1.7MB executable file can reap benefits here if you find yourself in a situation where you need to script functionality that has a requirement to talk, read or manipulate to an MS SQL Server on ‘wafer thin’ deployments, be they disk-less VDI terminals in an office, or cut down elastically provisioned servers located up at a cloud provider.