Summary

Concepts used by the Guaranteed State application, which ensures device compliance with enterprise IT policies.

About Guaranteed State

Guaranteed State is a feature, first introduced 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 you first configure it, and then upload some policies (with their rules, triggers and preconditions) into your Tachyon system before you can use it. Please refer to:

Once you have imported an Integrated Product Pack you can configure and deploy policies 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.

On this page:

Key concepts in Guaranteed State

Integrated Product Packs

Integrated Product Packs are:

  • zip files containing Guaranteed State policies, but can also contain instructions (as an alternative to classic Product Packs which can only contain instructions)
  • zip files with a folder structure and files as shown in the following table - except for manifest.xml all folders and files are optional
  • uploaded into Tachyon using the Tachyon Product Pack deployment tool - for more information please refer to Uploading the Integrated Product Packs.

FolderSub-folderFiles
Fragments

Checkxml files, each containing the definition of a check fragment
Fixxml files, each containing the definition of a fix fragment
Preconditionxml files, each containing the definition of a precondition fragment
InstructionSets<Instruction Set Name>xml files, each containing the definition of an instruction
Policiesxml files, each containing the definition of a policy (a list of rules)
Rulesxml files, each containing the definition of a rule (a list of fragments, triggers, and their parameter values) 
TriggerTemplatesxml files, each containing the definition of a trigger template and its available parameters
manifest.xml

xml file containing name, description and version details, that are only used for display by the Product Pack Deployment tool

The presence of this file indicates the zip file is an Integrated Product Pack.

<policy>.icoicon file that is referenced in the manifest.xml, which is not used currently.
1E provide a number of ready-made policies which are described in the Integrated Product Packs pages:

These pages include lists of instructions, policies, rules, fragments (preconditions, checks and fixes) and trigger templates. The lists have links to more detailed information about each pack in the Integrated Product Packs reference.

You can create your own policies using rules, fragments and triggers from other Integrated Product Packs. For example, the Tachyon Core Integrated Product Pack.

Policies and Rules

Guaranteed State is enforced by the Tachyon client 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 Organizational 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.

You can create your own policies using rules, fragments and trigger templates from any Integrated Product Pack that you have uploaded, which you configure how you wish. Please refer to Defining your own policy.

The following are examples of check and fix rules, that are provided by the Tachyon Core Integrated Product Pack:

Fragments

Fragments is a collective term for Rules, Trigger templates and Preconditions. These are written in the Tachyon instruction language SCALE.

Triggers

Triggers define the conditions which will cause a rule to be evaluated. Each check rule and fix rule must have a rule trigger defined using a trigger template.

The following are examples of trigger templates, that are provided by the Tachyon Core Integrated Product Pack:

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.

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

The following are examples of preconditions, that are provided by the Tachyon Core Integrated Product Pack:

Dependencies

Check rules require:

  • a trigger 
  • a check.

You can also optionally add a precondition. 

Fix rules require:

  • a trigger
  • a check
  • a fix.

You can also optionally add a precondition.

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

  • A Check Rule defines a Check , including a trigger and and optional preconditions.
  • A Fix Rule defines a Check and a Fix, including a trigger and and optional preconditions. A fix is applied when a check is performed and 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.

Four 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.
  • If the precondition for a rule returns failure on a device when evaluated, then the Guaranteed State subsystem indicates 'not applicable' against the device compliance status for the rule.
  • Rules that return 'not applicable' do not affect device compliance status. If all rules for a device returned 'not applicable' the device would still be regarded as compliant.