Rules & Rule sets
.
The Lens Portal uses rules to power its dynamic pools. It provides administrators with a powerful and flexible system to create pools based on a variety of workstation attributes.
You can combine rules into a ruleset, allowing for reusable groups of rules that can be used with multiple pools. Multiple rulesets can be associated with a pool too.
Rules
Attributes
The Lens portal provides administrators with many different attributes that they can create pools based on.
Category | Attribute name | Description |
---|---|---|
General |
| The workstation’s hostname |
General |
| The supported platform a workstation was detected on |
General |
| The network the workstation is in |
Operating system |
| The type of operating system: Such as |
Operating system |
| The operating system version |
Template |
| The name of the Lens template that the workstation was created with |
Template |
| The version of the Lens template that the workstation was created with |
Comparators
Comparators tell the dynamic pool engine how to evaluate the attribute values, and whether the workstation should be included in the pool. Different attributes have different comparators.
Category | Attribute name | Attribute type | Supported comparators |
---|---|---|---|
General |
| String | Normal: Advanced: |
General |
| String | Normal: Advanced: |
General |
| CIDR range |
|
Operating system |
| String | Normal: Advanced: |
Operating system |
| Number |
|
Template |
| String | Normal: Advanced: |
Template |
| Number |
|
Value
This is the value that you want to be checked against the workstation’s value.
Case-sensitivity
By default, the rules are case-insensitive. For example, Edit
and EdIT
would be treated as the same.
You can set case sensitivity on a rule-by-rule basis. Please note, that this will only affect attributes of the String
type.
Examples
Take a look at some of the examples below to see how Lens would process different rules.
Hostnames
Rule configuration | Result | ||||
---|---|---|---|---|---|
Workstation hostname | Attribute value | Comparator | Case-sensitive | Included in pool | Reason |
|
|
| ❌ |
| String matches |
|
|
|
| ❌ | Case does not match |
|
|
| ❌ |
| Matches the following characters: EDIT-001 |
IP network (CIDR)
Rule configuration | Result | |||
---|---|---|---|---|
Workstation IP | Attribute value | Comparator | Included in pool | Reason |
|
|
|
| 10.0.1.31 is within the 10.0.1.0/24 network |
|
|
| ❌ | 10.0.1.31 is not within the 10.0.2.0/24 network |
|
|
|
| 10.0.1.31 is not within the 10.0.2.0/24 network |
Rule sets
Rules are grouped into what we call ‘Rule sets’. There is no limit to the amount of rules you can have within a rule set. It is possible to customise how the rules in the rule set are evaluated by changing the Rule logic mode
. Take a look at the examples below on how the rules are evaluated.
Examples
For the examples below, lets assume the following:
Workstation name: EDIT-001
Workstation IP: 10.0.1.32
Scenario 1
Ruleset (Rule logic mode | ||||
---|---|---|---|---|
Rule # | Attribute name | Comparator | Value | Matches |
Rule 1 |
|
|
|
|
Rule 2 |
|
|
| ❌ |
Result | ||||
Added to pool | Reason | |||
| Rule 1 matched. As at least 1 rule matched, the workstation was added to the pool. |
Scenario 2
Ruleset (Rule logic mode | ||||
---|---|---|---|---|
Rule # | Attribute name | Comparator | Value | Matches |
Rule 1 |
|
|
|
|
Rule 2 |
|
|
| ❌ |
Result | ||||
Added to pool | Reason | |||
❌ | Rule 1 matched, but Rule 2 did not match. In |