This page refers to an older version of the product.View the current version of the online Help.
Condition Management
In this section:
- About Conditions
- Create a Condition
- Condition Variables
- Field Validation
- Active Directory Based Conditions for Devices in Child Domains
About
Conditions
Conditions are used to create rules which enable actions to be executed based on who, where from or how a user is connecting to a computer or application. Conditions based on Directory Membership, User, Computer, Session and Client can be used to create a configuration which can define computer usage throughout an organization.
They are the bridge between triggers and actions to provide context for applying the action. For example:
| Trigger | Condition | Action |
|---|---|---|
| User > Logon | User > User Name | Map Drive |
The action is to map a drive when a user logs on. The condition allows a user to be specified so the drive is mapped only for that particular user. Without the condition, the drive would be mapped for all users at logon.
Actions can be set to execute when the criteria within the condition is true or false for the user or their computer. For example, a condition can be created which applies the associated actions to a specified computer or the actions could be set to execute for any computer other than that specified. Regular expressions and ranges can also be used to create advanced conditions which apply to multiple matches.
Simple regular expressions can be used such as entering [abc] will match anything which includes any of the characters within the brackets. More complex queries can also be used, for example, ^[a-f]+ will match any user name which begins with a letter from a to f.
For further information see Wildcards and Regular Expressions.
The positioning of a condition within the Policy Configuration navigation tree determines how it is applied. Conditions at the same level within in the tree are evaluated simultaneously. A condition which is a child of another condition, will only evaluate once the parent condition has been successfully executed. All conditions, with the exception of Counter, can also be added to the Environment tab in most triggers.
For any condition which queries the Active Directory, the Environment Manager administrator must be a member of the target domain or have sufficient permissions to access and query the domain.
Create a Condition
This section applies to creating Directory Membership, User, Computer and Session & Client conditions only as the dialog boxes these conditions use follow the same format.
- In the Policy Configuration
navigation tree, select a node or create a new node within the trigger
you want to apply the condition to.
The condition can be added directly to the trigger in the Environment tab.
- In the Conditions ribbon,
select the required condition.
The condition tab, specific to the condition type displays by default. This tab allows the parameters to be set using a common group of options and fields. See Condition Variables for further details.
- Define the condition using the available fields and checkboxes.
- Select the General tab.
- Enter a description and any optional notes. The description is used as the display name for conditions. If this field is left blank the display name is automatically set from the configured condition.
- Click OK to save the condition.
The Environment Manager agent uses the condition to find a match with the same criteria for a logged on user. If a match is found, any actions attached to the condition are executed.
Once created you can prevent a failed action from continuing to execute any dependent sub nodes by selecting the Stop sub node on fail check box in the node work area. By default, Stop sub node on fail is enabled for new conditions.
Condition Variables
Each type of condition can be specified using variations of the following fields, drop-downs and checkboxes:
- Equal - A comparison is made against the contents of the Match field to target the users or computers which fulfill those criteria. Enter the criteria into the Match field or use the ellipsis (...) to search or select as required.
- Not Equal - Targets all users or computers which do not fulfill the criteria in the Match field. Enter the criteria in the Match field or use the ellipsis to search or select as required.
- Query
- Targets all users or computers which match the criteria specified in
the Query field. Using wildcards
in the query allows a wide range of matches, for example:
- *Windows - target users or computers ending in the text Windows.
- Windows* - target users or computers starting with the text Windows.
- *Windows* - target users or computers containing the text Windows.
- Regular Expression - Use regular expressions to specify advanced queries for users or computers.
- Between - Used for conditions where a range of values can be set. For example, a condition could be created to apply to a selected range of IP addresses.
- Evaluate once per session - When selected, a condition is evaluated and the result is cached. If the condition is run again, the result is obtained from the cache rather than evaluating the condition again. If you want multiple instances of the same condition to evaluate only once, a reusable condition must be created and referenced multiple times. If you create multiple conditions, they will each be run one. If a reusable node is referenced multiple times, evaluation only occurs once in the session.
- This option is not available for conditions within Process Start and Process Stop triggers.
The behavior surrounding this option changed in 8.1. Prior to 8.1 the option was evaluated when the configuration was parsed and cached for the session. In 8.1 and later versions, the option is not evaluated until the trigger is fired when the result is cached for the whole session.
For example, a Process Start condition is created for calc.exe with the Evaluate once per session checkbox selected. In 8.0 the result would be cached for the session when the configuration is parsed at logon. In 8.x the result is not cached until calc.exe is run.
Condition
Configuration Examples
The simple configuration below maps Printer 1 at logon for Endpoint 1. During logon, the Environment Manager agent checks the managed computer against that specified in the condition; Endpoint 1. If the condition is met, the action to map the printer to Printer 1 runs. If the managed computer is anything other than Endpoint 1, the action is ignored.
In the Environment Manager console, the example would be as follows:
Adding a further condition at the same level creates an OR condition. This configuration maps Printer 1 at logon for Endpoint 1 OR Endpoint 5. If the computer is one of those specified, the action to map the printer to Printer 1 runs. If the managed computer is anything other than Endpoint 1 or Endpoint 5, the action is ignored.
If a condition is a child of another, an AND condition is created. A condition which checks if the user is an administrator has been added as a child of another condition. By adding this, the action will run for the computers specified AND the user is an administrator.
AND and OR statements can be combined to create AND OR conditions. This configuration maps Printer 1 at logon for Endpoint 1 OR Endpoint 5 for users which have administrator rights.
There is no limit to the number of conditions you can add to AND and OR conditions or the number of AND OR conditions that can be used.
The AND OR labels and the item background colors can be turned on and off in the Options Ribbon.
Field Validation
The table below lists the strings which are acceptable in the fields of the various conditions.
| Condition | Field | Allowed String | Example |
|---|---|---|---|
| User Group | Match | domain\group | ivanti/sales matches the group ’sales’ in the ivanti domain |
| LDAP | CN=sales, DC=ivanti, DC=com matches the ’sales’ group in the ivanti domain | ||
| Query | domain\gro* | ivanti\sal* matches group names starting with "sal" in the ivanti domain | |
| domain\*gro | ivanti\*les matches group names ending with "les" in the ivanti domain | ||
| domain\*gro* | ivanti\*ale* matches group names containing "ale" in the ivanti domain | ||
| User Name | Match | domain\user | ivanti\smithj matches the user name "smithj" in the ivanti domain |
| Query | domain\use* | ivanti\smit* matches group names starting with "smit", in the ivanti domain | |
| domain\*use | ivanti\*ith matches group names ending with "ith", in the ivanti domain | ||
| domain\*use* | ivanti\*ith* matches group names containing "ith", in the ivanti domain | ||
| Computer Group | Match | domain\group | ivanti\sales matches the group ’sales’ in the ivanti domain |
| LDAP | CN=sales, DC=ivanti, DC=com matches the "sales" group in the ivanti domain | ||
| Query | domain\gro* | ivanti\sal* matches group names starting with "sal" in the ivanti domain | |
| domain\*gro | ivanti\*les matches group names ending with "les" in the ivanti domain | ||
| domain\*gro* | ivanti\*ale* matches group names containing "ale" in the ivanti domain | ||
| Computer Name | Match | computer | SalesDesk01 matches the computer name "SalesDesk01" |
| Query | comp* | SalesDesk* matches all computer names starting "SalesDesk" | |
| *comp | Desk01* matches all computer names ending with "Desk01" | ||
| *comp* | Desk* matches all computer names containing "Desk" | ||
| Computer Domain | Match | domain | ivanti matches the domain name "ivanti" |
| domain | ivanti.com matches the domain name "ivanti.com" | ||
| Query | dom* | iva* matches all computer domains starting "iva" | |
| *dom | *nti matches all computer domains ending "nti" | ||
| *dom* | *ant* matches the domains containing "ant". | ||
| Computer NETBIOS | Match | computer | SalesDesk01 matches the computer NETBIOS name "SalesDesk01". |
| Query | comp* | SalesDesk* matches all computer names starting "SalesDesk" | |
| *comp | Desk01* matches all computer names ending with "Desk01" | ||
| *comp* | Desk* matches all computer names containing "Desk" | ||
| Computer IP Address | Match | xxxx.xxxx.xxxx.xxxx | 192.168.0.1 matches the IP address 192.168.0.1 |
| Between | xxxx.xxxx.xxxx.xxxx yyyy.yyyy.yyyy.yyyy | IP Address 1: 192.168.0.1, IP Address 2: 192.168.0.254 matches all IP addresses between "192.168.0.1" and "192.168.0.254" | |
| User OU Membership | Match | LDAP | CN=sales, DC=ivanti, DC=com matches the directory membership of user OU "sales" in the ivanti.com domain |
| Query | ou* | sales* matches user OU names starting with "sales" | |
| *ou | *sales matches user OU names ending with "sales" | ||
| *ou* | *sales* matches user OU names containing "sales" | ||
| Computer OU Membership | Match | LDAP | CN=sales, DC=ivanti, DC=com matches the directory membership of computer OU "sales" in the ivanti.com domain. |
| Query | ou* | sales* matches computer OU names starting with "sales" | |
| *ou | *sales matches computer OU names ending with "sales" | ||
| *ou* | *sales* matches computer OU names containing "sales" | ||
| Directory Site | Match | sitename | testsite matches the site name "testsite" |
Active Directory Based Conditions for Devices in Child Domains
Active Directory (AD) based client conditions convert the NetBIOS name of the client, obtained from Windows Terminal Server (or Citrix equivalent), to a FQDN used to query AD. The FDQN cannot be resolved if the terminal server is in the parent domain and is trying to resolve the FQDN of a connecting device in a child domain. This impacts Device and Custom rules, with Active Directory based client conditions, that are applied to terminal servers and VDIs in a root domain.
The terminal server must be configured with the DNS suffix of all child domains. The search list must be configured on all terminal servers wanting to resolve names for connecting in child domains.
For example, for the parent domain.local, the child domains, childa.domain.local and childb.domain.local, must be configured on the terminal server in order for AD based conditions to evaluate correctly.
For information about configuring domain suffix search lists, see: https://support.microsoft.com/en-gb/kb/275553