Page tree
Skip to end of metadata
Go to start of metadata

Policy precedence is the priority of a policy and ranges from 0 to 999. A lower number indicates a higher priority. Policy precedence controls the configuration applied to the PATROL Agents and Infrastructure Management servers when there are conflicting or overlapping configurations defined between two or more policies.

The following sections in this topic describe how precedence is applied and best practices regarding usage of precedence values.

Policy precedence behavior

  • Policies are applied on PATROL Agents based on the Agent Selection Criteria that is defined during policy creation.
  • If two policies attempt to manage the same variable, such as /AgentSetup/historyRetentionPeriod, the PATROL Agent resolves the conflict by evaluating the precedence of the involved policies. Consider the following examples:

Example: with conflict

Example: without conflict

Scenario details

Policy A:

Precedence number - 099

Includes configuration for the amount of history the Agent should retain.

/AgentSetup/historyRetentionPeriod - 7 (retention in days)

Policy A:

Precedence number - 699

Includes configuration for monitoring the following Microsoft Windows services:

  • Windows Update Service
  • Windows Time
  • Windows Firewall

Policy B:

Precedence number - 070

Includes configuration for the amount of history the Agent should retain.

/AgentSetup/historyRetentionPeriod - 1 (retention in days)

Policy B:

Precedence number - 499

Includes configuration for monitoring the following Microsoft Windows services:

  • Windows Event Logs
  • Windows Worldwide Publishing
When policies A and B are applied to a PATROL Agent

The Agent resolves the conflict that is related to the /AgentSetup/historyRetentionPeriod variable by evaluating the precedence values of the policies.

Because the precedence value of Policy B (070) is lower than that of Policy A (099), the variable value of Policy B, that is 1, is applied to the Agent.

Remember the rule: Lower the number, higher the precedence.

The Agent is configured according to the union of policy A and policy B because there are no conflicts. All the Windows services configured in policy A and policy B are monitored.


BMC recommends that you do not use the same precedence values for different policies. In such a scenario, the policies behave in the following way:

  • If polices with the same precedence value have the same KM parameters with different threshold settings, and they apply to different platforms, the policy with the latest time stamp is applied.
  • If policies with the same precedence value have different KM parameters, and they apply to the same host, both policies are applied.

Policy precedence values

BMC recommends that you define a precedence numbering system. Related policies can then be grouped according to the numeric ranges of the precedence numbers. Consider the following chart as an example.

Assign precedence numbers starting with the highest number in the range and then continue assignment in the descending order. By doing so, you can leave the lower numbers in the range for specific use cases.

Precedence range

Applicable for

Additional information

001 – 049

Temporary policy overrides

Use for a short term for specific policies until a complete policy is developed.

050 – 099

Policies for low-level behavior management in Agents

Use for policies that you always want to enforce. For example, Agent tuning, event propagation.

100 – 299

Polices that are specific to a logical group of servers

Use for policies such as vCenter monitoring, Exchange Servers, Oracle Servers, Location Related Servers or Services, Agent tuning overrides, and so on.

300 – 499

Specific platform variance policies

Use for policies such as Remote OS monitoring, Windows 2008 monitoring, Linux 6.7 monitoring, Specific Windows services, Specific UNIX processes, and so on.

500 – 699

Standard platform policies

Apply as a standard to large groups of Agents. For example, All Windows, all Linux, and so on.

700 – 899

Other platform policies

Use for examples such as Storage, Network, SNMP, PING, AWS, Azure, and so on.

950 – 999

Prepackaged policies

Reserved for the BMC prepackaged policies. You get these policies when you import the Infrastructure Management PATROL repository.

Policy naming guidelines

To easily track the configurations that are applied to PATROL Agents and to know the order in which the precedence is being applied, you must keep the policies organized.

BMC recommends that you organize policies according to the precedence numbers when creating and editing policies.

Consider the following options as examples for organizing policies:

1) Use policy precedence number in policy name

To enable easy sorting of policies, include the precedence number of a policy as a prefix in the policy naming, as per the following format: <precedence number>_<policyname>.

For example:

  • 099_Basic_Event_Propagation_ALL_AGENTS
  • 599_Standard_Windows_OS_Monitoring

2) Use policy sorting information in policy name

To enable easy searching of policies, include policy-specific information in the policy naming. For example, you can easily you can easily find all Windows policies if the policies are named as follows.

  • Windows2012_Service_Monitoring
  • Windows2012_Standard_Monitoring
  • Windows2008_SQLSrv_Monitoring


  1. Working with Bryan Meranda and he said that there is a special way to handle monitoring service policies. Policies which monitor servers use the include and exclude statements but do not really pay attention to precedence. Can this be verified and documented as this came from a customer question on what the expected behavior



  2. We need to add a section to the policies best practice doc to include a case where the user wants to stack policies using the same precedence.

    Use case:

    I am considering stacking hosts specific policies on the same precedence.   Many of our hosts have server specific monitoring rules.  For example a unix host may have rules that filter out specific filesystems unique to that host that don't require monitoring.  Other hosts may have KMs like ISM that monitor local websites.  Because of the large number of servers, it makes more sense to me to use the same precedence for these policies since the selection criteria is host specific.  Is there any technical or performance reason I should not do this?

    The recommendation is not to do this because:

    If There is  conflict of  2 policies created with same precedence (same KM parameters with different threshold setting and tags, and apply to different platform),  then Policy with latest time stamp will get applied.

    If There is no conflict if 2 policies created with same precedence (each policy focus on one type of KM and with different tag name assigned accordingly, apply to same host) , then both policy will get applied as they have different monitors/KM configured in it.

    This is based on Case 00401388/KA000114620

    Please add to the docs