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