Welcome back to ATA’s Learn with Me series on the 1E Tachyon Platform for Unified Experience Management! If you missed the previous posts, be sure to catch up here.
In this final installment, I will not explore a specific application but rather how to extend Tachyon’s functionality to other products and workflows.
Even though Tachyon comes with with a ton of features in-the-box, organizations never work with a single tool. Besides, by leveraging Tachyon’s ability for real-time endpoint communication and its intelligent data-gathering, you could use Tachyon’s strengths in other areas.
For example, during my time as an SCCM admin, I built plenty of PowerShell scripts to interact with SCCM and remotely invoke tasks on devices. I would have loved to have Tachyon’s real-time endpoint communication technology to invoke PowerShell scripts on endpoints and get responses back quickly.
Thankfully, from what I’ve seen so far, Tachyon provides a couple of different ways to customize and extend it to your liking by creating custom instructions and invoking Tachyon actions via its REST API. Through their well-documented Tachyon SDK, you can do quite a bit.
Let’s jump in and see just what’s possible when extending Tachyon for our own unique purposes.
Creating Custom Instructions
If you were paying attention way back in the *Implementing Tachyon* post, you’d know that instructions are what make Tachyon run. Instructions are the actions that Tachyon takes to initiate just about any endpoint action.
Instructions are what Tachyon invokes on 1E Clients to execute actions. Via the Tachyon Exchange, 1E and the Tachyon community already provide dozens of product packs containing hundreds of instructions. Why do you need your own?
You and I both know that every organization will always have some unique use case, “not invented here” mentality, or simply wants a different way to solve a problem. Creating a custom instruction in Tachyon can allow organizations to build functionality into Tachyon however they wish.
1E seems to be more open than other companies. Rather than simply giving you an instruction that supports a PowerShell script, they actually allow you to create first-class citizen instructions that natively integrate into the product.
The Tachyon Instruction Management Studio (TIMS) and SCALE
Many endpoint management products provide a way to write scripts and run them with the product somehow. These products are platforms to rely on you using your language of choice to write some code and execute it on the platform. Tachyon is different.
1E provides you with their very own language called Simple Cross-Platform Agent Language for Extensibility (SCALE), including an integrated development environment (IDE) called TIMS.
To create a Tachyon instruction, you must write it in SCALE. SCALE is an interpreted, cross-platform language that combines common scripting patterns with SQL-like constructs to query and transform data.
It’s currently impossible to create an instruction with any other language than SCALE. I asked why and was told for speed. SCALE talks directly to the Win32 APIs, which eliminates overhead with a language like PowerShell.
You can perform many script-related tasks in SCALE using various functions and methods. For example, you could invoke a WMI query using the RunWmiQuery() method to query an endpoint’s operating system name using the NativeServices namespace.
NativeServices.RunWmiQuery(Namespace:"root\\cimv2", Query:"SELECT Caption from Win32_OperatingSystem");You could download a file via HTTP with the HttpGetFile() function and assign it to a variable called script.
@script=HttpGetFile(URL : "agentVersions.ps1", Size:13536, Hash:
"F03757213F6A4A3FClDGFC589161993917866C88CEA9F68EDS4A892247CDC9F6");Or you could execute a Windows PowerShell 5.1 script using the Run() method in the Scripting namespace using the output from the script variable defined above.
Scripting.Run(Language: "PowerShell", LanguageVersion : "5.1",
ExecutionPolicy : "Override", Script : @script, InterpretAson : true);For example, take a look at an example below of a native instruction. Here you can see the final product once you create the instruction and upload it to Tachyon. Notice how the instruction configuration shown in TIMS correlates to what you’d see in Explorer.
If creating your own instruction seems too far off at this point, don’t worry. I go through a demonstration of creating an instruction and uploading it to Tachyon in the demo below.
Exploring the Tachyon API
If you have another tool that needs to interact with Tachyon, or you’re creating your own tool (which I’ll do below), you’re going to need the Tachyon Consumer REST API. The Consumer API is your gateway to managing Tachyon sans the Tachyon Portal.
The Consumer API has various REST endpoints, as you might expect with a REST API, along with some pretty good documentation. Using the Consumer API, it looks like you can do just about anything in Tachyon. I can tell 1E spent a lot of time making the REST API a first-class citizen in Tachyon.
If you’re familiar with working with REST APIs, the Consumer API will be straightforward to work with. Set up your API testing tool of choice and start seeing what you can do!
You can also interact with the Tachyon Consumer API via the .NET Consumer SDK in C# if you’re a developer at heart.
PowerShell + Tachyon: Testing for Pending Reboots
If you’ve been writing PowerShell scripts for some time, you’re probably familiar with PowerShell or PS Remoting. PS Remoting is a feature built into PowerShell that allows you to run commands on remote computers as if you were sitting in front of them.
PS Remoting is popular PowerShell feature because it’s free, comes with Windows, and usually works with a little bit of setup time. Unfortunately, after using Tachyon for a while, I’ve been slowly realizing PS Remoting’s downfalls.
- PS Remoting is sloooooow compared to Tachyon when you need to run a command on an endpoint.
- Auditing commands ran with PS Remoting requires setup and is not centralized.
- If targeting many different endpoints at once, you must build code to query endpoint inventory from another source or hardcode names in your scripts.
I’m excited to end this series by building a simple Tachyon instruction that invokes a PowerShell script that tests for a pending reboot. Although you can get much more complex, simply having a way to execute ad-hoc scripts on endpoints using Tachyon’s communication method would be awesome!
Set up the Code Signing Certificate
Before you create your first custom instruction, you must first set up a code signing certificate. Tachyon will not run PowerShell scripts (or any task) inside an instruction that isn’t first signed.
You can find the step-by-step instructions on the Setting up custom Tachyon Instructions for the First Time doc page.
The steps to set up a code-signing certificate are, in my opinion, way too convoluted. You must create a dummy instruction first, sign it, get the thumbprint and send it to 1E for license activation.
Create the Query
Since the example I’m using runs a PowerShell script that queries information on an endpoint, I’ll open TIMS and insert the following code.
The SCALE code below will open a script called Test-PendingReboot.ps1 and pass it a parameter of localhost essentially running .\Test-PendingReboot.ps1 localhost on the endpoint.
Scripting.Run(Language:"PowerShell",ExecutionPolicy:"Override",Script:'Test-PendingReboot.ps1',InterpretAsJson:False,"localhost");
Next, it’s time to import the script as a resource into the instruction. By clicking on Import resource and selecting my script, TIMS will embed the PowerShell script into the soon-to-be XML file representing the instruction.
You can see below what the instruction XML looks like after importing the PowerShell script as a resource.
I don’t necessarily think embedding the script in the instruction XML is the best approach. How would you approach updates? I can already see that embedding PowerShell scripts in instructions would soon become unwieldy. It’d be great if an instruction could simply reference a shared repository somewhere.
Next, I’ll define the output. Since the Test-PendingReboot.ps1 script returns a single True/False boolean value depending on if it needs a reboot or not, I’ll provide a Data Type of bool and call the output RebootStatus.
Finally, I will save the instruction as TestPendingReboot.xml.
Uploading the Instruction
Once I’ve created the instruction XML, I’ll then go to the Tachyon portal —> Settings —> Instructions —> Instruction Sets and upload the instruction.
Then, to ensure Explorer can read the instruction, I must then assign it to an instruction set. For this demo, I assigned it to an existing instruction set called OS.
Finally, the moment we’ve all been waiting for! Open up Explorer, and you’ll see that I can now select the instruction I just uploaded.
Conclusion
I was excited to wrap up this series by extending Tachyon since scripting and development are in my blood. I like that you can create custom instructions, but the process seems a bit convoluted, and I’m unsure if running your PowerShell scripts as-is in Tachyon is the best way to go. The jury’s still out on that one.
The REST API is also a huge advantage too especially since it seems like nearly every Tachyon function is available as an endpoint. Everyone loves REST APIs and it seems like 1E put a lot of work into ensuring the REST API has an extensive array of functions.
That’s it! That wraps up this seven-part series on 1E’s Tachyon product! It’s been a whirlwind ride for me as I learned all about Tachyon from scratch. And I learned a ton. I hope you did too!
