The staging Integration Service provides a single point in the environment where all newly deployed BMC PATROL Agents can register into the solution stack. The following topics describe how the staging Integration Service functions and best practices for deployment and configuration of a staging Integration Service.
A staging Integration Service supports a smoother process for deploying PATROL Agents into Infrastructure Management environments in three major ways:
BMC PATROL Agent silent installation packages are created so that the staging Integration Service is defined in the package. No other Integration Service is defined in the installation packages. Although technically possible, BMC recommends as a best practice that other Integration Service instances not be defined in the installation packages. When a package is deployed and installed, the PATROL Agent checks in through the staging Integration Service. When the PATROL Agent checks in, the Presentation Server evaluates thein a staging policy and uses that data to automatically assign a data collection Integration Service (or Integration Service cluster) to the PATROL Agent. The agent selection criteria can include any one or a combination of the following:
Integration Service policies are the only Infrastructure Management policies that are applied through a staging Integration Service. Monitoring policies are not applied through a staging Integration Service. Additionally, staging Integration Service policies are only applied through a staging Integration Service instance.
The architecture of network connections (communication protocol, ports, and so on) among the staging Integration Service, PATROL Agents, and the Infrastructure Management Server is technically the same as with other Integration Service instances.
The diagrams in the following steps illustrate the process of utilizing a staging Integration Service:
The following diagram illustrates three different Integration Service nodes and how they are used:
The purpose of each Integration Service is as follows:
The staging Integration Service is used strictly for introducing new agents to the Infrastructure Management Server. (An Integration Service has to be.)
The Integration Service running on an Infrastructure Management Server cannot be configured as a staging Integration Service.
A newly deployed PATROL Agent silent installation package is installed as shown in the preceding diagram. The installation package for the PATROL Agent contains configuration data that informs PATROL Agent on how to connect to the staging Integration Service. When the new Agent starts for the first time, it registers with the Presentation Server through the staging Integration Service. Presentation Server then applies a staging policy to the agent based onin the policy. Agent selection criteria define the agents that the policy must be applied to. The staging policy only contains agent selection criteria and information that defines connectivity for a data collection Integration Service node (or Integration Service cluster). No other agent or KM configuration data can be defined in a staging policy.
After receiving the staging policy, the newly deployed PATROL Agent switches to the data collection Integration Service node (or Integration Service cluster) defined in the staging policy. (The switch is represented by the blue arrow in the diagram.) The agent then receives monitoring polices that match each monitoring policy’s agent selection criteria.
The PATROL Agent starts monitoring and continues to receive any updates to existing monitoring policies and new monitoring policies that match the monitoring policy’s agent selection criteria.
Agents do not move from development to test, and then to production. All agents must first check in with the appropriate staging Integration Service, and then move to their data collection Integration Service. This supports the concept of creating installation packages for development and test only, separate from production.
A single staging Integration Service and a single Presentation Server instance can be used to support multiple Infrastructure Management Servers. The following diagram illustrates how this is designed for Infrastructure Management development, test, production environments.
Multiple Infrastructure Management Server deployment with a staging Integration Service host
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 Presentation Server instance for the entire environment, and eliminates the need to recreate policies in production after they have been created in development and tested.
You define and edit one or more of the following agent assignment configurations in a policy so it can support multiple Infrastructure Management Servers:
The easiest method is to include the appropriate Infrastructure Management 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 Infrastructure Management 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.
At least one Infrastructure Management Server must be included in the agent selection criteria to enable you to control to which Infrastructure Management environments the policy is applied. If you do not include at least one Infrastructure Management Server, the policy is applied to all agents, across all Infrastructure Management Servers that match the agent selection criteria of the policy. Additionally, multiple Infrastructure Management 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 Infrastructure Management Servers.
The policy’s agent selection criteria updates and deletes existing policies on all PATROL Agents that match the criteria. Consequently, it is not possible to test policy edits that currently apply to production without impacting production using the process outlined in the example. Separate policies must be created to test edits in the development and test environments by using the export/import utility.
Policy tags can be used to further control to which PATROL Agents policies are applied. 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 requires you to not only add the appropriate Infrastructure Management Server to the policy selection criteria, but also add the appropriate tag. This helps prevent accidentally picking the production Infrastructure Management Server and saving the policy. 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.
For information about PATROL Agent tagging methods, see .
You must use the policy export/import utility to move policies between environments that have multiple Presentation Server instances. The following diagram illustrates how this is designed in the Infrastructure Management Server development, test, and production environments.
In a multiple Presentation Server deployment, you do not have to specify Infrastructure Management 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 Presentation Server instance with the production environment.
Integration Service nodes can be connected to any Infrastructure Management Server across the environment.
BMC recommends the following best practices for staging Integration Services and Presentation Servers: