Overview

You can configure Inclusive policy rules to automatically associate specified agent management services with specified Smart Groups. Gaps between the configured inclusive policy and actual management service deployment are handled in two ways:

• In the Endpoint list, when an endpoint’s managed agents do not match the configured policy, the managed agents are marked with a compliance exception.
• If auto-remediation is enabled (in Advanced Settings), JetPatch Agent Manager automatically provisions management services and managed agents according to policy. If JetPatch Agent Manager subsequently finds that the service, managed agent, or connector has been manually removed from the endpoint (not just stopped), and policy consistency is enabled, JetPatch Agent Manager redeploys the service to the endpoint.

You can also configure Ban rules that will prevent specified agent management services from being deployed (manually or by policy) to specified Smart Groups.

The Agents & Tools → Selected Tool → Policy tab contains a list of configured policy rules for a specific tool, ordered by priority. 

The Status of each rule is either Enabled (the management service is applied) or Disabled (the rule is inactive). For agent management services (not the connector), rules are marked by type: Include or Exclude.

Configure Policy Rules

Edit an Existing Rule

1. Scroll to the right in the policy configuration window and click the Edit icon.
2. Under Actions, you can remove or edit any rule.

Add a New Rule

1. Click Add Rule.
2. Enter a Rule Name.
3. Select a Smart Group (or All Servers).
4. Select Required Service.
5. Select Auto Fix Mode.
6. Select Severity of Related Exceptions.
7. Choose whether to enable the rule or not.

8. Click OK, then click Apply.

   

   1. Enter a Rule Name
   2. Select a Smart Group (or, All Servers)
   3. Select Required Service
   4. Select Auto Fix Mode
   5. Select Severity of Related Exceptions
   6. Choose either to enable the rule or not
   7. Click OK.
   8. Click Apply.

How Policy Engine Works

Before provisioning each endpoint with the applicable policies, the Policy Engine compares rules based on three criteria:

• The Smart Group is associated with the Rule.
• The Managed Service associated with the Rule.
• The Action chosen for the Rule (e.g., “Require” or “Ban”).

This comparison happens in three steps:

Step 1: Generate Exception List

The Policy Engine runs through the rules one by one and omits those that don’t apply to the Smart Group in question.

For the remaining rules, if the managed service matches those applied to the Smart Group and the action is “Required,” the Policy Engine will not do anything.

An exception will be generated for a rule that fits one of two cases:

• The managed service is already installed on the endpoint, but the action is banned.
• The managed service is not installed on the endpoint, but the action is required.

Step 2: Filter by Priority Rule

The Policy Engine takes the exceptions list and, for each exception, checks if another rule exists with a higher priority (also according to the Smart Group relationship).

Step 3: Single Exception Treatment

The Policy Engine then applies a policy to each endpoint:

• If the highest priority rule is an exception, that exception is applied. Only one exception can be applied by the Policy Engine.
• If the highest priority exception is lower in priority than another rule according to the Smart Group relationship, no exception will be applied to the endpoint.

Scenarios

Scenario 1

A certain tool has the following rules:

• EP1 is part of Smart Group SG1 only. EP1 has the tool installed with MS2 as the Management Service.

Generate Exceptions List:

• Rule #1 is not relevant because EP1 is in a different Smart Group.
• Rule #2 will generate an exception (MS1 is not installed on EP1) — “EX2”.
• Rule #3 will generate an exception (MS2 is installed on EP1) — “EX3”.

Filter by Priority Rule:

The exceptions list has 2 exceptions (EX2 and EX3). Now it checks the priority of rules relevant to SG1:

• Rule #1 is out of scope because EP1 is not in SG2.
• EX2 — This is the highest priority rule that matches EP1.
• EX3 — Another rule is in higher priority (#2), so this exception is filtered out.

Single Exception Treatment:

EX2 will be treated.

Scenario 2

A certain tool has the following rules:

• EP1 is part of Smart Group SG1 only. EP1 has the tool installed with MS2 as the Management Service.

Generate Exceptions List:

• Rule #1 will not generate an exception (MS1 is really not installed on EP1).
• Rule #2 will generate an exception (MS2 is installed on EP1) — “EX2”.
• Rule #3 will generate an exception (MS1 is not installed on EP1) — “EX3”.

Filter by Priority Rule:

The exceptions list has 2 exceptions (EX2 and EX3). Now it checks the priority of rules:

• EX2 — Another rule is of higher priority (#1), so this exception is filtered out.
• EX3 — Another rule is of higher priority (#1), so this exception is filtered out.

Single Exception Treatment:

The filter cleared all exceptions — nothing will be applied.

Scenario 3

A certain tool has the following rules:

• EP1 is part of Smart Group SG1 only. EP1 has the tool installed with MS2 as the Management Service.

Generate Exceptions List:

• Rule #1 will generate an exception (MS2 is installed on EP1) — “EX1”.
• Rule #2 will not generate an exception (MS1 is really not installed on EP1).
• Rule #3 will generate an exception (MS1 is not installed on EP1) — “EX3”.

Filter by Priority Rule:

The exceptions list has 2 exceptions (EX1 and EX3). Now it checks the priority of rules:

• EX1 — This is the highest priority rule that matches EP1.
• EX3 — Another rule is in higher priority (#1), so this exception is filtered out.

Single Exception Treatment:

EX1 will be treated.

Relevant Articles

• Learn more about Moderate vs Aggressive mode in the autofix mode article
• Deploying the JetPatch (Intigua) Connector with Policy