At any point during the adding, removing, and rearranging of the rules in the rule list, clicking the Cancel button will revert the rules list back to the state at which it was when first opened. Unless you click Save, any changes made to this window are lost if you close the Configure tool.
XenMobile Mail Manager has three types of rules: local rules, XenMobile server rules (also known as XDM rules), and the default access rule.
Local rules. Local rules have the highest priority: If a device is matched by a local rule, rule evaluation stops. Neither XenMobile server rules nor the default access rule will be consulted. Local rules are configured locally to XenMobile Mail Manager via the Configure>Access Rules>Local Rules tab. Support matching is based upon a user’s membership within a given Active Directory group. Support matching is based upon regular expressions for the following fields:
As long as a major snapshot has completed and found devices, you should be able to add either a normal or regular expression rule. If a major snapshot has not completed, you can only add regular expression rules.
XenMobile server rules. XenMobile server rules are references to an external XenMobile server that provides rules about managed devices. The XenMobile server can be configured with its own high-level rules that identify the devices to be allowed or blocked based on properties known to XenMobile, such as whether the device is jailbroken or whether the device contains forbidden apps. XenMobile evaluates the high-level rules and produces a set of allowed or blocked ActiveSync Device IDs, which are then delivered to XenMobile Mail Manager.
Default access rule. The default access rule is unique in that it can potentially match every device and is always evaluated last. This rule is the catch-all rule, which means that if a given device does not match a local or XenMoble server rule, the desired access state of the device is determined by the desired access state of the default access rule.
About Rule Evaluations
For each device that Exchange reports to XenMobile Mail Manager, the rules are evaluated in sequence, from highest to lowest priority as follows:
When a match is found, evaluation stops. For example, if a local rule matches a given device, the device will not be evaluated against any of the XenMobile server rules or the default access rule. This holds true within a given rule type as well. For example, if there's more than a single match for a given device in the local rule list, as soon as the first match is encountered, evaluation stops.
XenMobile Mail Manager reevaluates the currently defined set of rules when device properties change, or when devices are added or removed, or when the rules themselves change. Major snapshots pick up device property changes and removals at configurable intervals. Minor Snapshots pick up new devices at configurable intervals.
Exchange ActiveSync has rules governing access as well. It is important to understand how these rules work in the context of XenMobile Mail Manager. Exchange may be configured with three levels of rules: personal exemptions, device rules, and organization settings. XenMobile Mail Manager automates access control by programmatically issuing Remote PowerShell requests to affect the personal exemptions lists. These are lists of allowed or blocked Exchange ActiveSync device IDs associated with a given mailbox. When deployed, XenMobile Mail Manager effectively takes over management of the exemption lists capability within Exchange. For details, see this Microsoft article.
Analyzing is particularly useful in situations in which multiple rules for the same field have been defined. You can troubleshoot the relationships between rules. You perform analysis from the perspective of rule fields; for example, rules are analyzed in groups based upon the field that is being matched, such as ActiveSync device ID, ActiveSync device type, User, User Agent, and so on.
The Appearance of the Types of Rules in the Rule Analysis Dialog Box
When there are no conflicts, overrides, or supplements, the Rule Analysis dialog box has no underlined entries. Clicking on any of the items has no impact; for example, normal selected item visuals will occur.
The Rule Analysis window has a check box which, when selected, displays only those rules which are conflicts, overrides, redundancies, or supplements.
When you click the highest-priority rule, the dialog box appears as follows:
In this example, the regular expression rule WorkMail.* is the primary rule (indicated by the solid border) and the normal rule workmailc633313818 is an ancillary rule (indicated by the dashed border). The black dot next to the ancillary rule is a visual cue that further indicates that the rule is inactive (will never be evaluated) due to the higher-priority regular expression rule that precedes it. After clicking on the overridden rule, the dialog box appears as follows:
In the preceding example, the regular expression rule WorkMail.* is the ancillary rule (indicated by the dashed border) and the normal rule workmailc633313818 is a primary rule (indicated by the solid border). For this simple example, there's not much difference. For a more complicated example, see the complex expression example later in this topic. In a scenario with many rules defined, clicking the overridden rule would quickly identify which rule or rules had overridden it.
When a conflict occurs, at least two rules will be underlined, the primary rule and the ancillary rule or rules. The rules in conflict are indicated by a red dot. Rules that only conflict with one another are only possible with two or more regular expression rules defined. In all other conflict scenarios, there will not only be a conflict, but an override at play. Prior to clicking on either of the rules in a simple example, the dialog box appears as follows:
By inspecting the two regular expression rules, it's evident that the first rule allows all devices with a device ID that contains "App" and that the second rule denies all devices with a device ID that contains Appl. In addition, even though the second rule denies all devices with a device ID that contains Appl, no devices with that match criteria will ever be denied because of the higher precedence of the allow rule. After clicking on the first rule, the dialog box appears as follows:
In the preceding scenario, both the primary rule (regular expression rule App.*) and the ancillary rule (regular expression rule Appl.*) are both highlighted in yellow. This is simply a visual warning to alert you to the fact that you have applied more than a single regular expression rule to a single matchable field, which could mean a redundancy issue or something more serious.
In a scenario with both a conflict and override, both the primary rule (regular expression rule App.*) and the ancillary rule (regular expression rule Appl.*) are highlighted in yellow. This is simply a visual warning to alert you to the fact that you have applied more than a single regular expression rule to a single matchable field, which could mean a redundancy issue or something more serious.
It is easy to see in the preceding example that the first rule (regular expression rule SAMSUNG.*) not only overrides the next rule (normal rule SAMSUNG-SM-G900A/101.40402), but that the two rules differ in their access (primary specifies Allow, ancillary specifies Block). The second rule (normal rule SAMSUNG-SM-G900A/101.40402) is displayed in lighter text to indicate that it has been overridden and is therefore inactive.
After clicking on the regular expression rule, the dialog box appears as follows:
The primary rule (regular expression rule SAMSUNG.*) is followed by a red dot to indicate that its access state conflicts with one or more ancillary rules. The ancillary rule (normal rule SAMSUNG-SM-G900A/101.40402) is followed by a red dot to indicate that its access state conflicts with the primary rule, as well as with a black dot to further indicate that it has been overridden and is therefore inactive.
At least two rules will be underlined, the primary rule and the ancillary rule or rules. Rules that only supplement one another will only involve regular expression rules. When rules supplement one another they are indicated with a yellow overlay. Prior to clicking on either of the rules, in a simple example, the dialog box appears as follows:
Visual inspection easily reveals that both rules are regular expression rules which have both been applied to the ActiveSync device ID field in XenMobile Mail Manager. After clicking on the first rule, the dialog box looks as follows:
The primary rule (regular expression rule WorkMail.*) is highlighted with a yellow overlay to indicate that there exists at least one additional ancillary rule which is a regular expression. The ancillary rule (regular expression rule SAMSUNG.*) is highlighted with a yellow overlay to indicate that both it and the primary rule are regular expression rules being applied to the same field within XenMobile Mail Manager; in this case, the ActiveSync device ID field.The regular expressions may or may not overlap. It is up to you to decide if your regular expressions are properly crafted.
Example of a Complex Expression
Many potential overrides, conflicts, or supplements can occur, making it impossible to give an example of all possible scenarios. The following example discusses what not to do, while also serving to illustrate the full power of the rule analysis visual construct. Most of the items are underlined in the following figure. Many of the items render in a lighter font, which indicates that the rule in question has been overridden by a higher priority rule in some manner. A number of regular expression rules are included in the list as well, as indicated by the icon.
How to Analyze an Override
To see which rule or rules have overridden a particular rule, you click the rule.
Example 1: This example examines why firstname.lastname@example.org has been overridden.
The primary rule (AD-Group rule zenprise/TRAINING/ZenTraining B, of which email@example.com is a member) has the following characteristics:
When you scroll up, you see the following:
In this case, there are two ancillary rules that override the primary rule: the regular expression rule zen.* and the normal rule firstname.lastname@example.org (of zenprise/TRAINING/ZenTraining A). In the case of the latter ancillary rule, what has occurred is that the Active Directory Group rule ZenTraining A contains the user email@example.com, and the Active Directory Group rule ZenTraining B also contains the user firstname.lastname@example.org. Because the ancillary rule has a higher precedence than the primary rule, however, the primary rule has been overridden. The primary rule’s access is Allow, and because both of the ancillary rule's access is Block, all are followed with a red circle to further indicate an access conflict.
Example 2: This example shows why the device with an ActiveSync device ID of 069026593E0C4AEAB8DE7DD589ACED33 has been overridden:
The primary rule (normal device ID rule 069026593E0C4AEAB8DE7DD589ACED33) has the following characteristics:
In this case, a single ancillary rule overrides the primary rule: the regular expression ActiveSynce device ID rule 3E.* Because the regular expression 3E.* would match 069026593E0C4AEAB8DE7DD589ACED33, the primary rule will never be evaluated.
How to Analyze a Supplement and Conflict
In this case, the primary rule is the regular expression ActiveSync device type rule touch.* The characteristics are as follows:
How to Further Analyze the Rules
This example explores how rule relationships are always from the perspective of the primary rule. The preceding example showed how a click on the regular expression rule applied to the rule field of device type with a value of touch.* Clicking on the ancillary rule Andro.* shows a different set of ancillary rules highlighted.
The example shows an overridden rule that is included in the rule relationship. This rule is the normal ActiveSync device type rule Android, which is overridden (indicated by the lightened font and the black circle next to it) and also conflicts in its access with the primary rule regular expression ActiveSync device type rule Andro.*; that rule was formerly an ancillary rule prior to being clicked. In the preceding example, the normal ActiveSync device type rule Android, was not displayed as an ancillary rule because, from the perspective of the then primary rule (the regular expression ActiveSync device type rule touch.*), it was not related to it.
在此示例中，设备类型为 TouchDown 的所有设备将被拒绝访问。
正则表达式本地规则可通过其旁边显示的图标进行区分 - 。 要添加正则表达式规则，您可以通过给定字段的结果列表中的现有值来构建正则表达式规则（只要已完成主要快照），或只需键入您想要的正则表达式。
通过选中正则表达式复选框，可以针对与给定表达式匹配的特定设备运行搜索。 此功能仅在成功完成主要快照时可用。 即使没有计划使用正则表达式规则，您也可以使用此功能。 例如，假定您要查找 ActiveSync 设备 ID 中包含文本“workmail”的所有设备。 为此，请执行以下过程。
下图显示了选定 user1 时的“允许”/“拒绝”选项。