Page tree

Unsupported content


This version of the documentation is no longer supported. However, the documentation is available for your convenience. You will not be able to leave comments.

Skip to end of metadata
Go to start of metadata

This topic discusses best practices around staging and policy management for development, test, and production.

Single Central Monitoring Administration instance deployments

A single staging Integration Service and a single Central Monitoring Administration instance can be used to support multiple BMC ProactiveNet Servers. The following diagram illustrates how this is designed for BMC ProactiveNet development, test, production environments.

All policies include agent selection criteria that allow you to completely control the policies that are applied to any and all PATROL Agents across the entire environment spanning development, test, and production. This allows you to install a single Central Monitoring Administration instance for the entire environment, and eliminates the need to recreate policies in production after they have been created in development and tested. One or more of the following agent assignment configurations in the policies is defined and edited to accomplish this:

  • BMC ProactiveNet Server that the agent is assigned to (this is a best practice)
  • Integration Service that the agent is assigned to
  • A “tag” defined in the agent configuration
  • Host name that the agent is running on
  • IP address that the agent is running on

The easiest method is to include the appropriate BMC ProactiveNet Servers in the agent selection criteria at the proper time for the policy as shown in the following figure:

Simply add the test and production BMC ProactiveNet Servers to the policy agent selection criteria when you are ready to apply the policy to those environments. This simplifies the process of moving configuration from QA to test, and finally to production. It also ensures that a policy is not applied to any agents in production until it has been tested and validated. 

The following outlines the process as an example referencing the preceding screen shot.

Phase 1 – Only the BMC ProactiveNet Server named “BPPMRHEL62-HM-QA” is included in the agent selection criteria when the policy is first created.

Phase 2 – The BMC ProactiveNet Server named “BPPMRHEL62-HM-TEST” is added to the agent selection criteria with an OR after the policy has been validated in the QA environment.

Phase 3 – The BMC ProactiveNet Server named “BPPMRHEL62-HM-PROD” is added to the agent selection criteria with an OR after the policy has been tested and validated in the BPPMRHEL62-HM-TEST environment and is ready to be applied in the production environment.


  • At least one BMC ProactiveNet Server must be included in the agent selection criteria in order to control which BMC ProactiveNet environment(s) the policy is applied to. If you do not include at least one BMC ProactiveNet Server, the policy is applied to all agents, across all BMC ProactiveNet Servers that match the agent selection criteria of the policy. Additionally, multiple BMC ProactiveNet Server values must be grouped () and related with a boolean “OR” as in the preceding screen shot. If you use a boolean “AND” to relate the agent selection criterion, the policy is not applied because an agent cannot register with multiple BMC ProactiveNet Servers.

  • Leveraging BMC ProactiveNet Servers in the agent selection criteria is powerful and has far reaching, global implications. If you add a production BMC ProactiveNet Server to the agent selection criteria for a policy by mistake, the policy might be unintentionally applied to hundreds or thousands of agents in production. Therefore, it is extremely important that this process be managed carefully. 


Updates and deletion of existing policies apply to all agents that match the policy’s agent selection criteria. Consequently, it is not possible to test edits to policies that currently apply to production without impacting production using the process outlined above.  Separate policies must be created to test edits in the development and test environments leveraging the export/import utility.

Leveraging tags and precedence in policies

Leveraging tags in policies can also be used to further control the agents that the policies are applied to. Tags must be used to provide a second level of protection to prevent policies still in development or test from being applied to production accidentally. Leveraging tags this way forces users to not only add the appropriate BMC ProactiveNet Server to the policy selection criteria, but also add the appropriate tag. This helps prevent users from accidentally picking the production BMC ProactiveNet Server and saving the policy when they did not mean to. Additionally, tags can be used to provide greater granularity for policy assignment when the other agent selection criteria is not enough.

BMC recommends leveraging precedence in policies so that production policies have the highest precedence and are not superseded by development or test policies. If you follow this recommendation, you will also have to adjust the policy precedence when you want to move it from development to test, and finally from test to production. 

Multiple Central Monitoring Administration instance deployments

The policy export/import utility is used to move policies between environments that have multiple Central Monitoring Administration instances. The following diagram illustrates how this is designed in the BMC ProactiveNet Server development, test, and production environments.

In a multiple Central Monitoring Administration deployment, you do not have to specify BMC ProactiveNet Servers in the agent selection criteria in the development and test environments. This is not needed because the environments are completely separated and do not share a common Central Monitoring Administration instance with the production environment.

General recommendations for staging and policy management

  • Integration Service node(s) can be connected to any BMC ProactiveNet Server across the environment. The Integration Service running on a BMC ProactiveNet Server must also be configured as a staging Integration Service. BMC recommends the following best practices for staging Integration Services and Central Monitoring Administration:
  • In large environments, designate at least one Integration Service node separate from the BMC ProactiveNet Server as a staging Integration service node.
  • Set up high availability for staging Integration Service nodes. This is especially important in environments where deployment of managed nodes and PATROL Agents is rapid and often. For example, in a cloud services provider environment. Setting up high availability for the staging Integration Services ensures limited or no disruption of the monitoring deployment process.
  • Limit the number of staging Integration Service nodes deployed in each environment. Limit this number to one or a single high availability pair per environment if possible. This reduces the number of components that must be maintained. It also eases administration and assignment of monitoring policies across each environment.
  • Limit Central Monitoring Administration to one instance in one BMC ProactiveNet Server (BMC ProactiveNet Server cluster) for each environment where development, QA, test, and production are each separate environments. This helps control the application of policies within the different environments. You can facilitate this by using the export/import capability of Central Monitoring Administration policy content and by assigning the appropriate BMC ProactiveNet Server to the agent selection criteria.
  • Do not move agents from the development to test and then to the production environment. Only configuration policies must be move among environments.

Related topics

BMC ProactiveNet Central Monitoring Administration architecture

Creating a staging policy

Adding or editing a BMC ProactiveNet Integration Service through Central Monitoring Administration

  • No labels