Skip to main content

1E 23.7 (SaaS)

Using device tags with the Tachyon PowerShell Toolkit

Here we walk through a scenario where we define a tag and then apply it to a device within our domain, and we then target this device using a scope expression.

Device tags are an extremely useful mechanism for applying metadata to devices that will help you effectively manage devices. In the example, we tag our domain database server and then locate it via a scope expression.


Device tags were previously known as coverage tags. Consequently, the cmdlets refer to coverage tags.

Defining the device tag and value

We start by defining the device tag and value. We will create a new device tag called DomainRole and assign an initial value to it, 'DatabaseServer'.

We do this using the add-Tachyoncoveragetag cmdlet as shown below.

Add-TachyonDeviceTag -name DomainRole -value DatabaseServer

Device tags can have multiple values per tag. In this scenario we could have chosen to add more values, such as DomainController, TachyonServer or whatever made sense from our management perspective.

Setting the device tag on the target devices

We now want Tachyon to set the device tag on the desired devices. We choose to set the DomainRole tag with a value of DatabaseServer, targeting the device whose fqdn contains 'urth-sql'. This is our lab database server.

To set the device tag, invoke the Tachyon instruction as shown below.

The scope you specify will define the devices that are to receive the tag. In this example, we have chosen an device that is running SQL Server. It will therefore receive the DomainRole tag with the value of DatabaseServer.

We specify the -nowait parameter because this is an action and not a question. Accordingly, it will require approval. By specifying -nowait, we regain control immediately with the instruction Id returned.


Currently the Tachyon instruction refers to device tags as coverage tags. This is the name by which they were known in earlier releases and has been preserved for instruction compatibility.

The Tachyon instruction defined two parameters whose names contain embedded spaces, "Tag Name" and "Tag Value". PowerShell does not allow parameters to contain spaces. Therefore, underscores are used instead. When you specify a parameter of Tag_Name or Tag_Value, it is automatically translated before being sent to Tachyon, to replace the underscore with a space again.

If you had not specified either or both of these properties, you will be prompted for them by PowerShell in the normal way.

Approving the device tag set instructione

The instruction approver will now receive an email requesting that the instruction be approved, or see a notification in the Tachyon Portal.

The approver receives a token, 'FWUM6' which will allow the instruction to be approved.


If workflow is configured for self-approval, because you are your own approver, you can directly approve the instruction and provide the token.

If workflow is configured for a separate approver (default configuration) you will need to approve the instruction in a separate powershell session where you are either logged on as the approver using the 'runas' command to start the session under alternate credentials, or by using the -Credential option to the set-tachyonserver cmdlet to supply alternate credentials. These credentials should correspond to those of a valid approver on the Tachyon platform.

You approve the instruction using the approve-tachyoninstruction cmdlet.

approve-tachyoninstruction -id 1324 -token FWUM6

Having done this, the instruction now executes and sets the device tag on the specified devices. In this case, only one device, URTH-SQL receives the tag.

We have now marked our lab database server.

Confirming the instruction approval

As the approver, you will have received a followup email confirming that the instruction was approved. Note that by default a comment has been added that the instruction was approved by the PowerShell Toolkit. You could have overridden the default comment by providing a -comment parameter when you approved the instruction above.

Confirming that the device tag has been set

You can use the Tachyon instruction "1E-Explorer-TachyonCore-GetCoverageTag" to determine if the device tag was set correctly.

We target our entire lab machine base here (as all contain FQDNs with the string URTH in them) and we request to drilldown to the detailed results, as this instruction is an aggregating one.


We can see that the URTH-SQL device has accepted and set the device tag.

Using the device tag to define the scope of an instruction

Suppose that we now want to send an instruction which targets only the database servers in our estate. We can now use the device tag to do this.

To see how this works, we can use the 'Get-TachyonRespondingDevice' cmdlet to see which devices would be associated with a defined device tag and value.

We specify a target scope expression that uses the 'tagtxt' entity to define the device tag and value. Within the square brackets we define the tag name (DomainRole) and tag value (DatabaseServer).


You can see that only our database server is returned. This means that any instruction which we invoke in Tachyon can now accept a scope expression which refers to this device tag. When the instruction is invoked, only devices contain the matching tag and value respond.

For example, let's ask what memory chips are installed on any database server.


Device tags provide a powerful and flexible mechanism for managing devices through Tachyon. As you can see, it's easy to use the PowerShell Toolkit to manage and set device tags, then target devices precisely.