You can configure Inclusive policy rules to automatically associate specified agent management services with specified smart groups. Gaps between 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 configured policy, the managed agents are marked with a compliance exceptions. For example: .
- If auto-remediation is enabled (in the advanced settings) JetPatch Agent Manager automatically provisions management services and managed agents according to policy. If subsequent to applying a management service to an endpoint by policy, JetPatch Agent Manager finds that the service, managed agent, or connector has been manually removed from the endpoint (not just that the managed agent is stopped), and policy consistency is enabled, JetPatch Agent Manager redeploys the service to the endpoint.
If any endpoint is included in two or more rules that apply different management services with the same managed agent, the first rule wins and that is the management service that will be applied to the endpoint server.
If due to a change in filter configuration or in endpoint configuration an endpoint no longer belongs to a group, services are not accordingly removed but the rules will no longer be applied on it.
You can also configure Ban rules that will prevent specified agent management services from subsequently being deployed (manually or by policy) to specified smart groups.
The Tools> Selected tool > Policy tab contains a list of configured policy rules for a specific tool and is 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.
You can manage the table.
To configure the policy:
- In order to edit an existing rule scroll to the right in the policy configuration window and click
Under Actions, you can Remove or Edit any rule.
- To add a rule:
- Click Create Rule
- Enter a Rule Name
- Select a Smart Group (or, All Servers)
- Select Required Service
- Select Auto Fix Mode
- Select Severity of Related Exceptions
- Choose either to enable the rule or not
- Click OK.
- Click Apply.
How Policy Engine Works
Before provisioning each endpoint with the applicable policies, The Policy Engine will compare the rules based on three criteria:
-The smart group associated with the Rule
-The Managed Service associated with the Rule
-The Action chosen for the Rule (ex. “Require”,” Ban”)
This comparison happens in three steps:
1)-Generate Exception List:
The policy engine runs through the rules one by one and omits those that don’t apply to smart group in question
For the remaining rules, if the managed service matches that which is applied to the smart group and the action chosen for that rule is “Required,” the policy engine will not do anything.
An exception will be generated for a rule that fits one of two cases:
-if the managed service is already installed on the endpoint but the action is “Ban”
-if the managed service is not installed on the endpoint but the action is “Require”
Since these rules are associated to the endpoint’s smart group, the policy engine considers them applicable, and generates an exceptions list, regardless of their priority
2)-Filter by Priority rule:
The Policy engine takes the exception list and for each exception, it will check if another rule is in higher priority (also according to Smart Group relationship).
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 chosen to by applied
-Only one exception can be applied by the policy engine
If the highest priority exception is lower in priority to another rule according to smart group relationship, no exception will be applied to the endpoint
-----------------------------------
Scenario #1:
- A certain tool has the following rules:
Run Name (in Order) |
Action: |
Service: |
Smart Group: |
Rule #1 |
Require |
MS1 |
SG2 |
Rule #2 |
Require |
MS1 |
SG2 |
Rule #3 |
Ban |
MS2 |
SG1 |
- EP1 is part of Smart Group SG1 only.
- EP1 has the tool installed with MS2 as the Management Service
- Generate Exceptions List:
- #1 is not relevant because EP1 is in a different Smart Group.
- #2 will generate an exception (MS1 is not installed on EP1) - “EX2”
- #3 will generate an exception (MS2 is installed on EP1) - “EX3”
- Filter by priority rule - the Exceptions list has 2 exceptions for #2 and #3. Now it will try to check the priority of the rules that are relevant to the SG of this EP (SG1):
- Rule #1 is out of scope because EP1 is not in SG2.
- EX2 - This is the highest rule that matches EP1
- EX3 - Another rule is in higher priority (#2) so this exception will be filtered out.
- Single Exception treatment - EX2 will be treated.
-----------------------------------
Scenario #2:
A certain tool has the following rules:
Run Name (in Order) |
Action: |
Service: |
Smart Group: |
Rule #1 |
Require |
MS1 |
SG1 |
Rule #2 |
Require |
MS2 |
SG1 |
Rule #3 |
Ban |
MS1 |
SG1 |
- EP1 is part of Smart Group SG1 only
- EP1 has the tool installed with MS2 as the Management Service
- Generate Exceptions List:
- #1 will not generate an exception (MS1 is really not installed on EP1)
- #2 will generate an exception (MS2 is installed on EP1) - “EX2”
- #3 will generate an exception (MS1 is not installed on EP1) - “EX3”
- Filter by priority rule - the Exceptions list has 2 exceptions for #2 and #3. Now it will try to check the priority of the rules:
- EX2 - Another rule is in higher priority (#1) so this exception will be filtered out.
- EX3 - Another rule is in higher priority (#1) so this exception will be filtered out.
- Single Exception treatment - The filter cleaned all exceptions so nothing will be opened.
-----------------------------------
Scenario #3:
A certain tool has the following rules:
Run Name (in Order) |
Action: |
Service: |
Smart Group: |
Rule #1 |
Require |
MS2 |
SG1 |
Rule #2 |
Require |
MS1 |
SG1 |
Rule #3 |
Ban |
MS1 |
SG1 |
- EP1 is part of Smart Group SG1 only
- EP1 have the tool installed with MS2 as the Management Service
- Generate Exceptions List:
- #1 will generate an exception (MS2 is installed on EP1) - “EX1”
- #2 will not generate an exception (MS1 is really not installed on EP1)
- #3 will generate an exception (MS1 is not installed on EP1) - “EX3”
- Filter by priority rule - the Exceptions list has 2 exceptions for #1 and #3. Now it will try to check the priority of the rules:
- EX1 - This is the highest rule that matches EP1
- EX3 - Another rule is in higher priority (#1) so this exception will be 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
Comments
0 comments
Please sign in to leave a comment.