Deploying a Policy
How to deploy a Policy in Endpoint Automation.
Overview
If you have uploaded the Product Packs provided with the 1E release using the PPDT, you will already have several Endpoint Automation policies and Instructions available in the application. Please refer to Tachyon Product Pack deployment tool for details.
The policies included with the release are:
Policy name | Description |
|---|---|
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 Policy | The Microsoft SCCM Patch policy ensures that ConfigMgr based patch management of the device is compliant with a reference baseline. |
Nomad Client Health | The Nomad Client Health policy ensures that the health of the Nomad client is compliant with a reference baseline. |
Windows Client Health | The Windows Client Health policy ensures that the health of the Windows operating system is compliant with a reference baseline. |
Windows Security Profile | The 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 new policies in the above table that can be uploaded using the PPDT.
The next steps to using these new policies is to add them to one or more Management Groups and to deploy them to clients.
Note
For a new or updated policy to become effective, it must be deployed. Policies are deployed by clicking the Deploy button from the Endpoint Automation→Administration→Policies page. Deployment affects all visible policies that are enabled, please refer to the section Deploying policies for details.
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.
Warning
If you select All Devices, Endpoint Automation 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.
Note
In Endpoint Automation you can create your own custom polices and associated rules, refer to Defining your own policy for details.
We should now see the assigned policy.
Note
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. 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 state | Description |
|---|---|
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. |
Note
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 1E 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 DefaultStaggerRangeSeconds parameter which is defined during 1E Client installation, refer to 1E client settings for details.
Verifying policies
You can verify policy enforcement on the Endpoint Automation→Overview page and confirm policy download and applications on the devices.
Verifying policy enforcement
The Endpoint Automation overview shows us all 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.
Note
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 1E Client, a history entry is not created for each evaluation cycle. The 1E 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 1E Client
We can also confirm that the policy was downloaded and applied on 1E Client 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 Value name and Value data exist.
If we attempt to change the Value data 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 Endpoint Automation Overview screen, we see that the momentary compliance failure has been logged.
Device Status
The device status view in Endpoint Automation 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:
Column | Description |
|---|---|
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 applicable | 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. |
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. |
