Summary

How to deploy a Policy in Guaranteed State.
On this page:

Overview

If you have uploaded the Product Packs provided with the Tachyon release using the Tachyon Product Pack deployment tool,  you will already have several Guaranteed State policies and Instructions available in Guaranteed State. Please refer to Tachyon Product Pack deployment tool for details.

The Guaranteed State policies included with the release are:

Policy nameDescription

Microsoft SCCM Client Health

The Microsoft SCCM Client Health policy ensures that the health of the ConfigMgr client is compliant with a reference baseline.
Microsoft SCCM Patch PolicyThe Microsoft SCCM Patch policy ensures that ConfigMgr based patch management of the device is compliant with a reference baseline.
Nomad Client HealthThe Nomad Client Health policy ensures that the health of the Nomad client is compliant with a reference baseline.
Windows Client HealthThe Windows Client Health policy ensures that the health of the Windows operating system is compliant with a reference baseline.
Windows Security ProfileThe Windows Security Profile policy ensures that the security of the Windows device is compliant with a reference baseline.

When you first open the Administration→Policies page, you'll see a popup message advising that you have policy changes that can be deployed to Agents. This refers to the five new policies in the above table that can be uploaded using the Tachyon Product Pack deployment tool.

The next steps to using these new policies is to add them to one or more Management Groups and to deploy them to Tachyon clients.

For a new or updated policy to become effective, it must be deployedPolicies are deployed by clicking the Deploy button from the Guaranteed State→Administration→Policies page.  Deployment affects all visible policies that are enabled, please refer to the section Deploying Policies for details.





Guaranteed State policies

Assigning a policy to a management group

Before deploying a policy we must first define the devices to which the policy will be sent. We do this by assigning a policy to a management group.

To do this, go to Guaranteed State→Administration→Policies select the policy and click the Assign Mgmt Grp button.

By default, there will always be a management group for All Devices. We select this and then click Save.

If you select All Devices, Guaranteed State will apply the policy to all devices including ones that are not currently online, which may include other OS or device types, for example servers.

For this reason we recommend that you define a specific Management Group for your policy to limit its scope to just the devices included in the Management Group.

The Integrated Product Packs provided by 1E contain policies for Windows devices, therefore when you deploy these please ensure your Management Groups include only Windows devices.

In Guaranteed State you can create your own custom polices and associated rules, refer to Defining your own policy for details.

Assigning a policy to a management group

Assign Management Groups

We should now see the assigned policy.


The policy is now shown with its assigned management groups, in this case, the All Devices group.

Assigned policy

Deploying policies

For a new or updated policy to become effective, it must be deployedPolicies are deployed by clicking the Deploy button from the Guaranteed State→Administration→Policies page.  Deployment affects all visible policies that are enabled.

You can enable or disable a policy from this screen by selecting it and then clicking the Disable Selection or Enable Selection button (which will change the Status as appropriate based on the current state of the policy).

Policy stateDescription
Deleted policies and deploymentIf a policy is deleted, then clicking Deploy will also cause any Tachyon client that receives the deployment to remove the policy and to cease to enforce it.
Disabled policies and deployment

If a policy is disabled, then clicking Deploy will also cause any Tachyon client that receives the deployment to remove the policy and to cease to enforce it. 

If the policy is subsequently re-enabled, then the next time Deploy is clicked, it will be sent out again and become effective.


Currently, you are prompted to deploy a policy as soon as you save it, after creating or editing. However, deploying a new policy where any of the following is true will not result in any action being taken by the Tachyon client on devices because:

  • No rules have been assigned to the policy
  • All rules assigned to a policy are disabled
  • The policy has not been assigned to any Management Group.

However, once a policy has been deployed, re-deploying the policy will always affect the devices to which the policy was previously deployed. In the case where a re-deployed policy meets any of the above criteria, it will cease to be effective on the devices

If the change removes a policy from any management groups, devices affected by this change will receive a policy update. For example, suppose you had a policy P1 assigned to management group MG1 and you then re-target P1 to management group MG2 instead and re-deploy it. All the devices which ever received policy P1 previously will have that policy removed if they now fall outside management group MG2.

The distribution of policies to devices is staggered. The stagger period associated with this activity is designed to avoid excessive network traffic. It is not related to the Tachyon client: DefaultStaggerRangeSeconds parameter which is defined during Tachyon client installation.

Verifying policies

You can verify policy enforcement on the Guaranteed StateOverview page and confirm policy download and applications on the devices.

Verifying policy enforcement

The Guaranteed State overview shows us that we now have two compliant devices.

You can drill down on each chart. For example, clicking on the Device State chart allows us to see the specific devices that are associated with the chart. From there we can examine the history of each device, for example.

History entries are only created when the status changes state from pass to fail or vice-versa. Even though you may have a rule evaluated periodically by the Tachyon client, a history entry is not created for each evaluation cycle. The Tachyon client only communicates a state change when the rule status changes.

This means that if the cause of a failure changes, you may not receive a history entry with the revised cause, because no updates are received until the compliance state changes. This limitation may be revised in a future release.

Verifying policy on Tachyon clients


We can also confirm that the policy was downloaded and applied on Tachyon clients by examining the 1E Client log on the device. Here we see that the policy was downloaded and successfully applied.

1E Client log example

If we now start the registry editor on the device, we can see that the key and value exist.

If we attempt to change the registry key value to 1.

We see that, temporarily, it is out of compliance with the check rule.

However, after 30 seconds, it is automatically reset to be compliant.

If we view the device history from the Guaranteed State Overview screen, we see that the momentary compliance failure has been logged.

Device Status

The device status view in Guaranteed State shows the status of policies and rules for each device.

A device is shown as either Compliant or Noncompliant The associated columns show more information on the status of rules on the device:

ColumnDescription

Rules 

The number of rules which are active for the device. If there are several active policies applicable to the device, the rules count will be the sum of all the distinct rules associated with those policies. (i.e, if the same rule is included in two active policies against the device, the count of distinct rules is 1).

Compliant 

The number of rules which returned a compliance status of success (specifically each rule which returned a boolean value of True when the rules were last evaluated).

Non-compliant 

The number of rules which returned a compliance status of failure (specifically each rule which returned a boolean value of False when the rules were last evaluated).

Not applicableThe number of rules for which the precondition for the rule meant that for this device, the rule was not regarded as applicable and hence was not evaluated.

Error 

The number of rules for which an error was raised during the execution of the rule. This means that the SCALE code associated with the rule failed with an error that caused the code to be terminated, or that the code deliberately raised an error using the SCALE Error function.

Unknown 

The number of rules for which no status has yet been returned from the device.


Device Status