Summary

How to use the Guaranteed State application to ensure device compliance to enterprise IT policies.

About Guaranteed State

Guaranteed State is a new feature in Tachyon 4.0 which allows you to easily check and enforce device state. Device state can represent just about anything you'd like to be set in a certain way for a collection of devices.

Guaranteed State requires that some policies and rules are imported into your Tachyon instance before you can use it. Policies and rules are not included with the baseline installation of Tachyon, but a basic Windows Client Health set consisting of one policy and a number of rules is provided in the Tachyon Platform zip and may be added subsequently by running a script. For more information on this process, please refer to Configuring Guaranteed State.

Once you have imported the Windows Client Health set, you will be able to configure Guaranteed State to manage various device attributes. For example:

  • Registry keys
  • Services
  • Config Manager metrics such as client cache usage
  • Disk free space
  • WMI namespaces and classes.

Guaranteed State can also be extended to allow you to define your own checks and enforcement actions. For example, you could define a state which mandated that a particular application was installed at a specified version level, or that documents were only stored in a specific user folder.

On this page:

Key concepts in Guaranteed State

Policies and Rules

Guaranteed State is enforced by the Tachyon Agent at each device using one or more policies that are deployed to devices according to their management group memberships.

A policy consists of one or more rules, which fall into two primary categories:

  • Check rules - these allow you to verify that a device has a particular state, such as a registry key having a specific value. You can then view summary and detail reports that show which devices are compliant and not compliant with the check rules
  • Fix rules - these allow you to define a desired state for the device and then enforce that state. For example, you can mandate that a registry key exists and contains a specific value. Again, you can report on the application of these fix rules to devices.

Management groups use rules to determine device membership, enabling the devices to be administered as a group. For instance, you can select devices based on their Active Directory Organisational Unit, or their operating system version, or any other criteria available to the management group rules. For an explanation of management groups, please refer to the Management groups page.

Rule Triggers

Both check rules and fix rules must have a rule trigger defined. Rule triggers define the conditions which will cause the rule to be evaluated.

Once you have imported the Windows Client Health set into Guaranteed State, as discussed above, you will then be able to make use of a number of rule triggers that come with that set, which include:

  • When the Tachyon Agent starts
  • When a file changes (Windows only)
  • Periodic (hours)
  • Periodic (minutes)
  • Periodic (seconds)

However, rule triggers are extensible. You can define new trigger templates that allow you to set up new rule triggers which will then appear in the trigger list in the rule definition screen.

For more information on defining new trigger templates, please refer to Using the Tachyon Policy Tool.

Preconditions

Both check rules and fix rules may have optional preconditions defined. Preconditions allow you to define a conditional test that must be met before the rule is evaluated. Once you have imported the Windows Client Health set into Guaranteed State, as discussed above, you will be able to make use of a set of preconditions, which include:

  • Run if the Config Manager client is installed
  • Run if <SoftwareTitle> is installed
  • Run if operating system is <OsText>
  • Run if operating system is <OsText> and <SoftwareTitle> is installed
  • Run if device is Windows <Minumum version>

Preconditions are extensible. For more information on customizing the available preconditions, please refer to Using the Tachyon Policy Tool.

A precondition is not required. If you do not specify a precondition, then the rule is always evaluated when the trigger fires

Check rules

Check rules require:

  • a trigger 
  • a check.

You can also optionally add:

  • a precondition. 

Once you have imported the Windows Client Health set into Guaranteed State, as discussed above, you will be able to make use of a number of check rules that come with that set, which include:

  • Check Registry Value - Checks a specified registry hive, subkey and value name.
  • Check Service State - Checks that a specified service on the device is either running or stopped. 

Check rules are extensible. For more information on customizing the available check rules, please refer to Using the Tachyon Policy Tool.

Fix rules

Fix rules require:

  • a trigger
  • a check
  • a fix.

You can also optionally add:

  • a precondition.

Once you have imported the Windows Client Health set into Guaranteed State, as discussed above, you will be able to make use of a number of fix rules, which include:

  • Set registry value. 

Fix rules are extensible. For more information on customizing the available fix rules, please refer to Using the Tachyon Policy Tool.

Be sure that you understand the key differences between Check Rules and Checks and Fix Rules and Fixes:

  • A Check Rule defines a Check, along with the circumstances under which the check will be made. (i.e the trigger and precondition)
  • A Fix Rule defines a Check and a Fix, along with the circumstances under which the check will be made. When the check is performed, the fix is then applied, if the check result indicates a compliance failure.

Rule outcomes

A rule always returns two items to the Tachyon subsystem. One is a Pass/Fail value and the second is an arbitrary data item.

A rule can also return an error status to the subsystem. This can occur if the rule logic terminates unexpectedly, for example, because a file could not be found etc. 

Guaranteed State history will show the result of rule evaluation. It will clearly indicate whether a check rule returned a success (compliance), failure, or error. It will also show whether a fix rule (if applicable) indicated success, failure, or returned an error.

Two things you should know about rule outcomes:

  • A check or fix rule that fails or results in an error causes a device to remain non-compliant from a Guaranteed State perspective.
  • History entries are only created in Guaranteed State when an overall compliance transition occurs i.e from false to true or true to false.