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

Assigning a policy to a management group

Before deploying the 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, select the policy and click the Assign 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.

Our example uses the Set MyApp Registry key policy created in Defining your own policy.

We should now see the assigned policy.

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

Deploying policies

For a new or updated policy to become effective, it must be deployed. Policies are deployed by clicking the Deploy button from the Guaranteed State→Administration→Policies page.

Note that 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 or Enable button (which will change caption as appropriate based on the current state of the policy).

Deleted policies and deployment

If 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:

  • 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 Overview 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.

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.

  • The Rules column shows 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).
  • The Compliant column shows 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)
  • The Non-compliant column shows 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)
  • The Not applicable column shows the 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.
  • The Error column shows 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.
  • The Unknown column shows the number of rules for which no status has yet been returned from the device.