Endpoint Automation

Endpoint Automation is based on the concept that a device is aware of its own current state more accurately than any centrally held repository. Also, if you can query the device directly then the need to store masses of data becomes unnecessary.

Endpoint Automation Concepts

Concepts used by the Endpoint Automation application, which ensures device compliance with enterprise IT policies. Endpoint Automation 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.

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.

Integrated Product Packs

Integrated Product Packs are Zip files containing Endpoint Automation policies, but can also contain instructions (as an alternative to classic Product Packs which can only contain instructions). They have a folder structure and files as shown in the following table (except for manifest.xml) all folders and files are optional.

You can upload these Zip files into 1E using the 1E Product Pack deployment tool, please refer to Getting started for details.

Folder	Sub-folder	Files
Fragments	Check	xml files, each containing the definition of a check fragment
Fix	xml files, each containing the definition of a fix fragment
Preconditions	xml files, each containing the definition of a precondition fragment
InstructionSets	<Instruction Set Name>	xml files, each containing the definition of an instruction
Policies	xml files, each containing the definition of a policy (a list of rules). Refer to Policies and Rules.
Rules	xml files, each containing the definition of a rule (a list of fragments, triggers, and their parameter values). Refer to Policies and Rules.
Trigger Templates	xml files, each containing the definition of a trigger template and its available parameters. Refer to Triggers.
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>.ico	icon file that is referenced in the manifest.xml (Not currently used).

1E provide a number of ready-made policies which are described in the Integrated Product Packs pages:

• MEMCM Client Health Policy

• Nomad Client Health Policy

• Windows Client Health Policy

• 1E Core Utilities

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 1E DEXPacks reference.

You can also create your own policies using rules, fragments and triggers from other Integrated Product Packs, for example, the 1E Core Integrated Product Pack.

Policies and Rules

Endpoint Automation is enforced by the 1E 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:

Category	Explanation
Check	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 which show devices that are compliant and not compliant with the check rules.
Fix	Allow you to define a desired state for the device and then enforce that state. For example, you could 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 example, 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. Please refer to Management Groups page for details.

You can also create your own policies using rules, fragments and trigger templates from any Integrated Product Pack that you have uploaded, which are fully configurable, please refer to Defining your own policies for details.

For details on check and fix rules, refer to Fragments in Tachyon Core integrated product pack.

Fragments

Fragments is a collective term for rules (refer to Policies and Rules), trigger templates (refer to Triggers), and Preconditions which are written in the 1E 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. Refer to Trigger templates and preconditions reference.

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. Refer to Precondition fragments.

Dependencies

Check rules require a:

• Trigger.

• Check.

You can also optionally add a precondition.

Fix rules require a:

• Trigger.

• Check.

• Fix.

You can also optionally add a precondition.

Rule outcomes

A rule always returns two items to the 1E 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.

Endpoint Automation 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.

Endpoint Automation Features

An overview of Endpoint Automation features. The Endpoint Automation application gives you the ability to ensure device compliance with enterprise IT policies.

Policies and Rules

The Endpoint Automation of a device is enforced by the 1E client at the device. One or more policies are deployed to devices according to the management groups the devices belong to. Each policy consists of one or more rules that are either check rules or fix rules.

Rule	Explanation
Check	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 which show devices that are compliant and not compliant with the check rules.
Fix	Allow you to define a desired state for the device and then enforce that state. For example, you could mandate that a registry key exists and contains a specific value. Again, you can report on the application of these fix rules to devices.

For an explanation of management groups, please refer to the Management Groups page. Management groups allow devices to be flexibly grouped, based on management group rules. This means you can easily administer devices based on, for instance, their Active Directory Organizational Unit, or their operating system version, or any other criteria supported by the management group rules. Refer to Defining your own policies and Integrated Product Packs

The Endpoint Automation Overview page

The Overview page lets you view the current state of your enterprise in terms of the devices and policies that have been defined and applied. It consists of a number of charts that let you monitor the state in real-time. Refer to Overview and Reports pages

Endpoint Automation Reports

The Endpoint Automation application provides three reports that let you view the details for the currently defined Policies, Rules and Devices. The information in these reports is consolidated into the Endpoint Automation Overview page charts. Refer to Overview and Reports pages

Exploring devices

Endpoint Automation provides a Devices page where you can view the currently connected devices. On this page you can also select one or more of the devices and click an Explore button that launches the Explorer application. You can then run an instruction using the selected devices as the coverage for the instruction. Refer to Using Endpoint Troubleshooting to investigate devices in Endpoint Automation

Device Criticality

Device criticality is an attribute of a device that defines its importance within an organization. The default definition in 1E has these settings:

• Undefined (or not set).

• Non-critical.

• Low.

• Medium.

• High.

• Critical.

At present, criticality settings do not affect the primary operation of Endpoint Automation. However, it is possible to use 1E to set device criticality and to view it within Endpoint Automation.

1E also supports the use of the criticality setting when defining coverage for an instruction. For example, you can target an instruction to be sent only to devices whose criticality is not Critical. Refer to Using Device Criticality