The Rule Analysis window has a check box which, when selected, displays only those rules which are conflicts, overrides, redundancies, or supplements.
Default access (Allow, Block, or Unchanged) and ActiveSync command modes (PowerShell or Simulation) are set separately for each Microsoft Exchange environment configured in your XenMobile deployment.
You can configure the maximum number of snapshots shown in the snapshot history.
You can configure which errors to ignore during a major snapshot. When a major snapshot returns errors that are not configured as ignorable, the results of the snapshots are discarded.
To configure errors as ignorable, edit the config.xml file using an XML editor:
- If the Exchange Server is Office 365, navigate to the /ConfigRoot/EnvironmentBridge/AccessLayer/SpecialistsDefaults/PowerShells/PowerShell[@id='ExchangeOnline']/IgnorableErrors node and add the text to be matched as a child element in the same format as the existing Error child element. Regular expressions are supported.
- If the Exchange Server is on-premises, navigate to the /ConfigRoot/EnvironmentBridge/AccessLayer/SpecialistsDefaults/PowerShells/PowerShell[@id='ExchangeColocated']/IgnorableErrors node and add the text to be matched as a child element in the same format as the existing Error child element. Regular expressions are supported.
- If there is more than one Exchange environment configured, navigate to the /ConfigRoot/EnvironmentBridge/AccessLayer/Environments/Environment[@id='ID Corresponding to the desired Exchange environment']/ExchangeServer/Specialists/PowerShell node. Add an IgnorableErrors child node to the PowerShell node for each error to be ignored. Add an Error child node to the IgnorableErrors node with the matching text contained in a CDATA section. Regular expressions are supported.
Save the config.xml and restart the XenMobile Mail Manager service.
PowerShell and Exchange
XenMobile Mail Manager now dynamically determines which cmdlets to use based on the version of Exchange it is connected to. For example, for Exchange 2010, it uses Get-ActiveSyncDevice, but for Exchange 2013 and Exchange 2016, it uses Get-MobileDevice.
Exchange Server configurations can be edited and updated without restarting the XenMobile Mail Manager service.
Two new columns added to the Exchange environment summary tab display each environment's command mode (PowerShell or Simulation), and access mode (Allow, Block, or Unchanged).
Troubleshooting and Diagnostics
A set of PowerShell utilities for troubleshooting is available in the Support\PowerShell folder.
Testing connectivity to the Exchange service using the Test Connectivity button in the Configuration window of the console runs every read-only cmdlet used by the service, runs RBAC permissions tests against the Exchange Server for the configured user, and displays any errors or warnings in color-coded fashion (blue-yellow for warnings, red-orange for errors).
A new troubleshooting tool performs in-depth analysis of user mailboxes and devices, detecting error conditions and potential areas of failure, and in-depth RBAC analysis of users. It can save raw output of all cdmlets to a text file.
In support scenarios, all properties for all mailboxes on all devices managed by XenMobile Mail Manager can be saved by selecting a diagnostic check box in the console.
In support scenarios, trace-level logging is now supported.
XenMobile Mail Manager supports Basic authentication for on-premises deployments. This enables XenMobile Mail Manager to be used when the XenMobile Mail Manager server is not a member of the domain in which the Exchange Server resides.
XenMobile Mail Manager applies local access control rules to all users in Active Directory (AD) groups, even if an AD group contains more than 1000 users. Previously, XenMobile Mail Manager applied local access control rules only to the first 1000 users of an AD group. [#548705]
The XenMobile Mail Manager console sometimes failed to respond when querying Active Directory groups containing 1000 users or more. [CXM-11729]
The LDAP Configuration window no longer displays an incorrect authentication mode. [CXM-5556]
User names with apostrophes no longer cause minor snapshots to fail. [#617549]
In support scenarios where pipelining is disabled (the Disable Pipelining option is selected in the Configuration window of the XenMobile Mail Manager console), major snapshots no longer fail in on-premises Exchange environments. [#586083]
In support scenarios where pipelining is disabled (the Disable Pipelining option is selected in the Configuration window of the XenMobile Mail Manager console), data for deep snapshots is no longer collected regardless of whether the environment was configured for deep or shallow snapshots. Now data for deep snapshots is collected only when the environment is configured for deep snapshots. [#586092]
The first major snapshot after initial installation occasionally encountered an error that prevented XenMobile Mail Manager from running another major snapshot until the XenMobile Mail Manager service was restarted. This no longer occurs. [CXM-5536]
1. Click the XmmSetup.msi file and then follow the prompts in the installer to install XenMobile Mail Manager.
2. Leave Launch the Configure utility selected in the last screen of the set-up wizard. Or, from the Start menu, open XenMobile Mail Manager.
3. Configure the following database properties:
a. Select the Configure > Database tab.
b. Enter the name of the SQL Server (defaults to localhost).
c. Keep the database as the default CitrixXmm.
4. Select one of the following authentication modes used for SQL:
- Sql. Enter the user name and password of a valid SQL user.
- Windows Integrated. If you select this option, the logon credentials of the XenMobile Mail Manager Service must be changed to a Windows account that has permissions to access the SQL Server. To do this, open , right-click the XenMobile Mail Manager Service entry and then click the Log On tab.
Note: If Windows Integrated is also chosen for the BlackBerry database connection, the Windows account specified here must also be given access to the BlackBerry database.
5. Click Test Connectivity to check that a connection can be made to the SQL Server and then click Save.
6. A message prompts you to restart the service. Click Yes.
7. Configure one or more Exchange Servers:
a. If managing a single Exchange environment, you only need a single server specified. If managing multiple Exchange environments, you need a single Exchange Server specified for each Exchange environment.
b. Select the tab. c. Click Add.
d. Select the type of Exchange Server environment: On Premise or Office 365.
e. If you select On Premise, enter the name of the Exchange Server that will be used for Remote PowerShell commands.
f. Enter the user name of a Windows identity that has appropriate rights on the Exchange Server as specified within the Requirements section.
g. Enter the Password for the user.
h. Select the schedule for running Major snapshots. A major snapshot detects every Exchange ActiveSync partnership.
i. Select the schedule for running Minor snapshots. A minor snapshot detects newly created Exchange ActiveSync partnerships.
j. Select the Snapshot Type: Deep or Shallow. Shallow snapshots are typically much faster and are sufficient to perform all the Exchange ActiveSync Access Control functions of XenMobile Mail Manager. Deep snapshots may take significantly longer and are only needed if the Mobile Service Provider is enabled for ActiveSync; this allows XenMobile to query for unmanaged devices.
k. Select the Default Access: Allow, Block, or Unchanged. This controls how all devices other than those identified by explicit XenMobile or Local rules are treated. If you select Allow, ActiveSync access to all such devices will be allowed; if you select Block, access will be denied; if you selectUnchanged, no change will be made.
l. Select the ActiveSync Command Mode: PowerShell or Simulation.
- In PowerShell mode, XenMobile Mail Manager will issue PowerShell commands to enact the desired access control.
- In Simulation mode, XenMobile Mail Manager will not issue PowerShell commands, but will log the intended command and intended outcomes to the database. In Simulation mode, the user can then use the Monitor tab to see what would have happened if PowerShell mode was enabled.
m. Select View Entire Forest to configure XenMobile Mail Manager to view the entire Active Directory forest in the Exchange environment.
n. Select the authenication protocol: Kerberos or Basic. XenMobile Mail Manager supports Basic authentication for on-premises deployments. This enables XenMobile Mail Manager to be used when the XenMobile Mail Manager server is not a member of the domain in which the Exchange server resides.
o. Click Test Connectivity to check that a connection can be made to the Exchange Server and then click Save.
p. A message prompts you to restart the service. Click Yes.
8. Configure the access rules:
a. Select the tab.
b. Click the XDM Rules tab.
c. Click Add.
d. Enter a name for the XenMobile server rules, such as XdmHost.
e. Modify the URL string to refer to the XenMobile server; for example, if the server name is XdmHost and the instance name is zdm, enter http://XdmHostName/zdm/services/MagConfigService.
f. Enter an authorized user on the server.
g. Enter the password of the user.
h. Keep the default values for the Baseline Interval, Delta Interval, and Timeout values.
i. Click Test Connectivity to check the connection to the server and then click OK.
Note: If the Disabled check box is checked, the XenMobile Mail Service will not collect policy from the XenMobile server.
9. Click the Local Rules tab.
a. If you want to construct local rules that operate on Active Directory Groups, click Configure LDAP and then configure the LDAP connection properties.
b. You can add local rules based on ActiveSync Device ID, Device Type, AD Group, User, or device UserAgent. In the list, select the appropriate type. For details, see XenMobile Mail Manager Access Control Rules.
c. Enter text or text fragments in the text box. Optionally, click the query button to view the entities that match the fragment.
Note: For all types other than Group, the system relies on the devices that have been found in a snapshot. Therefore, if you are just starting and haven’t completed a snapshot, no entities will be available.
d. Select a text value and then click Allow or Deny to add it to the Rule List pane on the right side. You can change the order of rules or remove them using the buttons to the right of the Rule List pane. The order is important because, for a given user and device, rules are evaluated in the order shown and a match on a higher rule (nearer the top) will cause subsequent rules to have no effect. For example, if you have a rule allowing all iPad devices and a subsequent rule blocking the user "Matt", Matt's iPad will still be allowed because the "iPad" rule has a higher effective priority than the "Matt" rule.
e. To perform an analysis of the rules within the rules list to find any potential overrides, conflicts, or supplemental constructs, click Analyze and then click Save.
10. Configure the Mobile Service Provider.
Note: The Mobile Service Provider is optional and is necessary only if XenMobile is also configured to use the Mobile Service Provider interface to query unmanaged devices.
a. Select the > MSP tab.
b. Set the Service Transport type as HTTP or HTTPS for the Mobile Service Provider service.
c. Set the Service port (typically 80 or 443) for the Mobile Service Provider service.
Note: If you use port 443, the port requires an SSL certificate bound to it in IIS.
d. Set the Authorization Group or User. This sets the user or set of users who will be able to connect to the Mobile Service Provider service from XenMobile.
e. Set whether ActiveSync queries are enabled or not.
Note: if ActiveSync queries are enabled for the XenMobile server, the Snapshot type for one or more Exchange Servers must be set to Deep; this may have significant performance costs for taking snapshots.
f. By default, ActiveSync devices that match the regular expression Secure Mail.* will not be sent to XenMobile. To change this behavior, alter the Filter ActiveSync field as necessary.
Note: Blank means that all devices will be forwarded to XenMobile.
g. Click Save.
11. Optionally, configure one or more BlackBerry Enterprise Server (BES):
a. Click Add.
b. Enter the server name of the BES SQL Server.
c. Enter the database name of the BES management database.
d. Select the Authentication mode. If you select Windows Integrated authentication, the user account of the XenMobile Mail Manager service is the account that is used to connect to the BES SQL Server.
Note: If you also choose Windows Integrated for the XenMobile Mail Manager database connection, the Windows account specified here must also be given access to the XenMobile Mail Manager database.
e. If you select SQL authentication, enter the user name and password.
f. Set the Sync Schedule. This is the schedule used to connect to the BES SQL Server and checks for any device updates.
g. Click Test Connectivity to check connectivity to the SQL Server.
Note: If you select Windows Integrated, this test uses the current logged on user and not the XenMobile Mail Manager service user and therefore does not accurately test SQL authentication.
h. If you want to support remote Wipe and/or ResetPassword of BlackBerry devices from XenMobile, check the Enabled check box.
- Enter the BES fully qualified domain name (FQDN).
- Enter the BES port used for the admin web service.
- Enter the fully qualified user and password required by the BES service.
- Click Test Connectivity to test the connection to the BES.
- Click Save.
XenMobile Mail Manager provides a rule-based approach for dynamically configuring access control for Exchange ActiveSync devices. A XenMobile Mail Manager access control rule consists of two parts: a matching expression and a desired access state (Allow or Block). A rule may be evaluated against a given Exchange ActiveSync device to determine if the rule applies to, or matches the device. There are multiple kinds of matching expressions; for example, a rule may match all devices of a given Device Type, or a specific Exchange ActiveSync device ID, or all devices of a specific user, and so on.
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:
- Active Sync Device ID
- ActiveSync Device Type
- User Principal Name (UPN)
- ActiveSync User Agent (typically the device platform or email client)
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.
- Default Access – Allow. Any device that is not matched by either a local or XenMoble server rule will be allowed.
- Default Access – Block. Any device that is not matched by either a local or XenMoble server rule will be blocked.
- Default Access - Unchanged. Any device that is not matched by either a local or XenMoble server rule will not have its access state modified in any way by XenMobile Mail Manager. If a device has been placed into Quarantine mode by Exchange, no action is taken; for example, the only way to remove a device from Quarantine mode is to have an explicitly Local or XDM rule override the quarantine.
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:
- Local rules
- XenMobile server rules
- Default access rule
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.
- Overriding rule. An override occurs when more than a single rule could apply to the same device. Because rules are evaluated by priority in the list, the later rule instance(s) which might apply might never be evaluated.
- Conflicting rule. A conflict occurs when more than a single rule could apply to the same device but the access (Allow/Block) does not match. If the conflicting rules are not regular expression rules, a conflict always implicitly connotes an override
- Supplemental rule. A supplement occurs when more than one rule is a regular expression rule and hence there might be a need to ensure that the two (or more) regular expressions can either be combined into a single regular expression rule, or are not duplicating functionality. A supplementary rule may also conflict in its access (Allow/Block).
- Primary rule. The primary rule is the rule that has been clicked within the dialog box. The rule is indicated visually by a solid border line that surrounds it. The rule will also have one or two green arrows pointing up or down. If an arrow points up, the arrow indicates that there are ancillary rules that precede the primary rule. If an arrow points down, this indicates that there are ancillary rules that come after the primary rule. Only a single primary rule can be active at any time.
- Ancillary rule. An ancillary rule is related in some way to the primary rule either through override, conflict, or a supplementary relationship. The rules are indicated visually by a dashed border that surrounds them. For each primary rule, there can be one to many ancillary rules. When clicking on any underlined entry, the ancillary rule or rules that are highlighted are always from the perspective of the primary rule. For example, the ancillary rule will be overridden by the primary rule, and/or the ancillary rule will conflict in its access with the primary rule, and/or the ancillary rule will supplement the primary rule.
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 an override occurs, at least two rules will be underlined: the primary rule and the ancillary rule or rules. At least one ancillary rule will appear in a lighter font to indicate that the rule has been overridden by a higher priority rule. You can click on the overridden rule to find out which rule or rules have overriden the rule. Any time an overridden rule has been highlighted either as a result of the rule being the primary or ancillary rule, a black circle will appear next to it as a further visual indication that the rule is inactive. For example, before clicking on the rule, the dialog box appears as follows:
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:
- Is highlighted in blue and has a solid border.
- Has an upwards pointing green arrow (to indicate that the ancillary rule or rules are all to be found above it).
- Is followed by both a red circle and black circle to indicate respectively that one or more ancillary rule conflicts with its access and that the primary rule has been overridden and is hence inactive.
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:
- Is highlighted in blue and has a solid border.
- Has an upwards pointing green arrow (to indicate that the ancillary rule is to be found above it).
- Is followed by a black circle to indicate an ancillary rule has overridden the primary rule and is hence inactive.
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:
- Is indicated by a solid border with a yellow overlay as a warning that there is more than a single regular expression rule operating against a particular rule field, in this case ActiveSync device type.
- Two arrows are pointing up and down respectively, indicating that there is at least one ancillary rule with higher priority and at least one ancillary rule with lower priority.
- The red circle next to it indicates that at least one ancillary rule has its access set to Allow which conflicts with the primary rule’s access of Block
- There are two ancillary rules: the regular expression ActiveSync device type rule SAM.* and the regular expression ActiveSync device type rule Andro.*
- Both of the ancillary rules are bordered with dashes to indicate that they are ancillary.
- Both of the ancillary rules are overlayed with yellow to indicate that they are supplementally being applied to the rule field of ActiveSync device type.
- You should ensure in such scenarios that their regular expression rules are not redundant.
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.