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

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.

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.

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

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

  3. Define the condition using the available fields and checkboxes.
  4. Select the General tab.
  5. 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.
  6. 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.

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

Related Topics